Scrum Teams root out sources of waste
The seven wastes of software development
Scrum is founded on empiricism and lean thinking. In a previous post, I highlighted how Scrum promotes lean thinking. It’s subtle, but it’s there.
If Scrum promotes lean thinking, then Scrum should help teams and organisations reduce waste.
“Lean thinking reduces waste and focuses on the essentials” — SG 2020
There are many different sources of waste rooted in traditional software development. Just as gardeners look for and remove weeds to look after their gardens, Scrum Teams are always looking for sources of waste in the process to root them out. Anything that prevents teams and organisations from realising the principles of just-in-time and jidoka can constitute a potential waste.
What are the most common types of waste faced by Scrum Teams?
The seven wastes of software development
Mary Poppendieck famously translated the seven wastes of manufacturing into the seven types of waste of software development in her book “Lean Software Development: An Agile Toolkit”:
- Partially Done Work — Unless a work item is complete it does not add value to the customer. Work that has started but is not finished tends to pile up. Many possible causes explain such interruptions. In any case, if something is left unfinished for a long time it impacts the optimal flow of work:
— We can lose important windows of opportunity. What was valuable in the past isn’t necessarily valuable now. Thus, unfinished work can become obsolete.
— The more unfinished work items pile up, the longer it takes to complete them. This is explained by Little’s Law.
— The more unfinished items we have, the more times we have to review what was left unfinished. “What was this about again?” becomes a recurring question. In an attempt to solve this, people tend to generate more work to manage the amount of work they already have:
* Status reports
* Tagging and classifying
* Meetings
* Ordering and grouping tasks
* Extensive documentation
* etc.
This extra work would not be necessary under different circumstances. The work we generate to manage the work we already have is called superfluous work. The dangerous thing about superfluous work is that we think we are adding value when, in reality, we are not.
— Partially done work can also take the form of features that are complete but are stuck in “Ready for deployment” for months, waiting for the next release window. Sometimes functionality becomes overripe, and no one wants it anymore. Fredrik Carleson calls this “Tanker Delivery Pattern”.
2. Extra Processes — Extra work that adds no value to the product. Some emerge as a consequence of accumulating unfinished work, some emerge to fill communication gaps between silos, some emerge because “we have always done it this way”. Some examples are:
— Detailed documentation and reports
— Managing unnecessary large Product Backlogs in the ticketing system
— Reporting meetings
— Detailed long-term planning
Some might argue that certain processes are needed for regulatory reasons or to improve certain “technical” aspects of the product. Others might say those processes don’t add value.
3. Extra Features — Adding unnecessary features that are never used or were never requested by customers. Having extra features:
— Increases the complexity of the product
— Increases the effort needed to maintain the codebase
— Increases technical debt
— Increases the risk of unexpected failures
— In short, increases the Total Cost of Ownership of a Product
4. Task switching — Switching between projects, switching between tasks, switching between maintenance and new development, switching between the task and administration or e-mails, and so forth, can reduce productivity and efficiency. This type of waste is closely related to partially done work. The more unfinished work items we have, the more we will have to revisit them:
— Relearning the contents (“What was this about again?”)
— Expectation management, either in reporting meetings or via email
— Extensive documentation, in the hope of gathering enough information to spend less time catching up again
5. Waiting — Unnecessary waiting times. Delays produce waste by causing extra work:
— Causes Task Switching. While waiting on something we pick up another task
— Increases the effort needed to complete an unfinished task:
* Catching up with something that has been on hold for a while needs time and effort. Once you’re caught up, you still have some work left to actually finish the task
* Delays in testing increase the cost of fixing a defect. The bigger the haystack, the harder it is to find the needle
— Delays in deployment increase the chances of a feature becoming obsolete. Once we discover that customers no longer want the feature, we need extra work to remove it (or maintain it)
6. Motion (Hand-offs) — hand-offs occur when we separate:
— Responsibility (what to do)
— Knowledge (how to do it)
— Action (actually doing it)
— Feedback (learning from results)
Hand-offs generate waste in the form of loss of knowledge. Also, anytime a work item is handed off from one person or team to another, extra work is created in the form of training and knowledge transfer, and this assumes that nothing is lost in translation.
7. Defects — “The amount of waste caused by a defect is the product of the defect impact and the time it goes undetected. A critical defect that is detected in three minutes is not a big source of waste. A minor defect that is not discovered for weeks is a much bigger waste” (M. Poppendieck — Lean Software Development).
How does Scrum deal with these types of waste?
1. Partially Done Work happens when a Product Backlog Item doesn’t meet the Definition of Done before the Sprint Review.
“The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product. […] The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment.” — SG 2020
In other words, Product Backlog items that meet the Definition of Done are not partially done. They are complete. Of course, working in complex environments means we will discover the need to evolve either the product (which will emerge as new Product Backlog items) or the Definition of Done. No Definition of Done is perfect. Still, Scrum considers a Product Backlog item as “complete” if it meets the Definition of Done. The Scrum framework also offers ways to minimise the chances of generating partially done work:
— The Scrum Team has frequent opportunities (at least once a day) to inspect the Sprint Backlog. This level of transparency allows the Scrum Team to detect potential unfinished work, so the scope for the Sprint can be adapted to minimise the chances of having partially done work
— Multiple Increments may be created within a Sprint. Focusing on the flow of value across the entire process should minimise partially done work. This is especially true for teams who practice Continuous Delivery and combine Scrum with Kanban. Why not finish something before starting something else? “Stop starting, start finishing”
— Items that don’t meet the Definition of Done by the end of the Sprint are placed back in the Product Backlog for future consideration. In this case, the Scrum framework offers a way to minimise the impact of generating unfinished work
2. Scrum handles Extra Processes in two ways:
— There are processes that emerge because of “people problems”. Those which serve as communication gaps between silos tend to disappear because of the cross-functional nature of Scrum Teams. Those which serve as command-and-control tools tend to disappear as people become more proficient in living the Scrum Values
— Other processes emerge because quality was not considered at every step of the process. Those are minimised with the help of the Definition of Done for the product. If some processes or activities are deemed unnecessary upon inspection (either at the Sprint Review or the Sprint Retrospective), they should be removed from the Definition of Done
3. Scrum minimises the chance of building Extra Features.
— Scrum Teams focus on a single objective at a time, the Product Goal. Thus, any feature that doesn’t help the Scrum Team advance towards the Product Goal is not considered for planning. It is true that Scrum Teams may work on things outside of the scope of the Sprint Goal (such as process improvements or experiments). Still, I believe that those should be aimed to help the Scrum Team achieve the Product Goal
— Working in complex environments means that some features that are actually delivered will not have the expected impact. In those cases, the frequent opportunities for inspection and adaptation of Scrum will guide the next steps (pivot or delete the feature)
4. Task switching, as defined by Poppendieck, can only happen if members of a Scrum Team work on more than one product/item at the same time. In general, task switching also occurs during the normal course of a Sprint. Problems may arise in production, or an impediment “forces” you to help with something other than what you were doing.
— Scrum Teams are designed to focus on a single Product Goal at a time. Thus, people in a Scrum Team should be committed to working on a single product
— Still, context switching is something Scrum Teams can struggle with. If a team has little focus on flow or suffers from a lot of interruptions, they will struggle with context-switching. The amount of time spent context-switching is one of the Key Value Measures suggested by the Evidence-Based Management framework for a reason
5. Scrum minimises Waiting within the scope of a Scrum Team. Scrum Teams are cross-functional and self-managed. As such, they have complete autonomy and ownership of their work. There can still be some waiting related to dependencies with other parts of the organisation or unexpected changes in the market. That is to be expected as part of a complex environment. If we knew everything beforehand we would plan our work accordingly and we would not need to wait for anything.
6. Hand-offs are minimised in Scrum. Scrum Teams are designed as cross-functional, self-managing, and responsible for all product-related activities. In reality, this is often not the case. Some hand-offs are inevitable, but others are within the scope of Scrum Teams. They should work to eliminate those hand-offs and work with the organisation to minimise the impact of the others.
7. Defects, as defined by Poppendieck, should be minimised in Scrum.
— The focus on empiricism during Scrum Events offers ample opportunities to detect defects:
* During Sprint Planning, Scrum Teams discuss the why, the what, and the how of a Sprint. The level of detail of those conversations helps anticipate risks, and they are considered as part of the plan
* Daily Scrums are the last responsible moment for a Developer to raise the risk of introducing defects. If detected, Developers decide what they need to do about it
* During Sprint Reviews, all participants inspect the outcome of the Sprint and collaborate to determine future adaptations. This includes showing the working Increment. By doing this, participants can detect defects that went unnoticed during the Sprint
— The cross-functional nature of Scrum Teams maximises collaboration and promotes a common understanding of the problems to solve. The entire Scrum Team is accountable for creating a valuable, useful Increment every Sprint
— Adherence to the Definition of Done and good software craftsmanship practices minimise the risk of not detecting defects
Empiricism complements lean thinking
In complex environments, focusing on reducing waste is not enough. We need empiricism to handle complexity and to learn from the outcome of our work. If we were to focus solely on reducing waste, some activities which are critical for the success of a Scrum Team would be considered wasteful. There would be no room for experimentation or learning by trial and error. This is why Scrum is founded on empiricism AND lean thinking.
Empiricism is the philosophy that knowledge is based solely on what can be confirmed with the senses.
Empiricism asserts that knowledge comes from experience and making decisions based on what is observed — SG 2020
Ken Schwaber explains how empiricism became a part of Scrum in one of his articles. In it, he tells the story of Babatunde Ogunnaike (Tunde), one of the authors of “Process Dynamics, Modeling and Control”:
“Lean processes optimized quality and value. Sources of defects were rapidly detected and removed. Everything that wasn’t geared toward optimizing value was also removed. Waste was continually detected and removed.[…]
Tunde said that this approach fell apart when unexpected events overwhelmed the productivity of the line. […] Tunde then took me to the realm of empirical process control, […] when there is more unknown than known, where the complexity is greater than the predictable. He felt that this was more relevant to the field of software development. […] This approach was set up to expect the unexpected through frequent inspection of progress and subsequent adaptation […]”
— Ken Schwaber
“In complex environments, what will happen is unknown. Only what has already happened may be used for forward-looking decision making” — SG 2020
Endnote
The Scrum framework is designed in such a way that it allows Scrum Teams to detect sources of waste in a lightweight and systematic way. This article gives examples of how Scrum tackles the seven wastes of software development. Still, Scrum pursues the delivery of value through adaptive solutions for complex problems.
To deliver the right thing, right, Scrum relies on empiricism and lean thinking.
Thank you for reading.
