Updating the Agile Manifesto

Stephen Denning (Steve Denning Consulting)

Strategy & Leadership

ISSN: 1087-8572

Article publication date: 21 September 2015

4020

Citation

Denning, S. (2015), "Updating the Agile Manifesto", Strategy & Leadership, Vol. 43 No. 5. https://doi.org/10.1108/SL-07-2015-0058

Publisher

:

Emerald Group Publishing Limited


Updating the Agile Manifesto

Article Type: CEO advisory From: Strategy & Leadership, Volume 43, Issue 5

Stephen Denning

Stephen Denning, a Strategy & Leadership contributing editor, is the author of The Leader’s Guide to Radical Management (steve@stevedenning.com). His essays appear at Forbes.com: http://blogs.forbes.com/stevedenning/.[1] He is a member of the board of directors of Scrum Alliance, a non-profit association of more than 400,000 members.

In the annals of innovation, the Agile Manifesto deserves recognition as a revolutionary management document not just an inventive software development technique. In 2001, software development leaders Jeff Sutherland, Ken Schwaber, Kent Beck and fourteen colleagues got together at The Lodge in Snowbird, Utah and drafted the Manifesto for Agile Software Development, which became a clarion call to software developers around the globe to pursue a radically different approach.

The Manifesto inspired thousands of high-performance teams in hundreds of companies all around the world to produce software in a way that was more responsive to customers’ needs, more productive for the organization and more satisfying for the people doing the work.

The Agile Manifesto favored:

Individuals and interactions over processes and tools. Working software over comprehensive documentation. Customer collaboration over contract negotiation. Responding to change over following a plan.[2]

The Manifesto remains a landmark in software development but increasingly also for management innovation more generally, a radical new way of managing business complexity.[3] Others, however, have seen it as a product of a particular time and place and have been willing to apply the spirit of “inspect and adapt” to the Manifesto itself and explore ways in which it could be enhanced to reflect the realities of today’s marketplace in which “the customer is the boss.”[4]

One such exploration, by Kent Beck in an entertaining talk given in 2010 entitled “To Agility and Beyond,”[#fn5] concluded that while each segment of the Manifesto was a giant leap forward in 2001, the ideas needed updating.

Team vision and discipline over individuals and interactions

In 2001, it was a big advance in software development to realize that the people and the ways they interacted with each other mattered more than following a particular process. So the Manifesto declared that “individuals and interactions” were valued more than “processes and tools.”

Over the years, Beck has found, however, that in developing software in new business lines, “individuals and interactions” are not enough. Each individual in a team in a startup needs to think, not about how good a job he or she can do, but rather, how good a job are “we” doing? The implications of that are that sometimes an individual may need to do less than what that individual thinks is the very best in order for the team to achieve more. So if the individual knows an esoteric technique that is objectively the best, but the rest of the team doesn’t understand it, that individual may need to set aside that technique so that the team as a whole can be more productive.

Individuals interacting have a tendency to optimize their own performance. Beck believes that team vision and discipline that goes beyond individual optimization is necessary to make the most progress together.

Validated learning over working software

In 2001, it was a major advance to realize that working software should be valued ahead of comprehensive documentation. Beck noted, however, that perfect documentation for a frozen system was no help.

Beck argues that in a startup or a new line of business, the problem is not usually one of not knowing how to write the software. The central problem is almost always: how to find customers who are going to pay for what you are building? Working software can be part of the way to answer that question, but it isn’t necessarily the best way. As a result, validated learning is to be valued ahead of both working software and comprehensive documentation.

Customer discovery over customer collaboration

It was a big step forward in 2001 to realize that in the rapidly changing and unpredictable world of software development, collaborating with customers was better than trying to nail down all the details of software development at the outset.

But in a startup or new line of business, collaboration with customers isn’t possible, because by definition, you don’t have any customers. In effect, you have to find out who your customer is. In startups, customer discovery takes precedence over both customer collaboration and contract negotiation.

Initiating change over responding to change

Traditional management tended to believe that the way to do software was to make a plan and then follow the plan. In 2001, it was a big step to recognize that things changed too much and too rapidly for that to be feasible.

But in a startup or new line of business, nothing is changing. Nothing is moving. You have to establish momentum first. Development requires initiating change, not just responding to it.

This is where the risk-avoidance tendencies of bureaucracy can wreak havoc. Bureaucracies don’t want to be responsible for risky endeavors. But there’s no choice. Unless the firm initiates change there is no movement. This is where leadership comes into the picture: a leader takes responsibility, assesses the potential and the risks and initiates change. So in establishing new lines of business, initiating change has to be valued ahead of responding to change or following a plan.

As a result, Beck’s updated manifesto of 2010 validates:

  • Team vision and discipline/over individuals and interactions/over processes and tools.

  • Validated learning/over working software /over comprehensive documentation.

  • Customer discovery/over customer collaboration/over contract negotiation.

  • Initiating change/over responding to change/over following a plan.

Notes

1. This article draws on insights from the author’s blog: http://blogs.forbes.com/stevedenning/

2. http://agilemanifesto.org/

3. Denning, S., “Agile: it’s time to put it to use to manage business complexity,” Strategy & Leadership, Vol. 43 No. 5, 2015.

4. Denning, S., “Innovation: applying inspect and adapt’ to the Agile Manifesto,” Forbes.com, May 4, 2011, http://www.forbes.com/sites/stevedenning/2011/05/04/innovation-applying-inspect-adapt-to-the-agile-manifesto/

5. Beck, K., “Kent Beck talks beyond Agile Programming @ Startup Lessons Learned Conference 2010,” Published on August 5, 2014. http://www.youtube.com/watch?v=d4qldY0g_dI

Related articles