That’s 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.”
When it comes to Scrum, a central concept is deployment. As a consultant, looking at the deployment process gives me great 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 isn’t, 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 the stakeholders?
If the result of a sprint requires an additional confirmation by upper management, why not have them included in a 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 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 (PO) to test each story in order to determine if all the acceptance criteria are 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 PO 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 PO if it is clear that the remaining work won’t need more input (like documentation, testing additional special cases, etc.).
Approval is one of the jobs of the PO. 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 PO. If you do that, not only does the PO become the bottleneck, but also you transfer responsibility of the finished story to the PO. You would train the developer to think that if there were any open issues left, it is up to the PO to find them, which moves responsibilities away from the team.
- Neither management nor the PO should be a phase in development.
- The PO should review current work during the sprint and give valuable feedback.
Now, back to the deployment part. Is the goal of the sprint to produce a software package? No! If it indeed produced something at the end, you would actually be utilizing Waterfall. You would have to do a separate architecture meeting at the end of each sprint to combine all the stories together 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. A sprint is merely to better organize planning. You could do 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 or organize the code and the stories so that work required by them does not overlap.