“Scrum doesn’t serve us, it’s not working.”
You may have heard this gripe many times. One of the things that teams must not lose sight of is the framework's emphasis on continuous improvement ("CI" hereafter). At each sprint retrospective, your Scrum team should look at how you are interpreting and applying CI principles.
This article describes a retrospective activity to improve your Scrum process based on the 8 lean wastes. The analysis of these wastes comes from the manufacturing world, but it is easily applied to software development as well.Â
Source: https://goleansixsigma.com/8-wastes/
8 Lean Wastes Applied To Development
Let’s take a look at the wastes shown in the graphic above and how they could arise in the Scrum methodology for software development:
Defects: Errors are made in the delivery of the product, generating rework and inconvenience due to lack of quality.
Overproduction: More is produced than is required: for example, functionality is added that the end user does not need or want.
Waiting: Delays caused by waiting times between activities that take place during the development process.
Under-utilized talent: Waste of team creativity and intelligence due to ineffective allocation of responsibilities and tasks.
Transportation: Unnecessary transportation, whether it be people, equipment, or information, such as excessive amounts of email.
Inventory: Excess inventory can be a waste. For example, a backlog with many tasks unlikely to be completed is excess inventory.
Motion: Performing actions or activities that do not add value to the product, such as having many states for incident management, or too many columns in a kanban board. Excess motion adds complexity and frequently adds little value to the product.
Extra Processing: Excessive steps in a process. For example, approval is required of more people than is really necessary.
A Lean-Focused Retrospective Activity To Try
1. Create A Board To Generate Ideas
After you’ve explained the 8 lean wastes to your team, display the classic scheme of the Scrum life cycle on a board. You could draw or even project this image on a wall to cover it later with post-it notes.
Source: https://www.scrum.org/resources/what-is-scrumÂ
Then, ask your team to think about what wastes they see at each stage of their implementation of the process. Place ideas on post-its (one idea per post-it!). After leaving a block of approximately 10 minutes in silence for each one to think and write down ideas, have the participants stick the post-its onto the image where they correspond and briefly describe their post-it idea. The moderator should group together related ideas.Â
Here are some examples of possible comments that could arise on the post-it notes:Â
- Problems caused by waiting on the requirements specification
- Lack of knowledge in estimating user stories
- Time-consuming daily stand-up meetings that do not always start on timeÂ
- Lengthy planning meetings and retrospectives
- Manual regression testing takes a long time
2. Select Which Topics To Discuss Further
After the team has finished brainstorming ideas, you can use various techniques to prioritize the ideas worth further examination. For example, hold a vote or ask everyone to rank them by priority. The process should be organized based on the number of participants and individual post-its. The idea is to discuss the wastes that the team considers most significant and that most affect the speed and quality of the process.
3. Search For Proposals On How To Eliminate The Chosen Waste
After selecting the given wastes with the most impact, ask the team to meet in subgroups of two or three members to analyze and propose solutions.Â
Taking the debate to subgroups is particularly useful for some teams, because when we have opened the debate up in general, it tends to lead more to catharsis rather than focusing on solutions and proposing action plans.Â
After the subteams meet and discuss ideas, have each of these subteams present their post-its with solutions and proposals on the board. Then the team can arrive at an action plan for implementation.Â
Here are some possible solutions a team may come up with as a result of this activity:Â
- Reduce sprint time from 4 weeks to 2 weeks
- Review and improve the team’s automated testing approach
- Continue working on assembling automated deployments
- Improvements in the Definition of Done or Definition of Ready
- Define acceptance criteria for stories more clearlyÂ
- Formalize grooming meetings (or pre-planning)
Eliminate Inefficiency For Better Software Development
The accumulation of some waste in any process is inevitable. Unexamined and left to fester, it can lead to a loss of team maturity and effectiveness over time. Alternately, your team may not be getting the most out of Scrum practices. Using the activity described above allows an opportunity to review and adjust. On the other hand, perhaps we are not getting the most out of each of the events, artifacts or practices raised by the Scrum framework and this is an opportunity to review and adjust.Â
I invite you to carry out in your team this activity of the 8 Scrum wastes with a lean approach and draw your own conclusions!Â
References and Further Reading
- What is Scrum? - Scrum.org
- 8 Wastes -Â GoLean6Sigma.com
Author Bio
A software quality engineer with over 15 years of experience in performance, automation and functional testing, Federico Toledo is a co-founder and director of the software testing company Abstracta. He holds a PhD in Computer Science from University of Castilla-La Mancha in Spain. Dedicated to testing education, he wrote one of the first books in Spanish on testing and formed Abstracta Academy. He also collaborates with TestingUY, the largest testing conference in Latin America, and frequently publishes articles on his Spanish testing blog, federico-toledo.com. Federico is a firm advocate for agile methodologies and testing as a driver that facilitates DevOps and CI/CD. Follow him on twitter: @fltoledo.
You May Also be Interested In
- Revisited: How To Get Automation Included In Your Definition of Done - Angie Jones
- “Mapping Biases To Testing” Maaike Brinkhof