– I was lucky enough to attend the 2009 Agile conference. This post is one in a series of session reports from it.
Presenter: David Anderson
David framed this session with the idea that much of the stated value of Agile is in managing risk. Wanting to dig deeper, he tried to find a good Agile definition of risk or even just some articles treating risk from an agile perspective. He was pretty shocked to find very little published about it, so came up with his own definition:
“The likelihood and magnitude of the difference between a desired outcome and an actual outcome.”
I can live with that. I like that it acknowledges that risk isn’t always bad. Reinertsen tells us that risk is, in fact, good. We take some risks to get the rewards/returns that go with them. DeMarco also talked about this in Waltzing With Bears – a project without risk is a project not worth doing.
David suggested two approaches: manage risk with allocation and manage risk with classes of service.
Managing Risk with Allocation
Prioritization of work is always a chief concern on agile projects. David has “become disillusioned with prioritization schemes, asking the business people to do something they can’t do”. He feels like there is too much uncertainty at too many levels and that uncertainty gets multiplied together to give us bad prioritization advice. I can certainly relate to this in my own work; too often, the decision makers on a project don’t have enough context to make great decisions on priority. Their business units are too silo-ed, with little transparency due to the political dynamics of large companies.
Instead, David proposes taking some ideas from the MBA world. Let’s think of our projects/products/even features in the following terms:
- table stakes – things you have to have to be able to play, such as your network if you’re a cellular provider; they are commodities, undifferentiated
- cost reducers – reduce cost/increase margin
- differentiators – something unique and loved that your customers will pay for
- spoilers – moving in on someone else’s differentiator (push to talk, for instance)
Given these categories, we can think differently about how to tackle these kinds of features/projects/products:
Table stakes are not dynamic … they don’t change out from underneath you in the middle of a project/product. They have to get done, but they aren’t ‘exciting’. He advises getting them done first, and not bothering with agile methods. This commodity work doesn’t need to be done by “highly paid American engineers.” (yeah, he really said that). If you can buy these rather than building, do so.
Cost savers are nice, but similarly non-dynamic. Differentiators and spoilers, however, are quite likely to change out from underneath you. They probably haven’t been done before, or they wouldn’t be differentiators, and you can’t buy them. They are also the things that are likely to drive real value and profits to your company. So … they should be handled with lean and agile methods to deal with the dynamic market conditions.
He doesn’t show it on the graph, but the size of an MMF for each of these classes increases as you move down the chart. This dovetails nicely into managing risk with classes of service.
One caveat I would add to this set of ideas: the environment can get dynamic for table stakes or cost reducers if the target organization is not mature. I have worked with clients that were still sorting out their processes and procedures, assigning roles and responsibilities, and determining their market direction. Lean and agile methods have been tremendously helpful in building software for groups in this situation.
Back to the topic. We can manage our risk by managing the distribution of work in our project/product/company, just as you would manage the risk in your retirement portfolio. I don’t know how much application this has for my teams since we’re not in the product design business, but perhaps we’ll get to observe how our customers do this and eventually provide good advice to them about the mix of features on a project. We can also look at the overall structure of a product development and note incongruities, such as a long development cycle without interim releases on a product with lots of differentiators. Those differentiators are risky, so we should deliver them early and often to see how the customers/market respond.
Managing Risk with Classes of Service
The idea here is really around classes of service as used on a Kanban board. We already use some classes of service (bugs, scenarios, silver bullets, etc.), but I suspect we’re still not doing them at the level he prescribes. Different items have different levels of inherent risk, so we shouldn’t execute them all with the exact same procedure. We can apply allocation thinking again here by limiting the number of each kind of ticket that can enter the system.
He then tied together two concepts I keep hearing about in a nice way:
“Classes of service should be defined according to the cost of delay.”
I’m not the right guy to explain cost of delay, but it really is what it sounds like: what is the quantitative pain that comes from delaying this release one week/month/year/etc. He brought up really valuable point here as well. Cost of delay can often be represented as a curve. We might resist drawing this because we or the business people don’t know the real numbers that should be on it. BUT even if we can’t put specific numbers on it, we/they can probably draw the shape of it, and that alone is very useful thing to have.
The samples classes he provided were Expedite, Fixed Delivery, Standard, and Intangible. I’ll let someone more in touch with classes of service and cost of delay provide more depth there *cough*Shinkle*cough*, but hopefully you can see how this ties in.
What does this have to do with us?
First, David actually called out our very own Chris Shinkle (as well as distinguished alum Eric Willeke) by name in the presentation, wanting them to comment on Kanban’s response to staff allocation. (Sidebar: in a typical project, adding people gives a non-linear {decaying} improvement in productivity; many Kanban teams are showing linear response to adding people.) Being able to adjust our staffing and get linear responses in productivity is a powerful risk mitigation technique.
Second (and this is the big one for me), even if the specific techniques aren’t immediately applicable, this language is fantastically useful in talking to clients. Engineers consistently struggle to talk business value with the business people. This simple framework (diff/spoiler/cost reducer/table stakes) is easy to explain and gives a great basis for discussion. I tried this with a customer we’ve had for eight years (“Hey, I don’t really know where this system fits into the big picture for you. Is it a …”). He was a veritable font of information when pinged this way; I literally couldn’t write down everything he said it was flowing so fast.
The presentation can be found here. There’s a lot more there than I could capture (you understand if you’ve heard him speak). Feel free to comment with further insights you glean from the presentation itself.
