Manager: "I want my work delivered when you say it will be delivered"!"
Tech guy: "Stop changing the goal posts every few days and just let me get on with it!"
Sounds familiar?
One process that aims to address these frustrations is "Scrum". "What on earth is that!", you may well ask.
If you are a manager in an internet company you may or may not have heard the technical team talk about "Scrum" and "Agile Development". You may have wondered what it is and why it's becoming so popular. It's actually quite a simple way of organising work into (usually) 2 weeks blocks. To do this a number of roles are created and a number of meetings happen to keep things moving. I'll explain these, but first - why do it?
Benefits of Scrum
Terminology
There's some terminology unique to Scrum. The word Scrum for a start. Yes, I know it's a rugby term, but in this case it doesn't mean anything in particular other than a word to describe the process framework.
At the most basic level you need to understand that work is organised into periods of time called sprints. A sprint is usually a two week period, although it could be almost any time between 1 week and a month. It depends on what works for the team. We found that 2 week sprints worked well for us.
The team commits to deliver a specified amount of work in the upcoming sprint. The resulting work-list is called a sprint backlog.
To describe the rest of the process, I will focus on the following 3 areas:
Key roles in Scrum
1. The Product Owner
This is the person responsible for specifying the changes required. They may do this by themselves or they may represent a wider group of business owners. Their purpose is to scope out the work and arrive at a single list of priorities. The list of priorities is known as the product backlog. Each item on the product backlog is known as a story.
2. The Scrummaster
The Scrummaster is a facilitator. They are usually one of the team and have equal status to all others on the team. They are however responsible for ensuring that the team knows what is expected of them and leads the various meetings to make the process work. They also are charged with working to remove any impediments to progress that are reported by the team.
3. The team
The team is usually a group of developers and related functions (e.g. designer, testers). For Scrum to work well, you probably need at least 4 people, and no more than 10. These are not strict limits - Scrum is just a framework that you need to adapt to make it work for you. In my experience a team of 8 or 9 works great. If I had 20 people I would create two teams rather than have one huge team.
Meetings needed to make the process work
1. Sprint planning meeting
The day before the sprint starts, the team meet to plan the next sprint. They figure out from the product backlog, what tasks are required to deliver each story. They then estimate the time it will take them for each task. Knowing this they can then take on add a number of stories (in priority order) to the sprint backlog.
2. The daily scrum
This is a meeting that happens at the same time every day. In our case we chose 09.30, but it could be any time that works for the team. Every day means every day and it's not optional.
Each team member answers 3 questions in turn,
i) what did you work on yesterday?
ii) what will you work on today?
iii) what is blocking your progress?
The team organise their work around the sprint board. We mounted a white board on the wall and used post-it notes of different colours to represent the tasks. We used different colours for design, development and test. I've also seen magnetic boards that use magnetic post-its. Both work.
The board shows all of the work for the current sprint. (Click to enlarge)
You can see from the board that each story is broken down into tasks. These tasks are placed on the board according to their status. They are either in the queue, being worked on, being tested or are complete.
3. Sprint review
The sprint review is a meeting where the team present their completed stories to the product owner.
4. Sprint retrospective
This meeting happens at the end of the sprint and allows the team to discuss what went well in the sprint, what could have gone better and what they will change for the future. This allows for issues to be addressed and allows for a self-optimising team and process.
Time frame
The length of your sprints can be what you want it to be. Usually a 2 or 4 week cycle is chosen depending on the type of work you receive.
The start day of the sprint does not have to be a Monday. You can start say on a Wednesday and run your sprints Wednesday to Tuesday. Whatever works best for the team.
On a 2 week (10 working day) sprint you might do the following
Day 1 (am) - Sprint planning
Day 2 to day 10 - Daily Scrum
Day 10 (pm) - Sprint review
Day 10 (pm) - Sprint Retrospective
Why does it work?
The team have a clear set of priorities that they have committed to deliver over the coming sprint. They have thought through was required of them, they've discussed it in detail and they've agreed what they can achieve. Once committed, the team work together to maintain their collective reputation by delivering on their promises.
The management start to see stuff getting done. Every 2 weeks they see results. They know that the most important stuff is being worked on first. They know the team are not wasting their time on things that are not a priority for the business.
What can go wrong?
The process only works if the team are not interrupted once the sprint has started. New work should not enter into the current sprint unless the team agree it is possible to take it on. Otherwise, if the priorities really have changed you need to stop the sprint and start a new one. Management need to get used to the fact that they need to plan ahead. Will it wait 2 weeks until the next sprint starts? (In reality, the answer is usually yes).
The other important factor is that the team really need to believe in the structure. All team members need to be behind it and support it. Having one resistant member will spoil the party.
Rituals and rites
One way of rallying human behaviour around a cause is to introduce rituals. Religion of course has done this for centuries, but all social groupings have their rituals and behaviours. Songs and scarves (football supporters), national holidays (counties), opening ceremony (Olympics), holy days (religions).
What's interesting about Scrum is that the meetings, the terminology and the routine give a sense of shared identity to the Scrum team. Through following this process they re-enforce their sense of being a team. It's a very useful by-product of the efficiency of the process.
How to get started with Scrum
I was first introduced to Scrum by Tobias Mayer. He gave a simple but compelling overview of the Scrum process to our team. This planted the seed from which we grew to explore and adopt Scrum. It was simple enough for the key decision makers to "get it" and interesting enough for developers to want to learn more. If you want to introduce Scrum to your organisation, he'd be a good person to do this.
You need to start with one of two key individuals that are keen to get involved. They will be your champions. Get them trained on a Scrum training course. A good course to start with could be Rachael Davies' Scrum Awareness Course. Then get them back in the business and think through with them what needs change in the organisation if you are going to give it a go. Who will take up each of the key roles?
Then, you most definitely need senior management buy-in. They cannot just come to the team and demand work requests - they will also need to channel their requests in the right way, through the Product Owner.
Most importantly for Scrum to work the team needs to dedicate themselves to it's implementation. All the team need to feel that it is a benefit to work this way. Also - it needs to work in a way that suits them, their obstacles, people, goals and company organisation.
It takes a while to get right. We found it took us about 6 months before we really got going and had a clockwork process in place.
I found that the results though were worth it. I had a predicatble process to work with, my team were energised, they took ownership for their work - and most importantly - stuff got done.
Further reading:
Controlchaos.com - Ken Schwaber, The man who wrote the book on Scrum.
Scrum Alliance - Scrum community resource centre
Scrumworks Pro - software to manage your Scrum work flow
Conferences / Events
London Scrum gathering November 2007
No comments:
Post a Comment