In many "agile" projects I’ve been a part of my strategy was to break off specific functions / use case / stories / whatever and delivery them mostly whole one piece at a time. IE in iteration 1 go deliver order entry functionality, in iteration 2 go deliver product fulfillment.
While this approach help keep delivery efficient by breaking up work into smaller units, it does nothing to help business agility. When delivery a product an agile approach is to look at the product from a truly incremental perspective. What is the minimum that one can deliver right now that would meet some basic objectives of the product, what are the next set that would make the product a little better, and so on until I get that ideal product, one releasable piece at a time.
Using this approach means it’s not enough for teams to develop code each iterations that is production worthy. Rather the entire organization needs to think about releasing products to the market in increments.
For this to work the business needs to train them selves to stop asking if they can get the world a year from now, but if they can get a small piece of the world next week.
A colleague of mine, Alexis Hui came up with a very innovative way to manage this approach on a project that we were running. The approach was to extend our Kanban board with a capability and theme map, illustrated below.
The whiteboard was divided into sections based on major capabilities that the product had to meet. Capabilities were further broken up into major project themes that has numerous theme "attributes". Each attribute could be thought up as a feature that could be revisited numerous times over the lifecyle of the project. Each time the attribute required new work a story would be tagged with the theme and attribute.
Each theme/attribute set would act as a persistent queue, where stories could be placed.
We then used a concept known as a Cost of Delay Function to prioritize stories. Think of a Cost Of Delay Function as a simple way to profile the impact of not doing a story on the business, or in this case the project. COD, also known as Opportunity Cost, is often graphed as a line showing the relationship between impact vs time, the steeper the angle of the line, the worse the impact is over time. COD can represent financial, political, moral, or other impact that could adversely impact the organization.
While it can be very hard for an organization to know the exact impact over time for not doing a particular work item, one is frequently able to allocate the COD into a broad category or profile. When using COD I recommend using color, or annotations to tag work on a Kanban board to identify it’s COD profile.
Because our project was all about launching a new product, we decided to base our COD profiles loosely on market risk.
Orange tickets represented work items that were necessary to launch the most basic version of the product, the COD on this is represented as a straight vertical line. If we did not deliver these by the target date of the first release then the project would be deemed a failure. These were necessary to enter the market.
Beige tickets represented a second pass at the orange tickets, taking mostly manual bare boned functions and automating them, adding better error handling, and other work to make sure that a fully operational product would support more than a limited pilot. This COD was illustrated as an incremental line starting right way, we were losing money everyday these weren’t implemented, and things would get worse the longer they weren’t delivered. These tickets were necessary to support market growth.
Green tickets represented high end features like customer self care, power tools, customizations features, and market grabbing functions such as keeping a phone number when transferring to the new plan. COD here was illustrated much like the beige tickets, but with a delay before incurring losses, and a more pronounced curve on the line, we didn’t need these features right away, but they were quite valuable later on. These tickets were necessary to steal market share from competitors.
Blue tickets represented longer term investments. Completing a blue ticket did not result in a noticeable business impact. Rather work quality would improve. Architecture work, educating the team on agile practices, refactoring, technical docs, were all profiled as blue tickets. These tickets had a straight horizontal line with a slight upward slope to it, immediate value was not obvious to the business, but not doing them would result in downstream pain. These tickets were necessary to ensure that the IT team could continue to support other market needs at a reasonable pace and price.
COD allocations are also dependent on the nature of the business they are in, for example start ups will likely face more extinction level events than blue chips, and have more "warm" colored tickets in flight to respond to these events.
It was typical using this approach to revisit an attribute several times. The first story for an attribute may be a blue ticket involving a spike, POC, or actual design. Subsequent stories for the attribute could involve one more orange and beige tickets, depending on the desire for a mostly manual solution or full automation of a component out of the gate. Later stories would often be a series of blue and green tickets necessary to POC new technologies and implement new functionality necessary to support some high end feature.
The one common theme here is that the simple use of color can be used to convey an awful lot of information with deep meaning to the business, helping delivery support real agility.
If the Kanban card contains a target date, to what extent that will implement CoD?
Thanks! A fixed date would most likely correspond to a COD that is very steep, or even straight vertical line, oe severe impact when the date was missed.
Your post is very interesting! I've translated it into french : Priorisation des Fonctionnalités par le Coût du Retard
I just checked it out,ReplyDelete
C'est magnifique, merci pour votre travaile!
I think the idea of explicitly saying you'll revisit a feature multiple times is great, since that tends to happen anyway. So how do you use these "persistent queues"? Do you decide which story to pull onto your kanban board from among any of the stories at the top of any attribute queue? Can you give a few more examples of what you'd call a Capability vs Theme vs Attribute (say you're writing a job board, like the example here)?ReplyDelete
The theme map wasn't used for FIFO style prioritization, stKeholders had to make intelligent decisions about how to get basic or advanced features across the various themselves and capabilities. Coloring of COD, he led with what was taken from the map and placed into the queue.ReplyDelete
An examp,e of the theme might be order entry for a wireless device, and attribute might be Web Based Order Entry. a story would be the basic capability, then a collection of advanced stories like better back end integration with am order service, and finally premium market grabbing stories like porting numbers from in while ordering
Do you have a picture of this concept in action on a live project? That would be very useful for us to see. AlistairReplyDelete