Embedded Files
First published on Scrum.org, 8 October 2019 (syndicated).
“At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly” — The Agile Manifesto
A few weeks ago we considered the Agile Manifesto from a lean perspective. We saw that it is possible to map the 12 agile principles to the 7 canonical “Lean Wastes” in terms of a mitigation approach. Although it is not an exact science, the act of going through such an exercise may be useful. It can help us to improve our appreciation of how lean and agile practice relate to each other through their shared philosophical underpinnings.
Each Manifesto principle can address multiple forms of waste. One principle is remarkable in that it can be seen to mitigate all seven. It’s the one quoted above: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. This principle applies to the reduction of transport costs, inventory, superfluous movement, unnecessary waiting, over-processing, overproduction, and defects. You see, an agile team will consider every aspect of their work in terms of its empirical outcome. There is nothing in their way-of-working which they cannot challenge. Inspection and adaptation is fundamental to both agile and lean practice.
A team can do this at any time, although a formal opportunity to improve their implementation of Scrum is nevertheless defined: the Sprint Retrospective. This event is often confused or conflated with the Sprint Review, since both typically occur at the end of each Sprint, and are used to reflect in some way upon it. In truth however, the two events serve quite different purposes. Whereas the Sprint Review looks back upon the work that was done in the Sprint, and considers any that still remains to be done, the Sprint Retrospective seeks to improve how the Scrum Team sets about doing its work in the first place. In other words a Sprint Review is focused upon the product, and it is the increment and the Product Backlog which are inspected and adapted. A Sprint Retrospective, on the other hand, is focused upon the team’s process, and it is their implementation of the Scrum framework which they seek to improve.
When a Scrum Team implements Kanban as a strategy, there are implications regarding how a Sprint Retrospective is best conducted. To understand why this is so, let’s leave Kanban out of the picture for the moment, and just think about Scrum. The things a team considers during a Retrospective are not necessarily the same things they would reflect upon — with any invited stakeholders — during a Sprint Review. Although incidents of defects or technical debt might be discussed during the Sprint Review for example, and any remedial work incorporated into the Product Backlog, an investigation into the underlying causes would be a valid topic for the Sprint Retrospective. The team would then seek to inspect and adapt their process, such as by improving their Definition of Done, to avoid any recurrences in the future.
A Scrum Team implementing Kanban would enhance their Sprint Retrospective by inspecting and adapting their workflow, although again, there is nothing to prohibit them from improving it at any time. They’d challenge the stations they use and the WIP limits being observed, the commitment point, and the policies by means of which work transitions from one state to another. Any flow debt that is being incurred would also be of interest. A team leveraging this strategy is more likely to be focused on the optimization of flow rather than on the delivery of specific features. For example if items are stagnating “in progress” — work, in other words, which the team has started and intends to complete but which languishes unfinished — they would try to remedy the situation. They would understand that any accrued value cannot yet be released, and could even be depreciating. Moreover, they would know it subtracts from the available WIP capacity, and prohibits the team from actioning other work of more immediate benefit to stakeholders. That’s where “flow debt” comes from. Rightly or wrongly, time which ought to be spent on completing work already in progress is invested elsewhere.
The incurring of flow debt is not always immediately obvious to Scrum Teams. Unless they are expressly tracking work item age, team members may not realize — during their Daily Scrums for example — just how long an item has actually been in progress. Nor can charts and diagrams necessarily be relied on to expose the issue:
A burn-down or burn-up chart may not reveal the problem, since the rate of completion does not distinguish between those items started recently and those commenced long ago.
A cumulative flow diagram can give an insight into Little’s Law and the approximate average cycle time, but does not allow flow debt to be accurately gauged for essentially the same reason as burn charts. The aging of each individual item is not tracked and hence only approximations over a given time period can be made.
To truly understand the cost of impeded flow, it is necessary to compute the age of each individual item until such time as it is actually completed. Metrics including a true average cycle time can then be derived from the data and any outliers identified. A cumulative flow diagram can then be put into context, and any measurements of cycle time and throughput can be better understood. This information is of great use during a Sprint Retrospective, because the team can then investigate why certain kinds of work item are prone to impeding flow, and they can improve the method by which they handle instances of such cases.
In conclusion, there are differences between a Sprint Review and a Sprint Retrospective, and when a team implements Kanban the differences are still there. A Retrospective is much more about the process the team is following — their implementation of Scrum using Kanban for example — rather than the product or service the team provides to stakeholders. The important thing to remember is that when a team implements Kanban as a strategy, they are more likely to be interested in matters of flow rather than in the delivery of particular features.
Page updated
Google Sites
Report abuse