The Agile Manifesto was published in 2001. Twenty-two years later, the website, which still exists, looks like a relic of an earlier age. The simple website design has not been updated, and the principles themselves have been frozen in time.
For one thing, there were no women and no minorities among the seventeen white, mostly middle-aged men who gathered in Park City, Utah to hammer out this set of principles that eventually transformed software development. I would hope that such a gathering today would be seen as, at best, incomplete — without a more diverse set of voices in the room.
Still, as a marker of progress, the Agile Manifesto was a significant landmark that defined what it means for a software team to be Agile. Its twelve core principles have embedded themselves into the group of methodologies we call Agile Software Development so thoroughly that we take them for granted as the definition of “good development.”
And it was intended for software: the title of the document is “Manifesto for Agile Software Development” and “software” appears three times in the body. It uses other words like “requirements” in ways that were unique to software development. All of the authors of the manifesto came out of software — and more specifically, came out of IT software development. That was the environment they knew, and the one they wished to transform.
Twelve Principles for an Agile Transformation
The twelve principles they defined were compelling because they expressed the hopes and desires of many who are bringing new things into the world — not just software developers. The authors of the Manifesto had been experimenting with these ideas in the software domain, but the ideas themselves were more universal.
For example, the 11th principle states, “The best architectures, requirements, and designs emerge from self-organizing teams.” The Total Quality Management movement of the 1980s and 1990s had proven both the effectiveness and the difficulties of sustaining self-organizing teams in corporate structures. In general, people liked the autonomy and focus on value creation, but they struggled with managers who sought more command-and-control. Twenty years later, self-organizing teams are still the most effective way to organize knowledge workers — and still very difficult to sustain in a corporate environment.
At the time, large-scale software development programs had an 80% failure rate. Today, the failure rate is lower, partly because the technology is more mature and partly because the Agile Manifesto was successful at breaking the waterfall paradigm in software development. Today, not every software team is Agile, and not to the same degree. But they have all had to make a decision about whether or not to become Agile and if so, how to do it. In the Age of Agile, teams have to justify why they are NOT using Agile methods.
As I said in my article last week, that has sometimes led to conflating the principles of Agile with the practices and tools that manifest Agile in a specific situation.
The Agile Manifesto and Rapid Learning Cycles
Rapid Learning Cycles began gathering steam about ten years after the Agile Manifesto had been published. Its core principles were part of the unspoken assumptions that drove conversations within the Agile community, which had started dipping its toes into areas outside of software development. As such, I didn’t formally map Rapid Learning Cycles to the principles as it was coming together.
But all the conversations and projects I’ve had in the last few years rescuing Hardware teams from poor Agile implementations has shown that Rapid Learning Cycles works, in part, because it manifests the same principles. The practices and tools don’t look the same because the problem domain has different characteristics. But the connection is there.
The Same Principles, Different Practices and Tools
Over the next twelve weeks, I’ll write a series of articles to show how the Rapid Learning Cycles framework fulfills the Agile Manifesto principles for areas that differ from software development in at least one of three key ways:
- Cost of change is higher.
- The outcome is a physical product that will be sourced, assembled, shipped and supported in the field.
- Resources are more specialized: one person cannot step in to do the work of another very easily.
I’ll show how the Agile principles work because they rest on even deeper principles about the nature of work and system dynamics, such as queuing theory and Lean principles about how to remove barriers to flow in a process. An understanding of this foundation will help explain the choices we made as we transformed Scrum into Rapid Learning Cycles, element-by-element.
The articles will explain why the Agile principles lead to more agility (that is, flexibility and responsiveness) as long as the practices and tools fit the problem domain. Then I’ll share five things that hardware developers need to achieve agility that the Agile Manifesto doesn’t address, because software does not have these needs at all.
A Path Forward for Blended Teams
By the end of all this, I hope that you’ll have a better path for working side-by-side with your software colleagues, and a better understanding of exactly why Rapid Learning Cycles accelerates innovation — by helping teams live into these principles while using practices and tools that work for them.
