Should Agile Teams Have to Call Their Shots?
Written by Mike Cottmeyer Saturday, 7 August 2010 09:33
What do I look for day-one coaching an agile team? The first thing I want to know is if the team is really a team? Do they have everything (and everyone) they need to deliver an increment of working software? Do they plan together, do they work together, do they deliver together? I’m generally of the mind that if you aren’t going to recognize the team as the fundamental unit of value creation, you will struggle with almost everything else agile has to say about product delivery. You might be doing something… it might even produce working products… but it probably won’t look very agile.
Once I have the team in place… the next thing I want to know is if they can make and meet a commitment. I want to know if they can be predictable. Right out of the gate, I am not all that concerned if the team can deliver fast… I might go so far as to say, I don’t even care that they deliver value. To me, the most important thing is that the team gets good at establishing some sort of baseline velocity metric. I want them to be able to break down work into small chunks, put some sort of reliable point estimate on their work, and get good at doing what they say they are going to do.
Making and meeting commitments on a regular cadence is the heartbeat of an agile team.
Any of you guys ever play pool with your kids? When my kids were younger, they’d just walk up the table, quickly eyeball their shot, and do what they could to get the ball in the pocket. Every now and again they’d actually make a shot, but they’d never beat me playing an entire game. They were doing their best, but they never won. To really be successful playing pool, you have to be able to sink the ball you are trying to sink… and do your best to set yourself up for the next shot (or two… or three). Unless you are able to call each shot, you really don’t have any idea how you are going to win the game. Success is accidental at best.
If the team can’t call their shot… in other words, if they can’t predict their velocity at the beginning of the sprint, there is no point doing any kind of forward thinking, any kind of release planning, or even trying to make a guess at what you are going to put in market when. Your product delivery dates are nothing but fiction. Having a stable velocity is the fundamental prerequisite for managing the expectations of the business. It’s essential if you are coordinating with other teams to deliver the release, and essential for making tradeoffs when things don’t go exactly as planned. Stability builds trust with your product owner and it builds trust with your business.
Do what do you think? Is it important for agile teams to be able to call their shots? I think it’s essential.