In an effort to extend the Agile Manifesto to non-software products and management, experts at the 2004 Agile Development Conference developed The Declaration of Interdependence. Alistair Cockburn details the DOI’s six principles and how they can benefit your organization.
At the 2004 Agile Development Conference, a number of project, product, and management experts started working together to answer the question “How would you extend the Manifesto for Agile Software Development to non-software products, project management, and management in general?” Their answer is a document called “The Declaration of Interdependence.”
The group included two of the original Agile Manifesto authors (Jim Highsmith and Alistair Cockburn); noted authors in product management (Preston Smith), project management (Robert Wysocki), and teamwork (Chris Avery); plus others in industry and consulting from both Europe and the US (David Anderson, Sanjiv Augustine, Mike Cohn, Doug DeCarlo, Donna Fitzgerald, Ole Jepsen, Lowell Lindstrom, Todd Little, Kent McDonald, and Pollyanna Pixton).
The Agile Manifesto (2001)
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That Is, While There Is Value In The Items On The Right, We Value The Items On The Left More."
The Declaration Of Interdependence (2005)
"We Are A Community Of Project Leaders Highly Successful At Delivering Results. To Achieve These Results:
- We increase return on investment by making continuous flow of value our focus.
- We deliver reliable results by engaging customers in frequent interactions and shared ownership.
- We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
- We unleash creativity and innovation by recognizing that individuals are the ultimate source of value and creating an environment where they can make a difference.
- We boost performance through group accountability for results and shared responsibility for team effectiveness.
- We improve effectiveness and reliability through situationally specific strategies, processes, and practices."
The difference in style between the Agile Manifesto and the Declaration of Interdependence (DOI) is notable. The Manifesto is memorably terse and is followed by twelve rarely quoted principles. The DOI, on the other hand, is comparatively wordy, but the six principles capture all the authors intended.
The DOI highlights what its authors feel are the most important aspects in management and were selected for three criteria. Each point is of critical importance—we can't remove any one point. Each principle contains something new, different, or surprising to mainstream managers. Finally, the full set of principles captures the personal operating framework of each of the DOI authors.
Do the six points sound like platitudes? Perhaps it's because—unlike the Agile Manifesto—the DOI doesn't name the “bad guys.” For many, it is only when they try to apply the DOI that surprises pop up and the depth of the DOI is revealed.
In this article I'll highlight some of the surprises in the DOI. As with the twelve principles of the Agile Manifesto, there are some clauses that are still a stretch for me. But the DOI shows me in which direction I ought to stretch myself.
“We Increase Return On Investment By Making Continuous Flow Of Value Our Focus.”
The key and surprising words here are "continuous flow of value."
Lean manufacturing teaches us that having large inventories is inefficient. It also teaches us that the overall efficiency of a process improves as the batch size passed from stage to stage is reduced. Today this has become accepted in most (but not all) manufacturing circles, yet many people may be surprised that it also applies to software development.
When developing software, the unit of "inventory" is the unvalidated decision. This means that every written requirement; architectural decision or document; design drawing, decision, or document; and piece of written code counts as inventory until it is integrated and tested. Donald Reinertsen's Managing the Design Factory gives a convincing rendering of