Lean emphasizes seeing the whole, including the end-to-end view of the delivery pipeline – not constrained by organizational boundaries – and delivering as fast as possible. Lean also emphasizes the “amplification of learning” through techniques such as retrospection and mentoring, in order to increase the effectiveness of people – and therefore the speed at which work can be done.

 

Lean promotes the concept of amplified learning, through mentoring and focused efforts to have people learn by doing with appropriate supervision. Agile also promotes the concept of a sustainable work pace, which promotes quality and excellence because people have the energy to pay attention to doing things right instead of rushing things through. This means that work must be planned in a way that does not over-promise, and that is based on actual measurement of work capacity instead of aggressive externally imposed deadlines. Rushed work leads to re-work, and does not save time in the long run.

USCIS Agile Guidelines, with support by MITRE

Stanford professor Steve Blank’s 2013 Harvard Business Review article: Why the Lean Start-Up Changes Everything outlined lean start-up techniques and how they could ignite a new entrepreneurial economy. If you replace “start-up” with “acquisition program”, Blank’s article outlines how Lean techniques can enable faster, more successful solutions:

The “lean start-up,” favors experimentation over elaborate planning, customer feedback over intuition, and iterative design over traditional “big design up front” development. New ventures of all kinds are attempting to improve their chances of success by following its principles of failing fast and continually learning. And despite the methodology’s name, in the long term some of its biggest payoffs may be gained by the large companies that embrace it.

In acquisitions, the conventional wisdom is to define a program’s requirements and acquisition strategy upfront to describe the operational challenges and proposed solution. Budgets are determined early, often with a two-year lead time for Congress to appropriate funds. These plans are written before the system is developed based on the assumption that the program’s design and risks can be worked out ahead of time. After 5-10 years of development, developmental test, and production of initial quantities, users are first able to see the system in operational test. It is at this point when agencies realize the program’s features don’t effectively address the operational challenges as they weren’t effectively defined upfront or the environment has changed significantly over the last decade.

Steve Blank and Hacking for Defense (H4D) have tailored the Business Model Canvas for DoD to be the Mission Model Canvas.

Actions You Can Take

• Visit customer organizations to meet face-to-face with end users to understand their environment, frustrations, constraints, new threats, and operational priorities. Use this insight to scope potential solutions.
• Discuss key terminology with users – especially the rapid acquisition and agile software development environments. Remember, users are not necessarily acquisition system experts.
• Tailor a business model canvas for your program to understand who your true customers are, what they value, the key activities, resources, and partners you need to deliver a solution. Share and iterate a succinct canvas (a one page version is preferred over a lengthy document) with many stakeholders.
• Make investments in rapid prototyping and experimentation to share notional solutions with users to solicit their feedback on features, tradespace, and design considerations.
• Establish a regular collaborative environment (face to face, VTCs, discussion forums, email) to engage users, testers, and maintainers as part of a continual learning mindset throughout development.

References

• The Lean Startup by Eric Ries
• Business model canvas
• Lean Launchpad, Steve Blank
• An Innovation Insurgency, Defense AT&L Magazine, Apr 2018