My Lean Philosophy

Charting Your Course

Over time I have come to realize that Agile as a framework is not actually about software engineering at allAgile was not created as a result of any problem with actually coding, testing, or deploying software.  If Agile is not about software engineering, what is it about?  It’s about software delivery.  And what is the real problem that we are trying to solve?  The real problem is that software development is not a deterministic system that can be analyzed like a Toyota production line.  Both uncertainty and flux are the elements that create problems for product managers and software developers.

  • Uncertainty because no matter how much market research you try to do, and how much business analysis you do, it is just a fact that building useful, valuable software is difficult.  At the end of the day, because the market cannot be directly observed, the market is essentially unknowable, and the best we can do is to form hypotheses and then test those hypotheses in the market.
  • Flux because it takes time to bring software to market, and during that time there is constant change in the market, in customer behavior, and in technology.

The Framework

The Requirement Dimension

The requirements dimension captures how software requirements are discovered and elaborated. At one end, the top of the diagram, requirements are discovered through analysis. Business analysts, product marketers, and others, analyze and study user behavior and market needs, to determine the software requirements. Business analysts, user experience designers, architects, and developers, design the systems to meet the market needs. At the other end of the spectrum, market needs are discovered from the market through experimentation, and instead of up-front design, the requirements evolve as adaptations to the market needs.

The Budget and Schedule Dimension

The budget and schedule dimension determines how the planning for the software development process occurs. At one end of the spectrum, detailed plans are created that are then used to predict the outcome. The quality of the plan is considered important and the objective is to ‘work the plan’ to meet the predictions of budget and schedule. In contrast, at the other end of the spectrum, constant inspection of the current state, and revisions in the forecasted plans are made continually. in the words of Eisenhower, “planning is everything…plans are nothing”. Plans are not things to be worked, but are merely useful forecasts, to be abandoned when disproved.


A waterfall process is one where each phase is completed, prior to the next one starting. Work cascades from one phase to the next. Where it is possible to analyze and design the requirements up-front, then detailed plans can be created for the subsequent phases. Good practice, under these conditions, suggests that quality can be improved by ‘planning the work, and working the plan’.

Scrum/XP and Kanban

The so-called light development methodologies that were developed at the end of the last millennium replaced predictive planning with adaptive forecasting. Under this system, the plan itself would be replaced with a simple cadenced and flow-based work-stream. ‘Working the plan’ was replaced by a series of short-term sprints, or iterations.

Lean Start Up

Lean Start Up is used here to define a technique where analysis and design is supplemented, or sometimes entirely replaced, with hypothesis-driven experimentation. Often Scrum and other earlier forms of Agile lack rigorous market feedback, relying on proxies such as the product owner. The rise of continuous delivery, the ability to near-instantaneously deploy code to production has enabled Lean Start Up to become suitable for any-sized development.


To be truly adaptive, it is necessary to achieve the serial delivery of value under conditions of uncertainty and complexity. Such responsiveness requires the whole value-stream to be working at a regular cadence. This cadence gives rise to ‘flow’, where work-in-progress in every part of the organization is managed and controlled. Lean/Agile represents the break-out of Agile from the Technology department, to the entire C-suite.