Should Agile Teams Have to Call Their Shots?
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.
Comments (4)
Peter
So basically what you're saying is that estimates of velocity can't really be estimates?
D. André Dhondt
What happens if a team is working in a continuous flow mindset? That is, every story is relatively small, and we're not really worrying about estimates at all–we're just doing the most important things first… In this case, calling the shots is not as important.
Mike Cottmeyer
Peter,
Initially velocity is as estimate, but at some point it has to converge to something meaningful and predictable… if not, there is no point in measuring… it doesn't tell you anything.
It is also worthwhile to understand what I really mean when I say it needs to be predictable. I'm not saying you use velocity as a tool to beat up the team when things don't go as planned. But it should be used, by the team, as a tool to understand why there is so much variability in the system.
One last thing… I'm also not looking for absolute precision… more directional correctness over time. It doesn't have to be exact, but it does need to be stable enough that I can start using past performance as an indicator of future performance.
Make sense?
Mike Cottmeyer
Andre… calling the shots would still be important, it's just that what you are calling would look different. In your scenario, calling the shots would mean being able to establish classes of service for 'like sized' features and getting the class right most of the time. It would be about having predictable lead times and cycle times. Rather than considering the sprint 'batch' a shot, you would look at how you are averaging with each feature over time.
And you know what… if your customer doesn't care, I'm not asking you to care either. It just depends on how predictable your system needs to behave to meet your customers expectations.