Is agile really working for you? Let's find out together.

Do you really find meaning in all the ceremonies you do on an agile project? 

Let's consider, you were asked to build a project in 8 weeks that was originally for 6+ months. Let's add to the mix a few unknowns such as not finalized external API integration and a few spikes. Would you take it up? The first thing that would come to your mind would be long working hours and a totally burnt out team with very little chance of success.

Delivering this project requires thinking out side the box. The processes that we follow as chores such as standups, retrospectives, demo and others could become time sinks. We perform the ceremonies as chores and have lost the purpose as defined in the manifesto. 

You can call yourself agile as long as you define your own process and stick to the manifesto. We defined our own process in delivering the above mentioned project in 10 weeks. We call it the Burst Mode Development. 

Burst Mode is a mindset. Do not make the mistake of following it as it is. You want to stick to the purpose of each step and depending on the dynamics of your team, tweak the process to suit your needs.

 
2 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist
 

Outline/structure of the Session

Things that no one talks about:

  • Why do we still have agile consultants?
  • Why are the developers not see the big picture?
  • Are standup's really helping?
  • Why are Iteration Planning Meetings boring?
  • How retro are retrospectives?
  • Why is your team just not able to do TDD well?

A process is no good if it cannot be executed effortlessly. All of the ceremonies above have never been questioned. But the way software world is moving, we need to start asking ourselves - can we do better? Software development is not an art. It is a science. We are engineers and not artists. 

Burst Mode Development - A Pragmatic approach:

Let's see how does the agile manifesto still holds true and how can we think of dynamic processes. Burst Mode is a mindset. I will share the process that you can follow effortlessly without communicating it as a process to our team members. 

 

 

 

 

Learning Outcome

  • A process for delivering a extremely tight deadline projects. 
  • A mindset to now follow rule books dogmatically and thinking pragmatically.
  • How to work with deadline constraints.

Target Audience

CEO, Developers, Business Analyst, Scrum Masters and everyone in the software world.

schedule Submitted 1 year ago

Comments Subscribe to Comments

comment Comment on this Proposal
  • Ellen Grove
    By Ellen Grove  ~  1 year ago
    reply Reply

    Hi Jinesh

    I think there are some intriguing ideas in here, but it's not clear whether your proposal is for an experience report that describes a practical application of the Busrt Mode Development approach (or how the approach emerged from practical experiencese) or whether it is a more theoretical description of a new process approach.  Ravi's original questions still apply here - I would want to see some details that outline why a new approach/mindset was needed, how the team(s) involved determined, carried out and evaluated new processes, what the team learned about working with deadline constraints, and how these experiences resulted in a new approach to emergent process development.  (I realize that this proposal has been changed from a talk to an experience report - updating the abstract to be more specifically about an experience would help make this more real for the reviewers and the conference audience).  

    Thanks

    Ellen

     

     

  • Jinesh Parekh
    By Jinesh Parekh  ~  1 year ago
    reply Reply

    What I am saying is not against agile. Nor we are trying to do any kind of self promotion. The reason to share the experience is to give them a proof of it being something real. Agile in general has been oversold on it's processes. The manifesto is lost. The idea is to get people thinking back to the roots.

    Burst MOde Development could be called as a flavor of agile - Scrum + Kanban + Manifesto + Deadline. The deadline is the addition to it. If you still feel I should convert it to experience report: I can. 

    I will make some edits to the proposal above. Let me know how you feel about it.

    Thanks

    Jinesh

    • Ravi Kumar
      By Ravi Kumar  ~  1 year ago
      reply Reply

      Hi Jinesh,

      Sorry for the delay in getting back on this. I centainly feel sharing this as experience report is much better but this is just my opininon. The review panel might have others.

      Can you share links to the videos of your talk on this topic or others in past events either internal to the company or external. This will help the review team as they go through the proposal. In case you don't have any videos my suggestion is to record a short one on you phone and share the links.

       

      Thanks,

       

      Ravi

  • Ravi Kumar
    By Ravi Kumar  ~  1 year ago
    reply Reply

    Hi Jinesh,

    Thanks for submitting the proposal. 

    I understand that Burst Mode Developement is something that you use to deliver software in your company. I'm sure other companies have their flavors of development as well. Going through the proposal I find the following changes will help in attracting the audience

    1. The Structure/Outline is disconnected from the Learning Outcomes.
    2. If Burst Mode is a mindset so is Agile. Why is Burst Mode more suitable over Agile and what makes Agile less pragmatic etc.?  As I see, the topic sounds more of a self promotion of a framework/approach that you follow which is not desired.

    There are far too many questions that come up. I'm sure many of your customers have benifited from the approaches you've taken. What I would recommend is convert this topic to a 'Experience Report' instead of a talk. Present the following in the Experience Report

    1. Brief Context of the type of projects
    2. Why application of agile approaches were not pragmatic to the context?
    3. How your approach was more pragmatic?

    Elaboration with key data points across few projects on the application of the approach will be good.

    Also, can you please share links to any of the videos and blogs on this topic or others so that the review team gets a better perspective to jude the proposal. If you decide to convert to this to a Experience Report then I would also consider changing the title. 

     

    Best,

    Ravi


  • Liked Neil Killick
    keyboard_arrow_down

    The Slicing Heuristic - A #NoEstimates Method for Defining, Splitting, Measuring and Predicting Work

    Neil Killick
    Neil Killick
    schedule 1 year ago
    Sold Out!
    45 mins
    Talk
    Advanced

    This is a concept I devised a couple of years ago, and it seems there is a new #NoEstimates audience that would like to know more about it.

    A Slicing Heuristic is essentially:

    An explicit policy that describes how to "slice" work Just-In-Time to help us create consistency, a shared language for work and better predictability.

    The Slicing Heuristic seeks to replace deterministic estimation rituals by incorporating empirical measurement of actual cycle times for the various types of work in your software delivery lifecycle.

    It is based on the hypothesis that empiricism leads to smaller cycle time duration and variation (which in business value terms means quicker time to market and better predictability) because it requires work to be sliced into clear, simple, unambiguous goals. Crucially, the heuristic also describes success criteria to ensure it is achieving the level of predictability we require.

    Its application is most effective when used for all levels of work, but can certainly be used for individual work types. For example, a User Story heuristic can be an extremely effective way of creating smaller, simpler work increments, allowing teams to provide empirical forecasts without the need for estimating how long individual stories will take. However, if you are able to incorporate this concept from the portfolio level down, the idea is that you define each work type (e.g. Program, Project, Feature, User Story, etc.) along with a Slicing Heuristic, which forms part of that work type’s Definition of Ready.

    This talk will equip teams and organisations who are established on their Agile journey with a robust, clear and repeatable method for improving the quality and time-to-market of their software development efforts.