This is an excerpt from the book Scrum Your Jira: Your Waterfall Organization Transformed into Multidisciplinary Teams.
That Is Waterfall, Not Scrum
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Working software is the primary measure of progress. Continuous attention to technical excellence and good design enhances agility. — Principles Behind the Agile Manifesto [cf. Beck, 2001]
When it comes to Scrum, a central concept is deployment. As a consultant, looking at the deployment process gives me helpful insight about a company’s grasp of Agile and Scrum. Depending on the depth of understanding of Scrum and the maturity of the team, the deployment process falls into one of four categories:
- The deployment happens when there is time and when testing is complete and all the features are merged. A point in time is chosen when the whole project becomes stable or when the team is forced to release for business reasons.
- Deployment happens after a separate testing phase after each sprint, maybe even with a separate release manager.
- Most of the time, the team is ready with testing at the end of the sprint. If it is not, overtime is invested.
- Features are deployed and tested independently of each other and independent of the sprint.
Ultimately, the question is a philosophical one. What is commitment? And what is a sprint? Is it an actual software package delivered to the next department? Is it for business to review? Or is the end of the sprint just a status report to stakeholders?
Let us examine:
If the result of a sprint requires an additional confirmation by upper management, why not have them included in the sprint? If the feedback to features comes only at the end of a sprint, valuable time is lost. Additional phases like approval from people outside of the team go against the principles of Scrum. It is the job of the product owner to act on behalf of the stakeholders.
Likewise, it is not the job of the product owner to test each story in order to determine if all the acceptance criteria have been met. The very idea of coming up with acceptance criteria is that the team itself can make decisions about whether or not they met the required function or quality, requiring less interaction with the product owner over time. Finished stories can be demo’d to the product owner throughout the day, getting valuable feedback immediately instead of waiting for the end of the sprint. Even a half-finished story can be shown to the product owner if it is clear that the remaining work will not need more input (like documentation, testing additional special cases, etc.).
Approval is one of the jobs of the product owner. And in order to improve the likelihood of achieving approval, acceptance criteria and the definition of done are formulated. But the workflow should never include assigning testing tasks to the product owner. If you do that, not only does the product owner become the bottleneck, but also you transfer responsibility of the finished story to him or her. You would train the developer to think that if there were any open issues left, it would be up to the product owner to find them, which moves responsibilities away from the team.
To summarize:
- Neither management nor the product owner should be a phase in development.
- The product owner should review current work during the sprint and give valuable feedback.
Now, back to deployment. Is the goal of the sprint to produce a software package? No! If it indeed produced something at the end, you would actually be employing Waterfall. You would have to do a separate architecture meeting at the end of each sprint to combine all the stories and take care that there are no conflicts, and then do another round of testing to make sure that each feature did not affect another.
Delivery and sprints are independent from each other. The purpose of a sprint is merely to better organize planning. You could hold planning and review meetings for each single story separately, but that would result in significant overhead. Delivery or deployment can be done for each individual story, given you invest enough effort into your continuous integration system. Educate your team in proper branching techniques, organize the code into separate modules, and create stories that do not overlap.
Good luck!
