By
Clemens Lode
,
January 21, 2022
Person hands over a package to another person (source: Shutterstock).

Sprinting to Delivery

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!

Liked this post? Why not share it or
buy me a cup of coffee on ko-fi.com
?

About the Author

Clemens Lode

Hello! My name is Clemens and I am based in Düsseldorf, Germany. I’m an author of books on philosophy, science, and project management, and coach people to publish their books and improve their approach to leadership.

I like visiting the gym, learning to sing, observing animals, and creating videos on science and philosophy. I enjoy learning from nature and love the idea of optimizing systems.

In my youth, I was an active chess player reaching the national championship in Germany, and an active pen&paper player leading groups of adventurers on mental journeys. These activities align with my calm approach to moderating meetings, leading meetups, and focusing on details. My personality type in socionics is IEE/ENFp.

Read more...
Clemens Lode

Recommended Further Reading

Woman and man training in a gym (source: Shutterstock).
January 21, 2022

When Growing Gets Tough

Applying the principles of Scrum in a larger organization with multiple teams can be challenging. This article discusses a number of improvement ideas.

Related Services

Related Blog Posts

Related Topics

Agile

Agile

Agile is about courage, trust, and discipline. This approach replaces status meetings with time spent working together. The focus of an agile team is people, results, collaboration, and flexibility over processes, contracts, documentation, or plans.

Read more...
Management

Management

Management is the art of coordinating people who do not work together on a daily basis. While working collaboratively is preferred, using management is sometimes inevitable. Here, I will talk about tools and techniques to improve your management style.

Read more...

Do you have a question about our services?

Reach out, we'd love to hear from you! Schedule a video chat or message us by e-mail, WhatsApp, or Discord!

Send us an e-mail (mail@lode.de).

Reach out to us via WhatsApp.

Chat with Clemens on Discord.

Or send us your question or comment here and we'll get back to you ASAP:
Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.
Sign up for the newsletter

Newsletter

Let's keep in touch! Sign up for our occasional newsletter.