The Lean-Agile Manifesto

Context / Intent for Article

I have seen the Agile movement grow from when we new a fraction of what we have now and didn't have a name for the overall approach. XP and Scrum were gaining ground. We talked about the value of co-location, self-organization, quick feedback and deliveries. Different people had different approach (there were Scrum and XP 'wars' during this time) and the Agile moniker was created with the Agile manifesto. Given that Agile, at the time, was focused on teams and didn't require much management involvement (other than to let the teams self-organize and to not interrupt them) the Agile Manifesto reflected this.

As Agile moved to multiple teams, it was natural to try to expand Agile via current existing Agile methods. So Scrum-of-Scrums was born. Unfortunately, inter-team dynamics are not the same as intra-team dynamics and this method usually only worked in few situations where it was applied.

What was missing was an holistic, systems-thinking approach as well as a deeper understanding of the principles underneath Agile as well as some laws of software development that were not well understood in 2001. Lean provides this. with its foundations of:

• Systems thinking
• Need for leadership
• Focus on removing delays in workflow, feedback, and using information (just-in-time)
• commitment to continuous improvement across the organization
• making all work visible

While Agile provides us with a focus on team improvement, Lean provides us with the bigger context needed for an enterprise-wide view of our work and efforts at increasing our ability to add value to our customers and ourselves.

The Lean-Agile Manifesto

First, I mean no disrespect to the Agile Manifesto. It was an incredible rallying cry for those of us who were doing that was later called 'Agile' by the manifesto. I recollect having troubles naming what we did prior to the manifesto. Once I used the term - iterative, incremental, integrated. It was awkward. Many of us knew what we were trying to accomplish but didn't have a name for it. The Agile Manifesto gave us that name. A few months ago, in A Personal Manifesto, I said I would not try to rewrite the Agile Manifesto.  

The intent of this blog is not trying to do that (although it may appear to be doing so). However, in a few interactions I've had with both aging and entrepreneurial companies in the last couple of weeks, I've seen the manifesto's focus on teams and working software has become impediments to these organizations. While the companies are of varying sizes, a team focus is not the proper solution for them and is currently working against them. While team improvement is critical, a larger view is needed. Some are tempted to use a large framework so they can move forward. While frameworks may be useful at times (both large and small ones) I believe a set of guidelines to use to discover how to improve is ultimately more important.

I have been developing software for almost five decades. Each year the need for effective software and the rate of its development increases. 16 years ago we were in a different world, so to speak. This is due not only to technology improvements that enable faster deliver of software but the incredible pervasiveness of the software itself. We continue to learn and must be willing to adopt new methods.  

I present the following not as a real manifesto. To be candid, I wrote this in about 45 minutes. It's mostly a way to state how we can improve where we come from and to be a point of discussion. I do not feel we need a new manifesto and repeat my statement that had I been at Snowbird in 2001 I doubt I would have contributed significantly to it. But I also believe that holding onto a definition 16 years old for a movement that is increasing in velocity of change, is being used in significantly larger organizations and is now being adopted by people who are often adverse to change is not sensible. While not trying to speak for anyone else, there is a growing community that I believe reflect these thoughts. I am not looking for people to agree or disagree with this. I am looking to start a conversation about what we should be doing. 

Manifesto for Lean-Agile Software Development

We continue to uncover better ways for the faster realization of business value predictably, sustainably and with high quality. Through this work we have come to value:

Optimization of value realized over development optimization

Visibility across the value stream over intra-team collaboration

The ability to respond to change over recognizing the need to change

Flow over small batch planning

Continuously looking for methods of improvement over using proven practices

Empowering the people doing the work to make decisions over command and control structures

That is, while there is value in the items on the right, we value the items on the left more.

Principles behind the Lean-Agile Manifesto

We follow these principles:

1.  Our highest priority is the realization of customer value via quickly, predictably, sustainably and with high value through a focus on identifying the minimum business increments that can be realized and ensure every knows what these are.

2.  Allocate your capacity to work on the more important items before working on items of lesser importance. Accomplish this through effective management of work in process.

3.  Have teams work as part of a bigger whole. They must put the priorities of the organization above their own by attending to the effect their work has on other teams and groups both upstream and downstream of them. Their focus must be on value realized, not demonstrating their software.

4. Recognize that systems thinking is essential and that most of our errors come from ineffective systems. 

5.   Management's role is to create the eco-system within which developers can manifest the strategies of the business.  Leadership, management and those doing the work must work together daily. Everyone must foster an environment of trust and recognize that people are inherently motivated, although bad systems may obscure that fact.

6.   The most efficient and effective method of  conveying information to and within a team is face-to-face conversation.

7.   Value realized is the primary measure of overall process. Working software is the primary measure of team process.

8. Sustainability is key. This can be achieved by attending to visibility, managing work in process, improving the eco-system of the organization and an overall agreement to work together for value realization. Sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. A focus on eliminating delays in workflow, feedback, and timely utilization of information is essential

11. Authority should be pushed down in the organization to enable those doing the work to make decisions about how to do their work

12. At regular intervals, all roles reflect on how to become more effective, then tunes and adjusts their behavior accordingly.