Reworking the Agile Manifesto

This content is syndicated from [email protected]: Strategies for Scaling Agile Software Development by ScottAmbler. To view the original post in full, click here.

I've recently been working with Mark Lines of UPMentors and we've had some interesting discussions around evolving the Agile Manifesto which I thought I would share here to obtain feedback.  Note that this is not any sort of official position of IBM, nothing in my blog is by the way (unless explicitly stated so), nor is it some sort of devious plot to take over the agile world (although if we did have some sort of devious plot, we'd make the exact same claim).  What we hope to accomplish is to put some ideas out there in the hopes of getting an interesting conversation going.

Over the past decade we've applied the ideas captured in the Agile Manifesto and have learned from our experiences doing so.  What we've learned has motivated us to suggest changes to the manifesto to reflect the enterprise situations which we have applied agile and lean strategies in.  We believe that the changes we're suggesting are straightforward:
  1. Where the original manifesto focused on software development, a term which too many people have understood to mean only software development, we suggest that it should focus on solution delivery.
  2. Where the original focused on customers, a word that for too many people appears to imply only the end users, we suggest that it focus on the full range of stakeholders instead.
  3. Where the original manifesto focused on development teams, we suggest that the overall IT ecosystem and its improvement be taken into consideration.
  4. Where the original manifesto focused on the understanding of, and observations about, software development at the time there has been some very interesting work done within the lean community since then (and to be fair there was very interesting work done within that community long before the Agile Manifesto was written).  We believe that the Agile Manifesto can benefit from lean principles.

Our suggested rewording of the Agile Manifesto follows, with our suggested changes in italics.

Updating the Values of the Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.  Through this work we have come to value:
  1. Individuals and interactions over processes and tools
  2. Working solutions over comprehensive documentation
  3. Stakeholder collaboration over contract negotiation
  4. 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.

Updating the Principles behind the Agile Manifesto
  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.
  2. Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the stakeholder's competitive advantage.
  3. Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  4. Stakeholders and developers must work together daily throughout the project.
  5. Build projects around motivated individuals.  Give them the environment and support they need, and trust them to get the job done.
  6. The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.
  7. Quantified business value is the primary measure of progress.
  8. Agile processes promote sustainable development.  The 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. Simplicity--the art of maximizing the amount of work not done--is essential.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
  13. Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.
  14. Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.
  15. The organizational ecosystem must evolve to reflect and enhance the efforts of agile teams, yet be sufficiently flexible to still support non-agile or hybrid teams.

We're agile -- things evolve, including manifestos.  Looking forward to your feedback (add a comment).

Further reading:

Leave a Reply

What is 5 + 8 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”

DAN PULHAM, DIGITAL DIRECTOR
TELSTRA