Why Sprint n-1 Analysis is a BAD idea...
(commonly known as the Scrummerfall anti-pattern)
Consider the following familiar situation
The team has taken a story in the sprint, and during the sprint, shit hits the fan.
They rework, rework again several times to get it to done. Then the “we-could-have-avoided-this” feeling enters the minds of the team...
In the Retro the conclusion is clear:
We could have avoided this!! We had to analyse this better! We need analysis upfront!
“Stories shall be analysed sprint n-1!!”
What happens if we do this?
Stories will require more time to get it done. Minimal 2 sprints: Analysis sprint + Implementation sprint!
The Cost per Function Point goes up.
The ROI of the team goes down.
Precious time is wasted.
But there is more…
As we do the analysis upfront, we -in most cases at least- leave that to the expert at hand.
If we let the expert do that, we know one thing for sure: the analysis is coming from that one-and-only brain.
And no matter how perfect the analysis might be, the job’s not done yet: the knowledge of that analysis needs to be consumed by the team executing the implementation.
Regardless of the info carrier: One-and-only brain solutions are unilateral and easily biased.
Because of that, two things can happen, depending on the team’s resilience:
- the team accepts the analysis as it’s coming from the expert.
Conclusion: Info is shared, not knowledge.
- the Team resists the analysis, as they are knowledgeable too. (resilient team)
Conclusion: Discussion; there is no supporting surface for the analysis.
In both cases the consequences are not pretty...
- The 1st kills the team’s creativity. As the Team lets the one-and-only brain determine the analysis outcome, we never contribute to the process of analysis. They obey/accept.
- In the 2nd case, discussion will start.
Deeper analysis follows, or at best an update of the analysis.
Either how, precious time is wasted.
And we’re not done yet.
As it happens, implementation is based upon a document; called analysis.
Since an analysis is an imaginary worked out solution, as opposed to a practical implemented solution, it’ll miss feedback from a real life system that has its own typical unforeseen reactions, commonly known by the experts working on it day-in day-out.
Also an analyst cannot foresee these imperfections.
And what happens when analysis does not match the implemented reality? That has to be fixed right?
Discussion starts between the people implementing and the analyst.
In its simplest outcome, the consequence of this discussion can be two-fold:
Either implementation OR the analysis needs rework. That is to say, in the positive outcome that both parties come to an agreement!
Even though the waste of time stacks up, there is another vicious thing going on.
Smart readers amongst us will have noticed this discussion is unintentionally becoming polarized. His solution or our solution?
Have you also noticed the difference in atmosphere compared to the beginning?
Why? This is because both parties have been putting effort in it. Nobody likes their work to be discarded, right?
As you can see, the risk on the total timespan until something gets really done, is not small.
On top: how in heaven's name you estimate this lasagne of actions?
As it turns out: most likely we'll not have an analysis + implementation sprint, but
1 analysis sprint + 1 or more feedback sprints + 1 implementation sprint.
That’s why in Agile the effort to analyse is comprised within the story.
Likewise, the estimation includes the analysis work, which is kicked off when tasking out together.
That’s why in Agile the analysis is done by the Team, not an Analyst role, not upfront.
That's why in Agile the Team is the centre of technical knowledge.
That's why in Agile we tackle problems collaboratively instead of centralised.
It assures immediate feedback loops from and to the experts (the Team)
It assures minimal waste due to handover.
It assures minimal waiting times due to immediate feedback.
Estimations & execution of the work is done by the Team and no one else.