Photo by Author
Scrum is a Software Development Lifecycle Methodology
In its most basic form, Scrum is a Software Development Lifecycle Methodology that is based on the principles laid forth in the Agile Manifesto. This article describes how using the basic principles can improve Scrum by adding a Zero Defect model to the backlog and refactoring how we do Retrospectives.
Let's start with the Scrum definition.
In a nutshell, Scrum requires a Scrum Master to foster an environment where: A Product Owner orders the work for a complex problem into a Product Backlog. The Scrum Team turns a selection of the work into an Increment of value during a Sprint. The Scrum Team and its stakeholders inspect the results and adjust for the next Sprint. Repeat
The Scrum Master Fosters the Environment
As a review, let's take these statements apart word by word. The Scrum Master's role is "fostering the environment." What environment? The software release environment. Their primary responsibility is aligning the release process, facilitating meetings so the team is not wasting time, and ensuring the customer's needs are met.
The role of the scrum master stops there. The value they have is to foster the development environment. There are no other hard and fast rules on what they do other than facilitate the work of the product owner and the development team.
The Product Owner Orders the Work but not the Defects
The Product Owner "orders the work on the backlog." In a "Zero Defects" environment, we make a distinction between the backlog work and defects we released to customers. The shift is that the software defects are not a part of the software backlog. They are not valuable to the customers, they are blockers to value and need to be treated as such. Defects should take priority over the stories in the backlog. In this way, a Scrum team is a Zero Defect Scrum Team and the product owner cannot prioritize new features over fixing existing defects.
Define the Sprint Goals and Let the Developer Own the Stories
At the high level, define the sprint goals and then select the stories. Give the developers ownership of the stories, so that they own the functionality of the story from inception to release, and also own any feedback or defects.
Ownership of the story empowers the developer. They determine the subtasks of the story. They demonstrate the story during the sprint review. The developer will also be responsible for any defects.
For all defects, the developer will schedule a "Five Why's" as soon as possible. The "Five Why's" is root cause analysis where we ask why a defect happened five times to get to the root cause and fix it. Other valid root cause analyses exist, but the point is to tolerate Zero Defects and eliminate the root causes of any defects.
Ditch the word 'Stakeholder' and focus on Customers
The word "stakeholder" is problematic and borders on jargon. Looking at the 12 Agile Principles, it does not mention "stakeholder" once. It uses the word "customers," which has a clear meaning.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
By focusing on the customer, the role of the Product Owner elevates to a professional level. They are not an analyst, dutifully writing down requirements and entering them into Jira, then ordering them in a Product Backlog. They are responsible for success with the customer and need a full array of tools that go well beyond Scrum or any methodology. Their role transcends the Scrum and the sprint.
Allocate Stories and Run a Two Week Sprint with 6-8 days of work
Here is a classic example of the two-week Scrum sprint that produces a release.
Monday - Sprint Planning for New Sprint
Wednesday - Sprint Kickoff of the New Sprint
Thursday to Friday of the last day - Avoid unnecessary meetings and do work
Friday of the last day - Demo the sprint work
Tuesday - Release code from Current Sprint
Having the effective sprint days be from Wednesday to Friday and then allocating Monday and Tuesday for no new work. Allocating only enough work that the team will develop in 6 or 8 working days gives unscheduled time gives a buffer and also allows the team time for professional development. Don't overschedule your team, they are professionals, not a feature factory.
Use Retrospectives to Assess Success and Root Cause Analysis
Scrum masters will often lament bad retrospectives. Silent developers during the "What went well? What didn't go well? Yada yada yada..." sessions should be an indicator that the traditional retrospective is ineffective. Ditch that retrospective, it doesn't add value.
Instead of focusing on the scrum team, focus the measure of success on the customer. Since the release ends the sprint, the true retrospective should occur outside of the release and with the customer (in whatever form: it could be analyzing click rates on a new feature). The customer timeline will often be slower than the development timeline, so the cadence will be out of sync.
To improve retrospectives, go back to the original agile principle.
At regular intervals, the team reflects on how to become more effective then tunes and adjusts its behavior accordingly.
We improve the process by assessing how well our work helps the customers. A retrospective needs to focus on customer value as an honest assessment of success.
Do Root Cause Analysis to Improve Internal Process
If there is a problem in our process we will release a defect, something we did as a scrum team failed. As a Zero Defect scrum team, we own the resolution of the root cause of any failures.
A popular method for root cause analysis is "5 Why's". The developer responsible for the story organizes a "5 Why's" meeting as soon as possible as an ad-hoc meeting with the appropriate group. In the meeting, we state the defect, and we ask ourselves why the problem occurred. After discussing 5 deeper and deeper reasons, we get to a better understanding of the root cause and develop an action plan to fix it. This meeting replaces our retrospective improvements because we focus on how we are failing with explicit events.
Conclusion
Scrum is one of many valid software development lifecycle methodologies and the Agile Manifesto is just one of several valid software development principles. Start with a focus on the goal - Software Development - and use the principles to guide the methodology. There is no one way to develop software well, but there are many ways to do it badly.
Some goals should be consistent across methodologies: Focus on customer success, focus on sustainability, focus on quality. Customer Focus, Zero Defects, and Root Cause Analysis are three great principles to bring to any development project.
Comments