I have read in several Lean and DevOps sources that the Sprint events imply a kind of waste, so teams are supposed to move to a Continuous Delivery or Kanban lifecycle as they become mature. This post is to discuss that is simply not true, regardless what lifecyle each team chooses as their favourite one.
Scrum theory roots the Sprint design
As you can read in the Scrum Guide and in many posts the Scrum.org blog, Scrum is based on the empirical process control theory, or empiricism. Complex problems are better solved by self-managing and self-sufficient teams in short feedback loop iterations, where those teams can inspect and adapt whatever needed as they discover information about the problem being solved.
Events should not be judged just by estimating their efficiency in terms of how many team member's time they take. Their outcome is much more than that.
Sprints and their events are not just "meetings to plan and track work", but opportunities to share points of view, to remove erroneuous assumptions (and hence wasteful work later) and to come up with the best possible decissions (because they are rooted in the collective intelligence and not the individual's capacity).
The House of Scrum by Gunther Verheyen.
Beside the decission optimization, Sprint events also contribute to the growth of the team by the co-learning and with the development of a true team conciousness and sound relationships among its members. The Aristotle Project by Google showed that a team where the decission-taking and communication is balanced works better than other more talented but less participative.
Focusing on individual team member performance or backlog items throughput (e.g. velicity) may be counterproductive. A good team's outcome is more than the sum of the outcomes of their members. The product's outcome is more than its output (e.g. lines of code, number of resolved tickets).
Waste according to Lean
In Lean thinking, waste means uneeded work which adds not value to the product. Tom and Mary Poppendieck identified these seven sources of waste in their book Implementing Lean Software Development.
- Inventory: Unfinished goods (also called as "work in progress," or WIP)
- Overproduction: Producing more than the demand requires
- Extra processing: Additional steps in the process that aren't really needed
- Transportation: Shipping the goods from one place to the other
- Waiting: Lag between process steps
- Motion: Moving around within the process
- Defects: Flaws in the deliverables that impact their features/functionality
Let's use these sources as a definition of waste and find out how could the Sprint events become wasteful.
Why could events produce waste?
If a team does not understand correctly the Scrum or fails to take advantage of the continuous improvement provided by retrospectives, events could become sources of waste. Some examples according to Poppendieck's sources of waste, underlining possible flawed events, are:
- Inventory: teams do not track sufficiently the Work In Progress during the Daily Scrum and end the Sprint with "undone" work.
- Overproduction: Development Team and Product Owner fail to forge a good Sprint Goal during the Sprint Planning and to undestand together what are the priorities for a Sprint.
- Extra processing: teams fail to use Retrospectives to identify uneeded steps, or steps that could be automated.
- Transportation: teams may not be self-sufficient and PBI may have dependencies from external sources. This may not be indentified or tackled enuogh during Retrospectives.
- Waiting: teams use the Daily Scrum as their only Synchronization mechanism and hence, they wait to them to take decissions. Also item's dependencies may not be identified previous to the Sprint during refinement, or during the Sprint Planning, so items could be blocked within the Sprint.
- Motion: during Sprint Planning, team members may not understand sufficienly which is the team's plan to achieve the Sprint Goal and Backlog, and later they may fail as well to optimize the Sprint activities during the Daily Scrum.
- Defects: teams do not use the Definition of Done to identify items that are not ready to be released into the Sprint's increment, and that may not be identified during the Sprint Review and fixed within the Sprint Retrospective.
Agile it's not all about speed but value
The goal of this post was not to compare in detail neither Scrum and Lean nor Scrum and Kanban. It was not also to say which is better. This goal aims to remove the mistaken idea that Sprint events are wasteful and getting rid of them increases team productivity.
The term agility too often is confused with speed. In my opinion, the ultimate goal of Agile is not to produce more (output) but to produce more (outcome).