The Agile Manifesto Reexamined
The birth of the manifesto
Recently, Per-Magnus Skoogh (co-founder of Agile Extreme and co-author of this article) invited me to meet Arie van Bennekum. Arie is one of the co-authors of the Agile Manifesto that was written by 17 independent thinkers in February of 2001 at a ski resort in Utah, USA.
What these people all had in common was their growing frustration with the way software was being developed. That’s why they came together to see if they could find some common ground on how to change that. The result was the Agile Manifesto, a set of 12 guiding principles for software development.
Agile as an umbrella
One key takeaway from meeting with Arie, and that we both agreed on, was that Agile is not a method. Instead, it’s an umbrella term or mindset under which all agile methods can be grouped. That’s why Arie talks about being “Agile agnostic”. The Agile method or methods that your team chooses is less important than being disciplined in sticking to the underlying principles of Agile.
Agile coaches who religiously follow only one method, e.g. Scrum, XP, FDD, or DSDM, while launching one-sided critiques on other methods, such as ASD, Crystal or LSD, are limiting themselves and others.
What has happened since the manifesto?
Since that meeting in 2001, Agile ways of working have come a long way, and so has the field of innovation. A few examples are:
- In 2003 Clayton Christensen first introduced the term “Jobs-To-Be-Done” (JTBD) in his book The Innovator’s Solution.
- In 2005 Steve Blank published The Four Steps to the Epiphany where he introduces the concept of “customer development”.
- In 2010 Alexander Osterwalder and Yves Pigneur published Business Model Generation.
- In 2011 Eric Ries publishes The Lean Startup.
Parallel to this, we have also seen:
- Design Thinking gaining widespread popularity within the business community with pioneers such as Tim Brown of IDEO and Thomas Lockwood of DMI having paved the way.
- Outcome-Driven Innovation (ODI), pioneered by Tony Ulwick of Strategyn, and which heavily influenced Clayton in his own thinking around JTBD, has also begun to see more widespread adoption.
The backlog is what has happened
So, what does all this mean?
With the risk of oversimplifying, us old "agilists" that began working with defined agile methods in the mid-1990’ must admit one thing. We did not spend too much time trying to figure out how to build a business-friendly backlog (the job-to-be-done). We just assumed that the product owner and her magic would create wonderful products by picking things right out of her head.
Well, that was not, many times, good enough. The business and product owners were not always able to define the perfect product backlog - more help was needed. And … voilà - along came the lean startup, business modeling, and much more. These approaches help us figure out what should be in the backlog, and to verify faster if the assumptions that we are making are correct.
Reexamining the manifesto
Altogether, JTBD/ODI, Lean Startup, Business Modeling, and Design Thinking have started to merge, or at least borrow concepts and ways of working from each other. And that’s good - that’s the way it’s supposed to be.
Methods should constantly be subject to refinement and adaptation to better fit current circumstances - be it cultural or organizational - while principles and underlying values should not change all the time.
With almost 20 years since the Agile Manifesto was written, let’s now reexamine the 12 principles to see how they have stood the test of time.
1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
The focus on software limits the potential to innovate and deliver customer value. Software should be discussed within the context of business models and the JTBD. Although software, or “high-tech”, has meant a great deal for scalability and measurability, there are instances where low-tech solutions can be superior in delivering customer value.
There’s also an important distinction to be made between “satisfied” and “loyal”. Customer loyalty is directly correlated with lower churn, while customer satisfaction perhaps less so. Frederick Reichheld makes a powerful case for this in his book The Loyalty Effect published in 2001 (the same year the Agile Manifesto was published).
Proposed change: Our highest priority is to create loyal customers through early and continuous delivery of customer value.
2. Welcome changing requirements, even late in development.
Yes, it’s better to “pivot” late than never to “pivot” and die. This has a lot to do with letting effectiveness (= doing the right thing) take precedence over efficiency (= doing the thing economically). Or as Alberto Savoia would say “It’s more important to build the right it than it is to build it right”.
Proposed change: None
3. Deliver working software frequently from a couple of weeks to a couple of months, with a preference to the shorter timescale.
The focus on software limits the potential to innovate and deliver customer value. When we focus on software, which is a solution, we tend to forget about the problem or JTBD that we are solving for and if we’re addressing the right customer.
Proposed change: Remove since it has already been covered under point 1.
4. Business people and developers must work together daily throughout the project.
Business people usually don’t know how to code or develop software so why are they needed here? Well, it’s to ensure that the software that’s being developed meets the purpose of the business and its customers, i.e. all stakeholders.
We’d also like to kill off the word “project”, now that there is overwhelming agreement that permanent teams are the way to go. We send temporary work to permanent teams; we don’t create project teams around temporary work.
Proposed change: Developers, customers, and stakeholders must work together daily throughout delivery.
5. Build projects around motivated individuals. Give them the environment and support they need and trust them to get the job done.
Since the Millennials (a.k.a. Generation Y) started entering the workforce in 2000, the focus has shifted from doing what you are told to do, to understanding what the company stands for, it’s mission and values, and how that aligns with your own purpose in life.
In 2009 Daniel Pink published Drive where he spoke about the importance of purpose, mastery, and autonomy as key factors of high-performing teams.
That same year Simon Sinek published Start with Why – How Great Leaders Inspire Everyone to Take Action, where he talks about the importance of inspiring people by a sense of purpose, or “Why”, before communicating the “What” and “How”.
“Motivation” used to be extrinsically forced upon us to become something that is intrinsically discovered and understood.
A consequence of this is that trust must go hand-in-hand with accountability. The more empowered that we become, the more responsibility we must accept.
Furthermore, transparency is a two-way street - teams need to be transparent and accountable to their surroundings, with stakeholders and supporting structures responding in kind.
Proposed change: Build teams with a shared purpose. Give them the environment and support that they need. Trust them and hold them accountable to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
If the aim is high performing teams it helps if we can have them physically in the same room. When teams grow and time zones become stretched, this can pose a challenge. Although modern communication technologies have helped to alleviate some of these challenges, co-locating people from different time zones to sit together is often a great way to boost productivity.
Proposed change: None.
7. Working software is the primary measure of progress.
Software is just a means to an end. If we focus too much on the means we may lose sight of what really matters. Hasn’t that been, and to some extent still is, the biggest weakness of some “Agile” teams?
Let’s not forget the wise words by Theodore Levitt:
“The purpose of a business is to get and keep a customer. Without customers, no amount of engineering wizardry, clever financing, or operations expertise can keep a company going.”
and...
“People don't want to buy a quarter-inch drill. They want a quarter-inch hole.”
We can also take this one step further by considering that software through IoT and Ai will have a serious environmental impact by controlling the inputs and outputs of the physical world beyond our understanding.
More time should be spent on discussing the values, ethics, and actions that maximize human well-being, and less on how to achieve ever greater efficiencies, economic growth, and profit maximization. Let’s not forget what our true North star looks like or should look like.
Proposed change: A working product, solving real customer needs, is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsor, developers, and users should be able to maintain a constant pace indefinitely.
In the Agile Manifesto “sustainable development” mainly referred to not over-working your people and keeping to a 40-hour workweek, thereby enabling teams to “maintain a constant pace”.
Increasingly over the years sustainable development has taken on a new meaning, perhaps best defined in the Brundtland Report as “meeting the needs of the present without compromising the ability of future generations to meet their own needs”.
Proposed change: Agile processes promote sustainable development. The sponsor, developers, and users should be able to maintain a constant team-friendly pace indefinitely, without compromising the ability of future generations to meet their own needs.
9. Continuous attention to technical excellence and good design enhances agility.
This has to do with reducing delays. If what we develop is filled with bugs, or is poorly designed, the result will be delays during testing, deployment, and adoption. And without adoption, there can be no innovation. But we should also not forget that a great product must merge with a successful business model.
Proposed change: Continuous attention to technical excellence and good design of the product and it’s supporting business model enhances agility.
10. Simplicity—the art of maximizing the amount of work not done—is essential.
“Maximizing the amount of work not done” combined with “failing smart” is the essence of “lean”. Control that backlog and focus on a few priorities at a time.
Proposed change: None
11. The best architectures, requirements, and designs emerge from self-organizing teams.
This is as true today as it was back in 2001. When we try to build architecture on the enterprise level, more coordination is needed. It is not sensible for the customer or the company to allow teams to create architecture without first having considered the full picture.
Proposed change: The best architectures, requirements, and designs emerge from self-organizing teams that have found a balance between focusing on its own universe and understanding the larger enterprise that they are part of.
12. Regularly, the team reflects on how to become more effective and adjusts accordingly.
How many of you have run poor retrospectives or even skipped them altogether? Just as we are learning about the needs of the customer and what our value proposition should look like, we must also continuously learn about how we can best work together as a team, or team of teams.
Proposed change: None
Conclusion
- “Agile” is no longer only about software or the reserved domain of software developers. Instead, all domains can and should benefit from a more agile mindset.
- Agile is no longer just about teams – we now do agile in large organizations.
- Agile in 2001 assumed that the product owner or customer could define the product backlog. This is not easy! Thankfully, we now have several frameworks for innovation and business modeling that can help the product owner with her job.
Therefore, we need to continue to frame our discussions under the banner of organizational agility with software agility forming a subset of that.
New frameworks such as Modern Agile, created by Joshua Kerievsky in 2015, and the Scaled Agile Framework (SAFe) are clearly moving in this direction.
A final observation is that the Agile Manifesto was written by 17 men. We guess that if it had been written today it would have been slightly more gender-balanced. At least we hope so.
Andy Cars and Per-Magnus Skoogh
Andy Cars is the CEO and founder of the innovation strategy consultancy Lean Ventures International, based in Stockholm, Sweden. By drawing on his experience as a serial entrepreneur and coach to hundreds of startup teams, Andy provides unique insights into what it takes to give innovation a chance. www.leanventures.se
Per-Magnus Skoogh is a co-founder of Agile Extreme. Per-Magnus has more than 25 years of experience with agile transformations, making him one of the world’s most experienced agile coaches. Per-Magnus is also the author of the book Agile for Managers. At the time of the manifesto, Per-Magnus was on the board of directors of the DSDM consortium and was asked to go to Utah to represent DSDM. He declined, and Arie went instead. To this day he wonders what would have happened … www.agileextreme.com
Other articles by Andy:
7 things your company needs to give innovation a chance
If you think that you have a strategy for innovation, think again
20 ways how to think and act like an innovator
Innovation thesis, innovation strategy, ecosystem and purpose
Introducing the go-2-market transit map
Without entrepreneurship, there can be no innovation
How to leverage failure to keep exploring
Entrepreneurship vs. business as usual
Introducing the Customer Happiness Canvas
5 keys to unlocking the innovation mindset
How to pitch to investors using a Lean Startup approach
How large mature companies tackle innovation
Here is why most startup accelerators fail
Lean Startup vs. Lean Manufacturing
Head of Product externe @Michelin / Lead Produit @Zenika
4 年The actual problem of the agile Manifesto is its current use. It is not a framework nor a dogma. what is interesting here, is the focus you give on delivery actual value. "Our highest priority is to create loyal customers through early and continuous delivery of customer value." My analysis on that matter : Agile software center paradigm is evolving and becoming more a "value to costumer" mindset, sum-up as Product mindset (vs projet one).
Senior Enterprise Architect and PM, and Family Winemaker
4 年Very interesting and good points, but the Agile Manifesto as you note is a set of guiding principles, which by their nature are general guidelines. So I think that discussing them and how we can apply them in practice is useful, but I don't see the value in reformulating them since ultimately it's up to us to use our common sense when applying them.
Agilist - opinions posted are personal and not on behalf of NSW Health
4 年I love your thinking and it's good to find another person who thinks alike. It's a great set of updates to the principles. I like and agree with them... except for #9 . If an organisation has moderately, significantly adopted the agile mindset and values, then the part about "continuous attention to ... excellence/design of the supporting business model" could work, but in many organisations the proposed modification would force agile teams / products to fit the status-quo, and not-question "existing business models". I've always believed principle 9 is about re-factoring. It's acknowledges that sometimes decisions are made to build/construct/set-up something that is good-enough, but we should go back and pay attention, review, redesign them. Continually. That we shouldn't let "that's the way it's always been done" be a mantra. We've had discussions across the #xscaleAlliance https://www.dhirubhai.net/pulse/descaling-manifesto-peter-merel about how the original manifesto didn't focus enough on re-factoring and hence technical and organisational debt (bureaucracy) have been allowed to accumulate. The discussion is ongoing on how to do it better.
Ich unterstütze Unternehmen bei der Entwicklung menschzentrierter und innovativer digitaler Services.
4 年Great read. Brings the focus from processes and models back to principles that tell us how we need to work together, which imho is a good thing. Connects well to this beautiful piece by John Cutler: https://medium.com/hackernoon/let-teams-figure-it-out-eefbf1a44ae8
Product Discovery | Agile | Human-centered Product Development | Servant Leader | Scrum | Outcomes | Complexity |CSPO | CSM | CSP | Inclusion | Adaptive Learning | Change Maker
4 年Lots to reflect on. Thanks for posting. The duplication in some of the principles has come up in our Agile training recently, as well as the comment about motivation. I wonder, however, how SAFe moves us closer to achieving the Agile mindset and organizational agility. Personally, I don't see it. Also, I'm curious. You mention "...several authors of the Agile Manifesto, e.g. Andrew Hunt, Zach Bonaker, and Alistair Cockburn."? I wasn't aware Zach Bonaker was a signer of the Manifesto. :)