A while back, I had a podcast with Yuval Yeret is a senior Agile Consultant on the AgileSparks team who focuses on Kanban, Scrum, Lean, and effective R&D in general. See what Yuval says about commitment…
Related Podcast and Transcription: Kanban and Scrum: A Mixed Approach
Joe: That’s interesting, because commitment does seem that when you first hear about Agile, and you look at it, it seems like there’s a lack of commitment…but it’s not really true, is it?
Yuval: It’s not really true, but it’s indeed one of the more common myths around Agile in general. And when you go into Kanban, a feeling that or people think that Kanban has even less commitment than Agile itself for Scrum as an instance of Agile, when in reality, if you look at, let’s start with generic Agile for a minute and their release planning. The issue is that there is viability in the performance of your teams. The team has an average velocity or average performance, and there is a good chance that they will perform more than that average, and there’s a good chance that they will perform less than that average. If you come from Lean and Six Sigma, a control, a control chart is a good way to look at the velocity of a team in Agile.
So the question come up, what do you commit on? Do you commit on the average? Do you commit on the higher control limits, the best case? Do you commit on the lower control limit, the worst case scenario? So, typically, managers ask teams to commit to higher levels. What they say is, if the team will not commit to a high level, then they will not deliver.
If a team commits to a higher level and there is a good chance that it will be hard for them to deliver, then what you get is teams that have unrealistic commitments a good percent of the time. So what do teams do? Teams lower their commitment and lower their actual performance because they know that if they from time to time deliver something that is more than their commitment they will be expected to commit to a higher level and you have a cause and effect that drives performance lower.
What you want to create is a situation where teams commit to something that something is for sure something that they will deliver in the release, in the iteration, it doesn’t really matter. But you have the expectation of a team that if they always deliver on their commitments, that’s OK, but that’s not really good. You want them to deliver on the average and higher most of the time. But just make the separation between the commitment that the teams make and their actual performance.
Joe: Well, I think that’s a lot of just management understanding numbers. The control chart, for example, is a great way look at it and what you want to do over time is raise the average.
Yuval: You want to raise the average, and you want to reduce the variability, improve the predictability of the team. So be able to make more aggressive commitments and have fewer surprises in what you’re doing. That’s something that I’m trying to explain to teams how to do. When you go to the Kanban world in service delivery, you have a similar discussion just with cycle times where it’s maybe a more natural discussion, I would say. You have a cycle time, when you will, the SLA that you can commit on. But if you always meet the SLA then it means that it’s a dangerous SLA because there are some times that you will miss it. So you expect to beat the SLA most of the time.
If you go back to Disneyland, I would expect that most of the time if you see a sign of 30 minutes from here, most of the time it will take you much less than that. The park manager or someone like that will probably be worried if you’re just making the SLA that you want to aim for on most of the days.
Joe: Now, part of this, what always interests me is the estimation part of it because that is so important. We can sit there and say we’re delivering an average; we’re delivering plus or minus, but it’s all based on what you estimated in the first place on what the average, is?
Yuval: Well, actually it depends. Ideally you have items in your Kanban board or in your Scrum screens or in your releases that are more or less the same size. Once you get into the same ballpark, then once you go to big numbers the differences are not that great. So that’s the ideal. But there are many situations where you do have different sizes of things. You have those features which are; I don’t know, 10 days and the features which are 100 days. So obviously, you cannot compare the cycle times or in the release plan treat those features the same way.
What you can do is do just enough estimation to be able to have the amount of accuracy that you need in your plans. If you are committing not to, not based on 100 percent of your capacity in your release, for example, then whether a feature is really 90 days or 120 days shouldn’t be that much of a difference.
What we basically say with Agile is that most of the time when you plan a release, you don’t really know. So you know it’s a 100 kind of thing or a 10 kind of thing, it can be an eight versus a twenty, something like that. The relation between them is what is important, not the actual estimate.
If you have the featured size or the gross, the rough order of magnitude of the feature, then you can use the cycle time numbers that you have or your velocity numbers and see what comes out if you use this feature size. For example, you can say, “I do 10 engineering days per month.” Then you could have a feature of 100 engineering days that you can know it will take 10 months.
Having said that, again if you are able to break those features into smaller pieces and write them one by one, you get a lot of advantages. You reduce the variability. You get a faster time?to?market on the top priority parts of this feature. You get a lot of good things by doing this. I really like what Don Reinersten, the way Don puts it in his product development flow book. Recently finished it, and it’s a very good view of all of the technical principles behind all of this Agile and Kanban thinking.