by Martin Harris
I went along to the London Scrum User Group yesterday evening. For a change it was a quiet night. Christmas is around the corner so we had less attendees. Nigel Baker of AgileBear kicked off and suggested putting together 15 tips for good scrum. After some discussion, we came up with 6 good ones, and in true Agile style, we decided that if you did these 6 well, you would be in front of the pack. So we stopped there and got on with eating the snacks and drinking the beer. So here is what the group came up with, look at your team and ask yourself if your doing these, if not, perhaps its time for a scrum experiment?
The London Scrum Groups 6 Good Scrum Tips
- Love your product owner. The group agreed that the product owner should be part of the team. Include them in the meetings and get them involved. Its possibly the most important thing you can do for success in scrum. A fully integrated product owner will spot early on if the stories do not match their expectations. They negotiate the definition of done for a story. They are on hand to answer questions during the iteration removing waste and improving understanding of the stories. The product owner decides if the team has finished stories at the demo. Working closely with the product owner can avoid going adrift and missing your goals, saves a lot of stress when things hit a rough patch as they get to see the problems first hand. We agreed that this point can not be understated, if you do nothing else do this.
- Run Retrospectives. Its very important to take actions away from a retrospective. Be realistic though, your never going to solve them all, so ask the team to priorities them. If your doing the retrospective right your product owner will be there to help with prioritization. If you find something very big lands at the top, split it down into stories. Otherwise pick one or two that the team feel strongly about and turn them into stories. Make sure these stories are included in the next game planning sessions and make it into the iterations. If you have adjustments to the process you can implement these straight away, but experiment with it, and try to measure the impact of changes, you might not get the process right first time. Commit to doing them and then deliver.
- Ask your team to Pair Code. The XP technique of two programmers working on the same task. It was agreed that there are different kinds of pair coding and that they all have a place, but the one we are talking about here is where two equal programmers work together to improve quality and throughput. Don’t be dogmatic, let the team decide how much work should be pair coded.
- Setup Self Directed teams. Self directed teams have been proven to be more efficient. We discussed the role of a scrum master in a self directed team. Its very important that the scrum master does not tell the team how to work, or how to go about completing the tasks. The scrum master does not plan or allocate tasks. The empowered team needs to work out what the tasks are and find out how to finish the stories. The scrum master should spend his efforts removing blocks for the team, checking quality. Its important for the team and scrum master to spot if someone is not completing their work for whatever reason, but a strong team will sort out those kinds of issues if truly self directed. We also decided that to be empowered you need to make the team multi discipline. Include testers, user interface designers etc to remove hand off waste and increase team knowledge. With role diversity comes better decision making.
- Deliver what you commit to. Another gem, it sounds obvious but is so often ignored. Delivering builds trust in the team and the process. Classic ways to miss delivery include: Failing to produce a strong definition of done. The definition should include the programming, integration, testing and setup tasks. In fact everything required to get that task ready for delivery. Another way to miss delivers is to fail to demonstrate at the end of the iteration. You may think your done, but when the product owner sees the work for the first time they may request refinement. If you have kept your product owner close then the demo is likely to be painless. No power-point slides please, only real working software in the demo! So commit and then deliver what you commit to.
- Co-locate your team. The group defined co-location quite tightly. Co-location is not putting everyone in the same office. Its putting the team members next to each other in the same space. Intra team communication does not happen with the team scattered around an office. You should be able to turn around and join the stand up meeting. This closeness, speeds up the myriad of tiny important messages that pass around the team. Some of which is non verbal.
After this rich discussion we gave up on the 15 tips idea. If your doing these, then your doing very well indeed, and are likely to get better over time.
So another excellent meeting, a few more beers and I headed home enlightened, well fed and slightly merry. Why not come along to the next one, we could use your input.
