When you first implement Scrum, it can be HELL!
Sure, if you start with an established team, where the majority of the team has been trained in Scrum or done Scrum before, and you’re working on BAU (Business As Usual) development, it’s reasonably straightforward.
If you have a free choice about where to start implementing Scrum, I would highly recommend starting *there*.
If you have a newly formed team, where the majority of the team has not done Scrum before or been on Scrum training, and you’re working on a ground-up development project, implementing Scrum can be a painful and frustrating experience for everyone involved!
I have seen this situation quite a few times now. And without fail the experience seems to be the same.
Almost as much time is spent discussing the process and how things should be done as actually doing it. The product backlog is confusing and disorganised. Requirements are not clear. User Stories are not adequately prepared. Sprint Planning takes *days* instead of hours. And we all know how much developers love sitting in meetings!
Here are a few tips for handling this common situation…
First and foremost, get your backlog in order! In my series about ‘implementing Scrum in 10 easy steps’, this is step #1 and the most important step. Here I say you should proceed no further until this step is completed, otherwise you’ll regret it. It’s true, believe me! 🙂
Accept the fact it will take your team at least 3 or 4 Sprints to get into any sort of rhythm. Refine how you handle the process in each Sprint.
Resist adapting the process.
Ken Schwaber is the father of Scrum. Ken makes a very good point about this in his book ‘Agile Software Development with SCRUM‘. Scrum is designed to be adaptive. That’s actually a key principle behind the method: ‘Inspect and Adapt’. But until you understand a process well, and have some experiencing executing it as intended, you are in no position to adapt it.
Persevere. Trust me, it’s worth it.
Apart from the usual issues when a group of people adopt a new process they aren’t yet familiar with, newly-formed teams have their own challenges to overcome. According to research, a newly-formed team goes through some specific stages of team formation and only after some time does the team really begin to gel.
These stages are: forming, storming, norming, and performing. Follow the link to see a full description. It really is a very interesting concept and is worth understanding.
During the forming stage, “supervisors need to be directive”. This is in direct conflict with a key principle of Scrum, which is ‘self-organisation’; the idea that the team is empowered and makes its own decisions. Until the team has properly formed, and the process has been established, the team is not in a position to do this.
During the storming stage, team members become more assertive and confront their colleagues with their views. This stage can be contentious, unpleasant and even painful to members of the team who are averse to conflict. Going through this stage whilst still learning how to execute Scrum effectively is what I would refer to as ‘Scrum Hell‘. It’s difficult. But it’s not possible to skip this stage. Human nature demands it.
The norming stage is where team members start to adjust their behaviour as they learn to work together as a team.
Some, but not all, teams will reach the performing stage.
These high-performing teams are able to function as a unit as they find ways to get the job done smoothly and effectively, without inappropriate conflict or the need for external supervision. Team members have become interdependent. By this time they are motivated and knowledgeable. The team members are now competent, autonomous and able to handle the decision-making process without supervision. Dissent is expected and allowed as long as it is channelled through means acceptable to the team.
Then, and possibly only then, is the team is truly capable of self-organisation.
See here for further information on How to implement Scrum in 10 ‘easy’ steps…
Photo by Luis Fabres