Getting Predictable

Last Updated on Tuesday, 18 February 2014 01:42 Written by Mike Cottmeyer Monday, 6 September 2010 08:04

Over the past few weeks, I’ve made two assertions about new agile teams. First… teams need to get good at calling their shots. To me, that means that over time, a well-formed, stable team should get good at being able to predict what they will get done over the course of the next iteration. Second… teams need to get good at knowing the size of their bucket. To me, that means that over time, a well-formed, stable team should establish a predictable cadence of delivery… one where their past performance starts to become a predictor of future performance.

These two things are what fundamentally separates an agile project from total chaos. Without the ability to make and meet commitments, without the ability to look ahead and forecast what might be able to get done… we are asking our customers, our businesses, to make an indefinite investment in a project with no general ideal of what they are going to get when time and money runs out. To me… that is total non-starter.

Learn More

How Big Is Your Bucket?

Last Updated on Thursday, 15 November 2012 12:38 Written by Mike Cottmeyer Friday, 20 August 2010 03:49

A few posts back, I asked if an agile team should be expected to call their shots. In other words, should we expect that over time, an agile team should be able to accurately predict what they’ll be able to deliver at the end of the iteration? My assertion was that predictability at the iteration level is the only thing that separates an agile project from total chaos. Without the ability to make small commitments on a regular cadence, we have no ability to forecast what we can get done.

I’m working with one team right now that has gotten really good at calling their shots… but… people keep getting pulled in and out of the team. Having a stable velocity is predicated upon the team working together, staying together, and learning how to estimate and plan together. The constant churn at the team level is making it really tough to establish a consistent velocity iteration over iteration. While the team is great at calling their shots, they are still not able to really say what they can get done… and by when.

Learn More

Should Agile Teams Have to Call Their Shots?

Last Updated on Thursday, 15 November 2012 12:38 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.

Learn More

Stability first… then speed!

Last Updated on Monday, 19 November 2012 11:15 Written by Mike Cottmeyer Tuesday, 29 September 2009 11:22

So many folks want to flip a switch and magically become agile. They want all the benefits without any of the hard work that comes along with really transforming the organization. People think that just because they read a book… or took a few days of training… that they can expect instant productivity. They don’t realize that agile methods only show you your problems… it is still up to you to fix them.

I’ll often see this thinking manifest in questions like “how many iterations until I can expect my team’s velocity to start going up”. There is so much underneath a question like that, it’s hard to give a solid answer. Is there a prioritized product backlog? Is there a product owner grooming the backlog and available to the team? Is the team cross-functional? Are they dedicated to the project? Do they have everything they need to be successful? Are there external dependencies?

All those things matter… and right out of the gate.. you are not quite sure the kind of impact those answers will have on the team’s ability to deliver.

My recommendation is generally to look at team performance in three phases. The first goal is to measure what is… to establish a performance baseline. Next start thinking about getting stable… stable performance is key to running a predictable agile project. Once you are stable… now you can start thinking about getting faster. Adopting agile is a learning process and you can’t improve a system when you don’t understand what is broken.

And that is really the key… it isn’t about getting a better velocity. It’s about fixing the broken parts of your organization. It’s about looking at where you are and comparing it against where you would really like to be. It’s about understanding the impediments standing in your way and dealing with them in a meaningful way… in a way that really, truly helps the team get better. It’s about getting more efficient at creating value and really improving the processes that allow value to be created.

Those kinds of answers don’t translate into a great marketing pitch. How long will it take to get agile? I don’t know… how many iterations will it take to remove the organizational impediments that are slowing the team down? How many iterations will it take until you are willing to fix what is really broken? How many iterations until we are ready to stop applying labels and start REALLY transforming the organization?

Learn More

Comparing Value and Velocity

Last Updated on Friday, 16 November 2012 12:51 Written by Mike Cottmeyer Monday, 3 August 2009 12:23

Is there a difference between the value a team delivers and their velocity? Said another way… if I increase the velocity of the team… aren’t I getting more value from them over time? Like so many things we talk about here… the answer really depends on your context.

You might be inclined to make the argument that velocity is really just a measure of how many story points the team can complete in a given iteration. There is no explicit dealing with value… only relative size. But… if the Product Owner is prioritizing the backlog… and asking the team to deliver the highest value features first… isn’t there an implicit correlation between value and velocity?

My take is that there is a correlation between value and velocity at the team level… it is when we get beyond the team that relationship starts to break down.

Think about this scenario… let’s say them team is cranking out feature after feature… adding great stuff to the product… their velocity stabilized a few sprints back and is getting better and better every iteration. The company has a great product but a terrible sales team and even worse marketing. While the product is technically superior to their competition… how valuable is it if no one buys it?

You might make the case that all those really cool features ended up having very little value to the market. Great velocity… not so much value.

Here is another scenario for you… let’s say you have four teams that have to work together to deliver a new product suite to the market. Teams A, B, and C have fantastic velocity but team D just hasn’t been able to get their stuff together. Team D ultimately delays the release… and the overall product is late to market. In the meantime… the competition just released the latest version of their product and yours doesn’t do so well.

How much did the velocity of teams A, B, and C help the overall value of your product? Again… great velocity… not so much value.

Okay… last one. Let’s say you have 7 component teams that have to deliver features into several major architectural sub-components. All the teams are rockin‘… they have met all their high level milestones… they know where they need to take their part of the project. One of the teams realizes a significant risk and their velocity tanks. The rest of the teams keep going… they are building great stuff… stuff that certainly has to be built someday… but again… that one team causes us to delay the release.

Most of the teams were doing great… one team not so great… where did all the value go?

Lean tends to take a broader look at value delivery across the entire value stream… across the enterprise… Scrum by it’s very nature tends to look only at the delivery team. So… at the single team level… you can make a great case that there is a correlation between velocity and value. It’s an implicit link, but it is there. When you start looking outside the team… across the entire value stream… that is where the correlation between value and velocity starts to break down.

When the Lean folks say that Scrum focuses on velocity and Lean focuses on value… as I see it… this is the reason why.

Learn More