I’ve long been interested in Lean methodology, with my organization being a leader in adopting Toyota management principles in healthcare settings. While the technologies around DevOps methodologies are a treat to work with, the application of Lean principles in traditional enterprises both challenges and entices me. Having just given Humble, Molesky, and O’Reilly’s Lean Enterprise a initial read, I was excited by the announcement that the Seattle DevOps Meetup would be featuring Microsoft’s David Tesar presenting on Value Stream Mapping (VSM).

Apparently I wasn’t the only one, as the turn out at our Chef’s Seattle offices for this meeting were at a historical high with close to 40 folks attending. David did a nice background on the history of Lean, going back to JIT manufacturing from the 1930s, evolving into Lean in 1988, having a breakthrough into the software development space in 2003 and being added into the DevOps CAMS (Culture + Automation + Measurement + Sharing) mantra around 2010 as CALMS (CAMS + Lean).

David presented nine major steps in the VSM methodology employed at Microsoft:

  1. Begin with an architectural overview
  2. Model the process flow “backwards” (from end product back to request), much like a pre-mortem analysis
  3. Notation elements, including annotating the lead time, process time, and wait time
  4. Identification of the scrap rate (number of times a step has to be repeated before success)
  5. Grouping the process flows into logical groups
  6. Reviewing the draft VSM as a narrative story
  7. Identifying waste and pain points in the current as-is VSM
  8. Discuss recommendations to improve the flow
  9. Analyze, present, and establish the action steps to implement the improved flow

For what is a very tricky concept to fully understand, David did a great overview of both the purpose and the process employed while also providing context on the transformation that continues at Microsoft. Shortly after this meetup I grabbed a copy of Karen Martin’s Value Stream Mapping and am working my way through in preparation for a second, more thorough, read of Lean Enterprise. I’m hoping to find more opportunities to talk with folks that have, or are attempting, to transform how their organization’s approach technology development and management. There aren’t enough success stories for traditional non-software focused enterprises out there.