Profiles in Cost-of-Delay: “Intangible Fixed-Date”

TL;DR
  • The “Big Four” cost of delay profiles (a.k.a. archetypes) — Expedite, Fixed-Date, Standard Urgency, Intangible — are usually sufficient.
  • In my personal kanban, I have seen a new archetype emerge, one that has aspects of both Intangible and Fixed-Date, which I’m calling “Intangible-Fixed-Date.”
  • This profile is less for the purpose of selection and more for scheduling.
  • So far, the main application of “Intangible-Fixed-Date” for me is for buying airfare, whose cost-of-delay curve fits none of the “Big Four” curves.
  • I use a couple of features in Kanbanize to deal with this new profile slightly differently from the other profiles, namely by creating a separate swim lane and using two dates (rather than one).
  • Takeaway: “Listen” to your data, patterns and behavior of work items and be flexible enough to adapt and create new profiles when they emerge.

I routinely use cost-of-delay to assist in scheduling, selecting and sequencing work, both in professional settings and in my own personal life. The “Big Four” cost-of-delay profiles (aka archetypes) promoted in the Kanban community — Expedite, Fixed-Date, Standard Urgency, Intangible — are usually sufficient for the work that organizations, teams and I personally need to handle. However, lately in my personal kanban, I have seen a new archetype emerge, one that has aspects of both Intangible and Fixed-Date, which I’m calling “Intangible Fixed-Date.”

Basically, the new profile has arisen from the need to handle airfare purchasing, something that I do somewhat often. Since I’m not independently wealthy and I like to do right by my employer when I’m traveling on business, I care about the cost of airfare. Anyone who travels knows that there is some optimal time to buy airfare (even if he or she doesn’t know exactly when that is). I want to be able to research fares just-in-time to get the best deal. However, if I model the task as a simple fixed-date item, I either have to use the true date by which the cost-of-delay is unacceptable (that is, the day I need to be somewhere) or use a fake deadline. I typically added the task to my Fixed-Date lane with its true deadline, then would occasionally check it to see if it “felt” like I should act, but it was too easy to forget about it until past a responsible moment, even if it wasn’t the last responsible moment. Which brings us to the crux of the problem: This type of item has two last responsible moments, the financially last responsible and absolute last.
Let’s review the cost-of-delay curves of the existing profiles:

COD expedite

Expedite

COD standard

Standard Urgency

COD intangible

Intangible

COD fixed date

Fixed Date

According to the reliable Andy Carmichael and David Anderson in their Essential Kanban Condensed, Fixed-Date items “have high impact but only if you miss the deadline. The scheduling imperative here is to make sure you start before the last responsible moment and deliver before the deadline.” Also, you don’t get any economic benefit from completing the work before the deadline. In software delivery, this usually means understanding how long it can take you to complete the work (see your handy delivery-time histogram), then backing up from the deadline from there based on risk tolerance. However, booking airfare doesn’t take much time (I can do it in a few minutes) — so that’s not a concern. But the deadline only represents the absolute last responsible moment, so this curve is insufficient.

If airfare price increases were linear, I could use a standard urgency profile blended with the fixed-date. But some basic research shows that price increases have an inflection point somewhere around the 30-day mark, although the lowest prices may occur earlier:
airfare-prices-graph
CheapAir-2013-Domestic-AirFares2
Other factors matter, too, of course (seasonality, specific locations). But I don’t need to get too deep into modeling that yet — I just need a better solution. That means incorporating the Intangible curve, whose items “have an apparently low urgency,” but that indicates “a rise in urgency – possibly a steep rise – will happen in the future.”
My airfare purchases exhibit aspects of both curves, though neither is sufficient. Unlike a typical intangible item, I actually do know when that future date will be, along with a rough idea of when the “rise in urgency” will happen. And unlike a typical fixed-date item, there is some economic benefit from doing it sooner than the deadline.
COD intangible fixed-date

Intangible Fixed Date

Now that I understand the cost-of-delay curve, I need to be able to handle it in my kanban system. One approach that I’m trialling is to create a separate swim lane — “Intangible Fixed-Date” — and use a second date to signal readiness (the second date being my optimal time to commit).
Here’s how it works: Say I find out on Sep. 6 that have to be in Chicago on Nov. 6. That’s two months away. Given that airfare cost won’t typically rise until about 30 days out, I don’t want to worry about this yet, which is to say, I don’t want this card on my Requested column yet. So I set up a rule in Kanbanize (my work-visualization tool of choice) to keep it in the backlog until 35 days out (the five-day buffer allows me some flexibility), at which time it moves the card from the backlog to Requested.
It has the ultimate deadline — Nov. 6 — displayed on the card. But since it’s in its own swim lane, I have an explicit policy that I begin work on these items as soon as they appear in Requested.

