Continuing with my series about the 7 key principles of lean software development, here are my comments on Lean Principle #4 – Defer Commitment. I’m not sure I really like the name of this one. It could easily be misunderstood. It doesn’t mean you should put off committing to anything indefinitely, or defer all decisions […]
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:
- 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.
- 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.
- Where the original manifesto focused on development teams, we suggest that the overall IT ecosystem and its improvement be taken into consideration.
- 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:
- Individuals and interactions over processes and tools
- Working solutions over comprehensive documentation
- Stakeholder 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.
Updating the Principles behind the Agile Manifesto
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable solutions.
- Welcome changing requirements, even late in the solution delivery lifecycle. Agile processes harness change for the stakeholder’s competitive advantage.
- Deliver working solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Stakeholders and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a delivery team is face-to-face conversation.
- Quantified business value is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
- Leverage and evolve the assets within your organizational ecosystem, and collaborate with the people responsible for those assets to do so.
- Visualize workflow to help achieve a smooth flow of delivery while keeping work in progress to a minimum.
- 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).
Ron Jeffries has written a nice article on some of the effects, both positive and negative, of the Certified Scrum Master (CSM) program. On the positive side, he notes that it does interest people in training. I’m less optimistic that the training they receive will result in many improved projects. The CSM training teaches people […]