Practice #1 – Speed Drills
In Daniel Coyle’s book The Talent Code, he talks about the different ways that people practice that ultimately enable them to achieve extraordinary results. One the things that he mentions is that a key component of deliberate practice is to speed up or slow down the exercise at hand. He gives some great examples of musicians who are asked to play their music so slowly that the tune would not be recognizable by someone listening to them. Alternatively they are asked to play the music as fast as possible, sort of like a 33 RPM record being played at 78 RPM. What does manipulating the speed do for us? Well, for one thing, it highlights mistakes. Mistakes that you might miss playing at regular tempo may be more readily detected when the pace is dramatically slowed down or sped up.
This strategy is also used by athletes. Dramatically slowing down an exercise is used to detect and fix weaknesses in form. Speeding up the exercise is also used to force mistakes that might normally not occur. The idea is to use varying speed to highlight flaws in performance, which in turn enhances learning. It’s pretty apparent how these strategies apply in music and sports, but how could we apply variations in speed to coaching software teams? A few ideas:
Vary the length of the time boxes that you do development in. Yeah, you heard me right. Try dramatically shrinking the sprint length down to one week, one day, one hour. On the flip side, you could extend it – double it, triple it, quadruple the sprint duration. I know there are those who will try to convince you that this is a “bad thing”, but take it from me, you won’t go to hell for trying this. Shucks, try eliminating the sprints entirely (an infinite time box?).
Vary the length of some of the meetings. If your planning meetings are usually an hour, try all day. If they are 4 hours long, try 10 minutes. Is your stand-up meeting always 15 minutes? How about making it thirty seconds!
Speed up your retrospectives. What would happen if it was like a stream of consciousness game – each person has to blurt out the first thing that comes to mind to describe the sprint. If you don’t answer in 2 seconds then you move on to the next person.
How slowly can you write code? As an exercise you might find that changing your development pace will have interesting effects. Try out the Pomodoro technique.
Will you make mistakes if you do these things? Hell yes! That’s the point! If you want to learn you need to make mistakes. That means you and your team have to be able to change the variables (in this case: time) in order to push your boundaries and learn new things. What I’m talking about is experimenting with the constraints that you apply to yourself and your team. You can’t experiment like that without breaking a few rules. Let’s face it, if you don’t find anything useful by experimenting with the speed of different activities, you can always return to the status quo and blame me.