Agile Autonomy and Commitment

A recent post Should Agile Teams have to Call Their Shots got me thinking.

Calling pool shots == Velocity prediction

Mike makes the statement that calling your pool shot each and every time you shoot the cue is akin to being able to predict the outcome of a sprint iteration. The analogy is interesting but I think a little imprecise. Professional pool players - at least the 8 ball players I have seen on T.V. - have the ability to shoot the cue, hit the ball they want and have the cue glide into the near exact position needed to make their next shot. Pro-pool players seem to do this without really thinking about it (at least that is the way it appears on the T.V.). Similarly scrum sprint teams have to execute work for a period of time and when that time box is up be ready to do the next needed thing. However the sprint team can do this without ever needing to know their velocity at all and they can repeat the cycle over and over without the knowledge of their velocity. Velocity is important in predicting how much a team can do - but is only useful in predicting 'what' a team can do by providing a bar to say that something is too big or too small to fit within an iteration cycle.

Trust

Calling your shot in terms of scrum sprint teams and their velocity measurement is really about creating a level of predictability for the team and the organization as well as generating a level of trust for delivery with the business partners. Unlike the pool example - there is an external group beyond the individual that has to be able to count on the team committing to and delivering on promises so that the organization as a whole can be setup to execute the next set of work without having to worry about items that did not get completed because a team missed the mark. In the pool example there is only a single person and only that persons call of the shots matter - it is hard to scale that example up to teams with multiple people all of whom have to understand the team commitment and the need to follow through. Equating the single person in pool to a single team also doesn't seem quite right for the reason I laid out above... a team doesn't need to call the shot in order to do work in iterations, but they do have to call the shot in order to generate trust that they can 'predictably' do iterations. It is the trust and predictability that allows planning beyond one iteration for the organization.

I think a better analogy would be something like the team being able to reliably hit a bulls-eye in darts. Hitting the bulls-eye in darts requires skill and practice. I believe it to be the practice part of dart throwing that was missing in the pool analogy presented. Teams will not have any knowledge of their velocity when they start out and it will be difficult if not impossible for them to "call their shot" until they have run through many iterations and actually gelled as a team. As they practice however - they will get more consistent and more accurate. However, in those first few sprints, despite not having a consistent velocity and provided that they commit to and complete work that the team agrees can be done, the team will be building the trust with the business and management that as they get more accurate in their velocity measurements the team can be counted on to complete agreed to work in a given iteration.  This is when the benefit of knowing your velocity can be seen. 

Mike was right that knowing the team velocity is important for planning and laying out releases and things - but I would argue that trust that the team will complete what they sign up to complete is far more important.