Scrum is impossible without quality

Hi all, I would like to tell something about Scrum and how it is related to quality.

As Uwe Friedrichsen clearly pointed out on codecentric.de

Uwe Friedrichsen on #scrum:

Leider laufen ganz viele selbsternannte agile “Experten” und “Evangelisten” herum, die auf Konferenzen und anderweitig solche “Ihr seid das Team! Es zählt nur, was Ihr wollt! ‘Die’ haben Euch lange genug nicht ernst genommen! Nur Ihr seid wichtig! ‘Die da’ sollen gefälligst still sein und Euch machen lassen!” – Parolen als Opium unter das Entwickler-Volk streuen und sich entsprechender Beliebtheit erfreuen.

That is, scrum is the opium of the developers community because it promises that we finally get time, as in being left alone, to produce quality software.

Leave us alone during our scrum time box so that we can deliver quality.

It’s a statement that I believe to be true. That is; developers do want to focus on their work to deliver quality software. The reality is that it goes both ways! We can turn the statement around:

If you can’t deliver quality software then you can’t do scrum either.

What we realized when trying to introduce a fixed sprint lately is simply that you can not keep working only on the sprint tasks when the live product is not working as expected because of the previous sprint. In our case it was as bad that it meant we had to do hotfixes and enhancements on the live sites as well as keeping pace on the current sprint.

The reality is that that’s just not scrum. It’s kanban at best because hotfixes are just tasks that take over the top priority tasks of your current sprint. The team is not in scrum mode, but in chaos mode. And that is exactly what happened in our last sprint. Have a look at this imaginary scrum task board.

Image of the task board aka scrumboard with a hotline on top.

We have got rows on our task board for each user story, sorted on priority. The realization is that if your previous sprint has quality issues then your current sprint will have to deal with those issues from the earlier sprint one way or the other. Usually this involves heavy support, doing patches and hot fixing.

The only way to get out of this loophole is to deliver quality. Only if the stories delivered are fully accepted and fully tested you will have somethig that’s shippable.

Conclusion: Slow down. If you do not take the time or use the tools to deliver quality shippable software you will not reach scrum nirvana. If you want to go fast, slow down first. Look what quality is missing and take the time and effort to improve that first.

In this post I explained an agile framework like Scrum that promises to provide uninterrupted dev time in the sprint timebox can only do so if the team provides high quality, fully tested software.

Hope you like it, come back for more! 🙂