Scrum is impossible without quality

Lees voor met webReader

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.

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! If you turn the statement around:

If you can’t deliver quality 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 themprevious 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 as best because hotfixes are just tasks that take over the top priority tasks of your current sprint. And that is exactly what happened in our last sprint. Have a look at this imaginary scrum task board.

Image of task board 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 had quality issues then your current sprint will have to deal with that earlier sprint one way or the other. Usually this involves heavy support 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 shipable.

If you do not take the time or use the tools to deliver quality shipable software you will not reach scrum nirvana.