A couple of weeks ago, I met them. In real life. Scrum zombies! It was at Scrum day Europe 2016. Scrum day is not their natural habitat, they were brought in by two highly skilled Scrum zombie fighters as examples of what can happen when you are touched by the Scrum zombie virus. The zombies were examples shown in the workshop, ‘How do we survive the zombie Scrum apocalypse’ by Johannes Schartau and Christiaan Verwijs. I am going to summarize their workshop and then elaborate a bit more of what I think is the role of the tester in fighting the zombie Scrum apocalypse. For a more detailed view on zombie Scrum, please check their blog.
What exactly is the zombie Scrum apocalypse? And more important; am I already a zombie, maybe even without knowing it? The main problem with zombie Scrum is that it looks like Scrum; the team consists of a Product Owner, Scrum master and a Development Team. They follow the Scrum events; they work in sprints, do sprint plannings, have a daily scrum, sprint review and a sprint retrospective. They have the Scrum artifacts. But they are missing out on the purpose of their work; they don’t seem to deliver working software at the end of the sprint. They miss out on what is the core of Scrum.
Of course, there are other symptoms. Zombie Scrum teams desire no contact with the outside world; they don’t want to get involved with their customers, they don’t care if their poorly built application breaks the end-users machine. They did their job; delivering code. QA failed to catch the bugs, design failed to create a nice look. Not their fault! Whether or not their sprint succeeds or fails, the zombie Scrum team is not affected by it. They don’t try to improve, they just sink in the swamp they created for themselves. They become numb. In a worst case scenario, the Product Owner is absent most of the time, the Scrum master has multiple teams to take care of, developers are often being swapped between teams, so there is no stability. Zombie Scrum teams go through the motions of Scrum, but miss out on the fun in Scrum.
There are many causes of zombie Scrum. Probably the most well known cause (I guess we have seen it all) is the company that want to adapt this fancy new way of developing working software (#hype!). They rename the project manager to Scrum master, start to work in sprints, call the development team Scrum team and there you have it: the company is Scrum. The team slips in a non-productive way of acting-Scrum and starts showing above mentioned symptoms.
Another cause may be the lack of urgency zombie Scrum teams feel. They don’t feel the urgency to connect with their customers to deliver valued, working software. They don’t feel the urgency to learn from their mistakes. Every situation is different however, so take a moment to think about other possible causes of zombie Scrum.
So, having read all this and getting a little depressed by the fact you recognise some of the symptoms; what are we going to do about his? And, for me as a tester, what can I do? How can I contribute to healthy Scrum? As a tester, you are usually working in close collaboration with the developers and the product owner. Talk to them about quality and the importance of delivering working software. Help the product owner by testing his requirements beforehand. Clear requirements will help the developers build working software within the sprint.
Personally, I think the most important way of improving the way your Scrum team works is by talking about what you are building and how you are building it. Talk about your definition of ‘done’. If your team doesn’t have one, try to establish one. Make sure quality assurance is an important part of it. When you are testing, make sure to check if the definition of done is met. If not, discuss your findings with your developers; how can we make sure the software meets the definition of done and we can meet the goal of Scrum; deliver working software every sprint.
There are more ways of improving your Scrum team as a tester, but most of them come down to communication. Communicate with your team about the process and about how you contribute to the sprint goal. Raise your voice in the retrospective. Talk about the purpose of Scrum and make sure you are contributing to it.
If you think you are in a zombie Scrum team, don’t get depressed. Show your team that when you improve, there is fun in Scrum!