Value Stream for Business Travelers

TSAThe more I travel, the more I find myself observing how business travel (particularly flying) is a lot like application development. Process the flow of travelers (business value) through a system much like ideas flow from inception to delivery.  When reviewing the processes of  the business traveler (delivery), I keep asking myself why the system has so much room for improvement and why we as participants within it don't fix it.  I notice many travelers do few things that provide direct value (save time).  Rather, we do things that either provide little or no value but are necessary or are just wasteful.

As a business traveler, I want to arrive to a destination as quickly as possible without violating identified constraints.

Constraints: Quality and Cost 

Quality (safety thresholds):

We want to make sure that some knucklehead does not get on a plane and do something destructive.  Rather than quality, the FAA calls this security.  In the end, the underwear bomber who unsuccessfully detonated his skivvies mid-flight is like discovering a severity one bug in Production.  It would have been a lot cheaper, if this guy was stopped at a security checkpoint and prevented from getting on the plane in the first place.  As a result, I have Bubba the TSA Agent measuring me for a pair of pants every time I opt out the body scan. Do these theatrics actually increase quality?  I'm not sure. But I digress. [TSA Removing Body Scanners?]

We want to ensure planes don't fall out of the sky, due to mechanical issues.  In an attempt to ensure we don't go below this quality threshold, the FAA requires airlines to conduct regularly scheduled maintenance on aircraft.  As stakeholders, both the airlines and passengers see maintenance translate as on-time departures.  As this relates to application development, customers don't always think (or care) about code refactoring, fixing bugs, or paying down technical debt.  Still, if they don't want the system to crash or have a delayed launch, this out-of-site process has to take place on a regular basis.

Cost (budget thresholds):

As a business traveler, I expect my costs to fluctuate, based on quality and the speed in which I move through the system.  If I want to move through parts of the system faster, I can pay more.  In the end, local optimization just makes the process seem less painful.  It is, until you get to the next step or stage of the process.

The overall system:

  1. I arrive at the airport (park in the Daily garage) [every 15 minutes a shuttle arrives]
  2. I stand in line at the security (TSA) checkpoint.   [1-30 minutes]
  3. Choice of x-ray or full body scan [pay more for express search] [1-20 minutes]
  4. I opt out? [doesn't necessarily increase quality] [5-10 minutes]
  5. I arrive at gate and
  6. Board flight by "zone"  1st Class, Zone 1, 2, 3 [0-20 minutes]
  7. Fly to destination [varies]
  8. Land at destination and disembark the aircraft [5-15 minutes]

Though you can have several local optimums within the system, like any process we need to look at optimizing the system as a whole.

Look for bottlenecks and address them.  There is a bottleneck if a lead time exists between the start of one of the eight processes listed above and its execution (completion).   A lead time is the latency (delay) between the initiation and execution of a process. For example, the lead time between getting into the security (TSA) checkpoint line (process step 2) may be anywhere from 1 to 30 minutes. In industry, lead time reduction is an important part of lean manufacturing.  In application development, it allows us to shorten our iterations or feedback loops.  In travel, it allows us to get on with our lives with less impact to events happening outside the system.

One way I've seen people shorten the lead time at this process step is to just be ready.   Sounds obvious but you would be surprised.  There are signs and videos leading up to the security area.  TSA instructs you to have your boarding pass and photo identification ready.  They inform you what is allowed and what is not allowed (step 3).  I've seen countless travelers wait until they are at the podium before digging through purse or pocket, only to have a minor panic attack because they can't find a drivers license.

I've seen the same thing with application development.  Teams don't have their work ready and then there are delays in getting it done.


Ready and Done

Are we ready?When leading development teams, I see most of the wasted activities happen during the development phase.  If work is not ready, before the team begins development, there can be delays waiting for clarifications from the business.  If acceptance criteria is not clearly defined, before the team begins development, work can go on and on trying to appease the customer.  What your team needs is a clear definition of "Ready to Work" and a clear definition of "Done with Work".  Though definitions vary from team to team and organization to organization, it's imperative that you do it.  It's also imperative the team writes the definitions, not someone in an ivory tower. As with all of our clients, I stress the need to have a minimal agreement on both definitions before work is started.  When defining both the entrance and exit criteria, all major parties within the team need to be involved, to lower risks that something will be missed.

Below are examples of the definitions or ready and done.  Notice that we consulted Analysts, Testers, and Developers.  For your team or organization, you may consult UX designers, DBAs, Architects or others.  Don't make your definitions overly onerous.  Just create something that is just good enough and go from there.

Example of a Definition of Ready

  • Analyst – User story sufficiently defined and mapped from requirements
  • Tester – Acceptance criteria developed
  • Developer – User story is estimated and no known blocking dependencies exist within the sprint

Example of a Definition of Done

  • Analyst – Working system reviewed and User Story accepted via Automated Test or Manual Inspection
  • Tester – Test cases pass.  All critical and high severity bugs fixed and other bugs identified and tracked
  • Developer – Deployed to test environment and Code Review complete

So, what does your team require as part of your definition of ready or done? Do you have definitions?

As a side note, if you're preparing for the PMI-ACP exam, remember the team is responsible for the definition of done.

Image Sources: Pictofigo