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.
Outline/Structure of the Experience Report
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.
- 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.
CEO, Developers, Business Analyst, Scrum Masters and everyone in the software world.
schedule Submitted 8 years ago
People who liked this proposal, also liked:
Neil Killick - The Slicing Heuristic - A #NoEstimates Method for Defining, Splitting, Measuring and Predicting WorkNeil KillickLead Agile CoachMYOB
schedule 8 years agoSold Out!
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.