Scrum as an impediment to Agility
As I’m working with smaller and more agile projects, I’m increasingly seeing the classic way that Scrum is executed as more of an impediment to agility than a helper.
This is especially the case when it comes to the classic Sprint Planning as described in [the Scrum Guide](http://www.scrum.org/Portals/0/Documents/Scrum Guides/Scrum_Guide.pdf):
- “For example, two-week Sprints have four-hour Sprint Planning Meetings”
- In the Sprint Planning Meeting part 1: “Development Team works to forecast the functionality that will be developed during the Sprint.”
- In the Sprint Planning Meeting part 1: “Product Owner presents ordered Product Backlog items”
- “Work planned for the first days of the Sprint by the Development Team is decomposed to units of one day or less by the end of this meeting”
I’ve seen many sprint planning meetings struggle for the same reasons again and again:
- The user stories described by the product owner doesn’t fit the team’s way of working
- The team dives into too many details on each user story to be able to break it down to the level required
- The team blames the product owner for not providing enough details to the user stories
- Most of the design discussions are considered to be over once the sprint starts
- The forecasting/commitment to future velocity becomes a heated negotiation
If your project experienced these sorts of Sprint planning meetings, I would expect that the reaction of the project was to add meetings (“backlog grooming”), documentation and checkpoint prior to starting a new sprint. These activities would probably resulted in the product owner (team) spending less amount of time with the development team.
Scrum’s Sprint planning is assuming a situation where the product backlog is detailed for a considerable amount of time and where the ideal is that the product owner spends their time adding more details to the product backlog all the time.
The resulting projects have huge rigid backlogs describing the details for several months into the future. They communication between the users and developers is limited to the acceptance criteria that the product owner writes down before each sprint planning. They spend a considerable amount of the sprint planning the rest of the sprint. Deviations from the sprint backlog are considered problematic.
I think this is misguided. I think this is why we left waterfall in the first place.
In order for Scrum to work better, we have to abandon the idea that the product owner comes to the planning with a perfect set of stories, we have to abandon the sprint backlog detailing the work and design for several weeks and we probably should be very careful with what estimates we ask for.
Instead I would suggest the following approach to planning a sprint:
- The product owner and the team comes into the room informed by their current understanding of the value the system can deliver
- The product owner describes the current most important gaps in the value available to stakeholders
- The team already knows their current trajectory and together with the product owner, they can describe “what’s the next meaningful thing we could demonstrate to closing these gaps” as a script for the next demonstration
- The team isn’t asked to estimate their work, but the product owner, project managers and others are free to make qualified guesses based on the team’s past performance
- Keep it short and frequent!
Scrum was developed in the time where it had to match the perception of projects that did huge batches of planning and design. In response, it does smaller batches of planning and design. But “give a man an inch and he’ll take a yard”. The smaller batches leads to frustration over lack of details and the sprints become more and more plan driven and the connection between the users and the developers more and more document-driven.
A new approach is needed.
Comments:
Johannes Brodwall - Apr 25, 2013
I agree, the culture must change. Scrum comes from the old culture without challenging it.
Geir Amsjø - Apr 26, 2013
Johannes, this post confirms that the current understanding of Scrum is not really up-to date. The problems you describe are common, but solvable within the Scrum framework. You are right that Scrum have not changed much lately, but I do not think it need to. But Scrum has become better described lately; I encourage everybody to read Core Scrum in the Agile Atlas (http://agileatlas.org/atlas/scrum) which represents the Scrum Alliance understanding of Scrum. It is no apparent conflict between The Scrum Guide and the Agile Atlas. But they have a different form and focus.
You quote the Scrum guide, but you have forgotten some vital aspects:
The Scrum Team (the PO, the SM and the Dev team) do Product Backlog Grooming (called Backlog Refinement in Core Scrum) in parallel with the Sprints. This makes the Dev Team well prepared for what is coming in the Sprint Planning. There should not be any big surprises there.
They do retrospectives (The whole Scrum Team of course!) and if they experience problems like you describe, they shall address them and deal with them. That can easily be done within the framework.
Scrum is based on empirical process control, which means that they should not “struggle for the same reasons again and again”. The essential property of Scrum is that that feedback and learning is embedded. The Scrum Guide is very clear on this.
So, no new approach is needed. Just a better understanding.
[Rashad] - Apr 25, 2013
Every new “system” or “model” solves, at the end, one certain problem. Kanban solves software quality, Agile solves unmanageable feature creep, Scrum self reflection and communication in a process, XP with multiple eyes can reduce bug counts in hard to maintain code segments etc. But nothing on that plate solves an disinterested, overworked, searching-for-a-scapegoat, non-committed, non-decision making project owner or an “always have someone to point finger to” company culture, which is sadly very common.
Another “model” doesn’t cut it. We have to start at the lawyers, with the controllers and with the project manager. We need an different culture, where errors are part of the plan, where some level of wrong decisions are expected and long term planning is part of the identity of the company.
Johannes Brodwall - Apr 27, 2013
There’s lots of good things for any organization, Geir. I agree that the retrospective is a practice that leads to success. Personally, I think the sprint review is even more powerful. However, I’m suspicious of the Product Backlog Grooming meeting. I’ve seen this lead organizations towards a phase-oriented Scrum, where each sprint represents a waterfall and the team ultimately feels like having longer ever sprints would make their lives easier. This effect is so common that it even has a name: ScrummerFall.
Although Scrum has tools that help succeed, it also has (a few) elements that impede it.
pip010 - May 23, 2013
Scrum != Agile Scrum == framework a FIXED process Agile == principles Scrum breaks 1 principle of Agile by being a FIXED framework/process.
pip010 - May 23, 2013
" We need an different culture, where errors are part of the plan, where some level of wrong decisions are expected…"
“where errors are part of the plan” let me add, where the focus is not on functional deliverables, but non-func too:
instead of what new feature to pull from backlog, what can go wrong with what we have in the code-base NOW! refactoring … refactoring… refactoring…
context driven development instead of meeting driven development (a.k.a. SCRUM) !
[Ella Mapple] - Jun 18, 2014
It is the responsibility of the Scrum Master to ensure that the Product Owner< does not change requirements or acceptance criteria during the Sprint review and reject a done backlog item because it does not meet the changed requirements. If the requirements have changed, a Product Backlog item needs to be created to address the changed requirements in a future Sprint.
Johannes Brodwall - Jun 18, 2014
Your comment is the correct textbook answer. I’ve seen this textbook answer cause much dysfunction in actual projects