Screen Shot 2017-10-05 at 12.52.01 PM

If I want to really be disciplined, I can then set a service-delivery expectation that sets the bar for how well I handle these (e.g., 90% of Intangible Fixed-Date items will be completed within five days), and analyze my performance at my personal service-delivery review. But now I fear I’m exposing just how geeky I am (if that wasn’t clear already)!

So what’s the takeaway? Well, you might find value in this “new” cost-of-delay profile (if you need to book airfare, or to plan birthdays or anniversaries, which follow a similar curve). But abstracting out a bit, the idea is that it’s helpful to pay attention to — “listen” to — your data, patterns and behavior of work items and be flexible enough to adapt and create new profiles when they emerge. Pursuing incremental, evolutionary change is one of the underlying principles of kanban method; improve using models and experiments is one of its core practices.

Special thanks to Prateek Singh, Josh Arnold and Mike Burrows for their early feedback in the Lean Agile and Beyond Slack community.

 

Advertisements

Theory of Constraints in the Wild: Queuing for the Tube

Tube queuing after the Tottenham match at Wembley

Tube queuing after the Tottenham match at Wembley

When a WWT colleague invited me to the Tottenham – CSKA Moscow Champions League match Wednesday, he treated me to more than simply world-class soccer — he unwittingly gave me a chance to see Theory of Constraints in action: after the match, while we waited for a Tube ride.

Theory of Constraints tells us that every system has a single constraint — which is anything that limits a system’s performance relative to its goal — that governs its throughput. A particularly effective way of dealing with a constraint (aka bottleneck) is Eli Goldratt’s Five Focusing Steps, which I talk about this way:
  1. Identify the constraint
  2. Optimize the constraint
  3. Subordinate everything to the constraint
  4. Add supply to the constraint
  5. Goto 1
If you’ve ever been in London during rush hour, Step 1 is easy: The constraint is the supply of train cars. At busy times, London simply has more people needing to ride than it has trains to take them. Step 2 is fairly straightforward: We optimize the constraint by ensuring that the constraint is
  • always busy (Londoners are particularly adept at squeezing as many people as can fit into the car, so this is never a problem!), and
  • is only ever doing “value-adding” work, which in this case is moving passengers forward (as opposed to failure demand, which doesn’t typically happen in the Tube in the form of redoing work — going backward — but does often take the form of people getting their bags or themselves stuck in the doors).
That’s where Step 3 comes in. Only after we’ve properly satisfied the first two steps, we want to subordinate — which is simply to adjust the speed of things arriving to the constraint and departing from it to match the cycle time of the constraint. For the Tube, that means making sure that when a train stops, the platform has enough room for the passengers to spill out and leave the station. But the more vital subordinating occurs upstream — such as after the 62,034 fans emptied out of Wembley Stadium and headed for the nearest Tube station. That’s what happened the other night, as the photo shows: Tube security personnel created multiple upstream “batches” of people by holding up signs with either a red Stop or green Go (an indicator of capacity, a kanban). Only when the batch of people saw the green could they advance to the next “gated” area and finally onto the platform. This is exactly the “pull” behavior that an explicit  work-in-progress limit encourages in knowledge systems: Rather than pushing as much work forward toward the constraint, we wait to advance new work until we get the signal, which indicates we are now under our WIP limit and therefore have capacity.
The result was a very orderly movement of people through the station and into the trains, avoiding the evil of overburdening and its demon spawn of waste, unpredictability and delay (and in this case, possible physical harm). This was good enough for the problem at hand; Step 4, add supply, is likely too expensive because it means adding trains to the line for what is essentially an exceptional case (a mid-week soccer match at Europe’s second-largest stadium). In any case, the result is testable, in that we can review the three TOC measures to see if any improved:
  • Throughput (should go up)
  • Operational Expense (should go down)
  • Inventory/WIP (should go down)
Presumably, the London Tube officials have indeed tested whether the practice of subordinating has improved the situation. My guess is that the practice has increased throughput, while holding steady their operational expense and WIP (which is irrelevant in this case). It has probably also improved human safety.
Seeing flow in the physical world — especially when we’re personally involved! — is usually obvious. Knowledge work, on the other hand, is by its nature invisible, so we need special lenses to see bottlenecks in order to manage and improve flow. Thankfully, we have aids such as kanban boards and cumulative-flow diagrams that make visible the flow of work — work in progress, throughput and average approximate delivery time. It’s also helpful to be aware of physical manifestations — such as post-match queuing for the Tube — to train ourselves to look for flow, inhibitors to it and ways to manage it.