The Agile Manifesto from a Lean Perspective

First published on Scrum.org, 9 September 2019 (syndicated).

“Everybody has their manifesto; let them talk their language, come to the people, and the people will decide” -- Prakash Raj

So where were you between February the 11th and 13th, 2001?

Well, since you appear to have difficulty remembering, let me narrow things down. There is an excellent chance you were not at the Snowbird ski resort in the Wasatch Mountains of Utah. You were not there because you were not invited. Darn it though, neither was I. The nonexistent wound, inflicted by no-one, can remain the most fresh.

Snowbird. Where “seventeen people met to talk, ski, relax, and try to find common ground”. The result of this buzz session was, of course, the Agile ‘Software Development’ Manifesto. Can we perhaps see into the minds of those who were there? In the published history of the meeting, they claim to have sought consensus, and that they tried to reach a position they could all agree on. Yet as we have subsequently discovered, agility meant -- or came to mean -- something different to each of them. This is inevitable. Each attendee was a different person who brought their own knowledge and experiences. The Agile Manifesto is the work of unique individuals who met in a particular place, and it is an artifact which has withstood the test of time. We are left to decode its inner mysteries, like an ancient stone circle. What was really going through the minds of the builders? Did each perceive the same thing when they created it, in their mind’s eye?

To what extent, for example, is the Manifesto a reflex of “lean thinking”? Along with methods of round-trip development, it was in a sort of ascendancy at the time. There’s a clear synergy between lean and agile practice, and attempts to tease them apart can often seem contrived and artificial. Then again, we know they don’t describe quite the same philosophy or way-of-working.

Interestingly, in the published history of the Agile Manifesto, the word “lean” does not appear even once. Could it be that the authors were influenced by a “lean” gestalt which they saw no reason to explicitly acknowledge? Let’s walk through the twelve principles of the Manifesto, and see if we can examine each of them through a lean lens.

