Improve your Scrum implementation in one week
As a coach I have the benefit of observing multiple teams doing Scrum. I’ve noticed some basic things they often don’t seem to get right, which I think would massively improve things for them. Often the feeling is that it takes too much effort to get these things right, and they will ‘get around to them’ but they never do. I was inspired to write a post with some concrete steps teams could take to fix some of these things. Below are 5 things you can do to improve how you Scrum. You can do them all in 1 week, and none of them should take you more than 2 hours each.
1. Fix your Heartbeat
I have seen many teams who change their sprint lengths and start and end dates regularly, sometimes every sprint. There is always an excuse: the Product Owner is on leave, the release must go out on Friday, there are no meeting rooms available. Two reasons for fixing your sprint length are: to get a predictable velocity, to reduce complexity. In these teams that change this regularly I often ask “When does your sprint end”, or “What was your previous velocity” and they can’t answer me. This is a problem. Here is how to fix it.
On Monday, after standup, spend 15 minutes with the team and agree:
- Sprint length – if you can’t agree just vote.
- Sprint boundary day (the day you start and stop)
- If you are going to do review, retrospective and planning all in one day or split it over 2.
- When in the sprint you will do a backlog grooming/estimation session to get ready for the next planning
- Agree times everyone can make – make sure you allow enough time, you can always finish early, but if you run late people may have other commitments. Guidelines are 1 hour per week of sprint for SP1 and SP2.
- Agree a venue – try to always use the same on to reduce complexity
Right after the standup, book the meetings as recurring meetings in Outlook (or whatever you use), for the rest of the year. Make sure you name them correctly so people know what they are. Even better make a sprint calendar for your team board which might look like this:
Once you have fixed your heartbeat, don’t compromise it, work everything else around you heart beat. It’s not that difficult. If someone like the Product Owner is on leave, make sure that someone can run planning on their behalf. If there is a public holiday and the office is closed, then make sure that the ceremonies for that day move to the next working day.
2. Define Done
If your team doesn’t have a definition of done that everyone in the team can quote by heart then you have some work to do. Although lots of teams understand the concept, I have seen maybe who are a bit hazy about what theirs is exactly. If there is any doubt, then you can’t be sure each story conforms to it. This gets worst when you are pressurised by a deadline and can’t point to something everyone agreed as the minimum level of quality that is acceptable. This is a slippery slope. Here is how to fix it.
On Tuesday, plan a 1 hour meeting with the team to define their definition of done. Don’t wait for your next retrospective, do it today. Make sure it’s achievable on every story, not unrealistic. If you don’t yet do automated testing and you would like to, don’t add it yet. If you do, then you will very soon start to compromise on your definition of done, and once you’ve done that it has no value. Ensure everyone in the team understands each point. Try not to make it more that 5 points if it’s the first time you’ve done one. Here’s a suggestion from Scott Downey if you are stuck:
- Feature Complete
- Code Complete
- No Known Defects
- Approved by the Product Owner
- Production Ready
Straight after the meeting, type it up. Print it in a large font on your task board so that everyone in standup can read it, regardless of where they stand. Every time someone finishes a story run through the list as a team and confirm it meets the definition. Once you’ve been doing this for a few sprints, review your definition of done in a sprint retrospective and try to improve it.
3. Clean up your taskboard
Your taskboard is the measure of how your team is doing each sprint. If it’s messy and has stuff that is not longer relevant on it, chances are your team isn’t 100% focused. I often see boards with things stuck to the top or bottom as reminders which then get left for weeks and weeks until no one remembers what it was about but don’t want to throw it away either because someone might need it. If your taskboard doesn’t make it 100% clear what you need to do today, there is room for improvement. If your board is messy, then it is likely that your team are not taking care in other work they are doing either. If you have no burndown, then your team have no mechanism for figuring out if they are on track or not. I find this usually leads to a whole range of undesirable behaviour, like not taking commitments seriously, working overtime the weekend before a release, or working on every story on the board on any one day, rather thn limiting work in progress. Here is how to fix it.
On Wednesday, after standup, spend 30 minutes with the team and the task board:
- Remove anything on the board that is not being worked on this sprint.
- Make sure stories are in priority order, and tasks are correctly placed in the to do, in progress or done column.
- If you use different colours to mean something make a key visible on the board, and keep the right stationary next to the board.
- Print a stack of burndown templates (with days on one axis, and story points on the other) and keep them near your board. At the start of each sprint pin one up and update it daily with a marker pen. If your velocity is reasonably stable and sprint lengths are fixed you can use the same template every sprint.
- Decide what the important pieces of information are that need to be on your board. Print them large so that they can be read from 2 meters away. Keep it to the minimum.
- If you use columns like interruptions or unplanned work, make sure the headings are clear so tht everyone knows what the extra items here are for.
Once you’ve cleaned it up, make sure it stays that way. A good idea is to completely clean the board at each sprint planning and only put back up the stuff that is useful to the team.
4. Make your backlog visible
One of the biggest complaints I hear from teams is that they have no idea where they are going. The often know what’s in the next sprint, and maybe even the next release if it’s a month away, but they have no idea what’s coming after that. This lack of visibility affects morale as if teams can’t buy into a bigger picture, they start to believe what they are doing doesn’t really matter. Here’s how to fix this.
On Thursday, meet with the Product Owner and find out if he has a view of what’s coming next. Sometimes they do, but because it’s not firmed up they don’t feel ready to communicate it yet. Working with the Product Owner and a stack of index cards do the following:
- Write the high level features or epic coming up for the next 6 months to a year on index cards. Don’t write down every small story, just the higher level themes.
- Order the cards by priority.
- Use different coloured dots to indicate which need to be in the next release, and what would be nice to have in the next release.
- Stick them up on a wall or board.
Once you’ve got the basics grab the team for an hour and run them through the outline. Explain it is just the current thinking and likely to change. If they have any thoughts or ideas, let them raise them and add them to the wall. The Product Owner can decide how to prioritise them, but this way the team get an opportunity to give their input.
Note this is just the starting point for making this visible. You can grow this into a story map or whatever works for you. But if you have nothing visible today, it’s a start.
5. Plan to learn
Agile is a journey. You don’t get there in one go. We are learning all the time. This means part of improving an agile team is learning new things. You need to read books and blog posts about agile to grow, or even better attend talks or conferences. If you don’t you will either stagnate because you have no new ideas, or you will struggle with something which the industry has already found a good solution for. The best ScrumMasters I know spend time finding out what other teams are doing and then apply what they have learned. It massively improves how a team works because they benefit from lessons other teams have learned. Here is how you do this.
On Friday, spend some time sufing the web and do one or more of the following:
- Find a couple of blogs from agilists you like and trust. Sign up to their RSS feed so that you are notified when they post something new. It’s best if you can integrate this with your email, then you can read these when you normally read your mail. Worst case set some time aside in your calendar to do some reading each week. Also encourage a culture of sharing good articles in your team. To do this, just start sharing things you read that you enjoyed. Soon others will be sharing theirs.
- Sign up to twitter and follow some agilists. They often tweet about good ideas or new blog posts.
- Decide how long it takes you to read a book and commit to reading x number of agile books per year. If your company doesn’t have any, suggest that they get some.
- Find a Scrum or agile user group near you, and sign up so you are notified of their regular events, which are often free. Check out the South African Scrum User Group here: www.scrum.org.za
That’s it. If you do this, you should find things starting to work just a little bit better, unless of course you were doing all of these already 🙂
I’m keen to hear about experiences if anyone tries this out with their team.