• 1. “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software”. The longer customers have to wait for value to be delivered, the more waste will be incurred in terms of lost time and lost opportunity. The business environment will continue to change, and disruptive competitors may seize the initiative. If a system is allowed to diverge from an evolving and emergent set of requirements, the more likely it is to be viewed as defective when it is finally released. Lean practice is based on delivering the right value, to the right place, at the right time, and at the right level of quality to satisfy customer needs. Requirements are a moving target, and the only thing that genuinely allows us to recalibrate our understanding is the actual release of value. That’s the moment of empirical truth...and the earlier and more often we deliver, the truer to customer needs we can be.

  2. “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage”. The freezing of requirements does not freeze market conditions or the environment in which the customer operates. Moreover, change will happen regardless of whether or not it is captured by analysts. The business environment will continue to evolve, and just as surely, any system requirements will continue to mutate. The supposed fixing of scope just means that customers have to wait before a solution eventually converges with their actual needs. By that time the state of the market will have moved on still further, and so the deployed system will be permanently out-of-date and defective. The work done will solve the wrong problem at the wrong time, and the customer’s competitive advantage stands to be lost. Hence it is vitally important to avoid freezing scope, and to manage requirements change as soon as that change happens.

  3. “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”. The more we delay in releasing software to customers, the greater the leap-of-faith we are forced to take in assuming that the system will meet their requirements. On the other hand, the more often we deliver, the less customers have to wait before functioning software becomes available, and the less likely we are to continue investing in a system that is becoming increasingly unfit for purpose. A good lean approach is therefore to constrain the time we spend before delivering something of value, however marginally incremental it may be. This gives us more and better opportunities to remedy any defects or other non-conformances that emerge. If we deliberately take on less work before releasing an increment, and instead endeavor to release more often, then there will be a reduced chance for work-in-progress to depreciate.

  4. “Business people and developers must work together daily throughout the project”. Whenever an email or similar notification is sent between business people and developers, there is a delay in the other party receiving a response. The time spent waiting for a reply causes the value of the conversation to depreciate. Any non-conformance with requirements is less likely to be communicated and resolved effectively and in time. Also, each ad-hoc meeting that is set up demands that the attendees make arrangements to be there, which is not a productive use of effort. For the leanest possible workflow, it can be advisable to have business and technical people work together every day as a matter of course, in such a way that they are immediately available to each other, and the value of their discussions is maximized.

  5. “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done”. Skilled people ought to go to where the work is, at the time and place it needs doing. If work is passed between them instead, according to their discipline, efficiency will be lost since that person may not be ready to handle it at that time. The way lean initiatives are structured ought to reflect a collaborative sense of professionalism, where teams inspect and adapt their way to an agreed outcome. If work is seen to be building up in one area, then the team will focus on completing it in order to smooth lean flow. Self-organization of this nature can demand cultural change, and hence it is important to support the team in these efforts.

  6. “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”. Having business and developers work together can be an important first step in reducing the time they spend waiting for each other’s input and feedback. It also reduces the need to set up and attend meetings. The potential lean efficiencies can be increased if they all collaborate face-to-face. Non-verbal cues then become available to team members, and it is easier for them to communicate, develop, and pursue a shared focus on the task at hand.

  7. “Working software is the primary measure of progress”. The traditional stage-gated model of software development gauges progress by means of promissory notes. These are typically the analysis, design, testing, and management documents which report on whether or not delivery is on schedule and within budget. Such outputs do not in themselves provide value to stakeholders. At best, they can merely promise that value will be delivered at some future point. The leanest way to evidence progress is through empiricism, by releasing and using working features both early and often. Any non-conformances with stakeholder expectations can then be exposed and dealt with rapidly, and the risk of effort being wasted on unproductive activities is minimized.

  8. “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely”. If wasted time and effort is allowed to accumulate, it becomes harder to maintain a predictable rate of value delivery. Building the wrong thing at the wrong time saps a team’s energy and represents a lost opportunity for them to do genuinely useful work. Overloading the team in an attempt to compensate is not sustainable over time. Quality will deteriorate, further waste will be incurred, predictability will be lost, and eventually the wheels of the initiative may come off. The need to maintain a sustainable pace in lean practice can hardly be overemphasized.

  9. “Continuous attention to technical excellence and good design enhances agility”. Unaddressed defects are a common source of technical debt. By paying close attention to technical excellence and good design, at all times, the chances of that debt growing will be minimized. Reducing the burden of remedial work enhances the ability of lean practitioners to respond to change, so optimal value is delivered. If a team carefully limits the work it has in progress at any one time, members can focus better on completing it to the necessary standard.

  10. “Simplicity -- the art of maximizing the amount of work not done -- is essential”. Delivering new features more quickly than customers can readily absorb is development effort gone to waste. The value brought by that new capability cannot then be realized, and the investment made in its production will depreciate rapidly. The opportunity to invest scarce resources more productively is also lost. Furthermore, unnecessary complexity is introduced to the system, and there is now more to go wrong. A more artful practice is to focus on the things customers need now, and will be in a position to use. The law of parsimony can be expected to hold in a lean way-of-working. There is an imperative to simplify, and to find “ways of doing less so you can do more”.

  11. “The best architectures, requirements, and designs emerge from self-organizing teams”. The value customers receive is only as good as the value stream that generates it. As each increment is worked on by a team, its potential value is increased. Value-adding activities -- such as analysis and design, for example -- are most effective when lean teams self-organize around the work and team members collaborate with each other. They can apply shared experience and joint focus to the challenge at hand, which is meeting customer needs in a timely way. Each specification a self-organizing team has to produce, before value can be released, is more likely to optimize the value customers do in fact receive.

  12. “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly”. If a workflow is to become truly lean, and remain lean, it must be continually inspected and adapted. Everything about a workflow should be open to challenge by the team which owns it. There is no increment they deliver, nor any incidental activity they perform, nor any process they follow, which is immune from their consideration in terms of its empirical outcome.

We don't have a “Lean Manifesto” against which these principles might be compared, and which has gained anything like the same traction. There is however a common understanding that when lean practice is implemented, several types of waste will be challenged. There are various schemes for enumerating the 7 or 8 wastes that lean practice is said to resolve. Let’s pick one of the better known of them, TIMWOOD, and see if we can map the twelve manifesto principles to the kinds of “lean waste” they might help to tackle.