Reflections on the 10 Years Since the Agile Manifesto
This article is part of the Agile Manifesto 10th Anniversary series that is being published on InfoQ.
Much has changed in the ten years since the Agile Manifesto. Back then, the processes encompassed by the Manifesto-Extreme Programming, Scrum, DSDM, Feature-Driven Development, and others-existed only on the fringes of the software development world. It was, therefore, easy to dismiss them as being inappropriate for real-life application.
I know that was the case for the company I worked for back then. A few years before the Manifesto came about I was running Scrum with a software development group for a large division of a much larger conglomerate. When the VPs of Development for all the divisions met to discuss adopting a common development process across all of our divisions, I couldn’t get the other VPs to take Scrum seriously. Despite the fact that our division had been by far the most successful and we attributed that to our use of Scrum on dozens of projects, I couldn’t get others to even consider trying Scrum in their divisions.
Even in my own division, we questioned our decision to use Scrum. After all, most of the buzz in those days was about the Unified Process. There was this feeling in the air that if you weren’t doing the Unified Process, perhaps you should be. We had been tremendously successful with Scrum yet were filled with doubt-would we have been even more successful if we used a complete methodology instead of this little toy of a process called Scrum? After all, we didn’t know anyone else doing Scrum and the term "agile software development" didn’t exist. When the whole world seemed to be moving toward a "unified process," it was hard not to wonder if you were the only ones who weren’t.
And then one February morning I got an email from Ward Cunningham: "Look how I spent the last few days," he wrote. He included a link to a new website, agilemanifesto.org, and a grainy photo of some guys standing around a whiteboard. But that website hit me like a lightning bolt-we weren’t alone, after all. Suddenly I knew there were at least seventeen others who felt the same as we did. And then day by day, there were more, each signing his or her name and adding a brief statement of solidarity on the agilemanifesto.org website.
With a name for what we were doing - agile - others like us seemed to pop out of every corner. "Yes, we do that, too," became the catchphrase of early agilists as we all discovered we were not alone.
And now here we are ten years later, and things have swung 180 degrees. If you aren’t agile or in the process of becoming agile, you probably feel like you should be. The biggest change from ten years ago is that agile processes now deserve a seat at any table where people are discussing which process to use. If I were a VP of development today in a large conglomerate and I suggested agile to the VPs of other divisions, they could not just dismiss it with a wave of their hands. Agile, in its many forms, is a viable, credible alternative. It may not be the right one for every company or project but no one would be laughed out of the room for suggesting it.
From laughed out of the room to credible alternative in ten years. Where does agile go from here? Hopefully two things are in store for us next. First, I’d like all the brands to go away. No Scrum. No XP. No Kanban or lean. No DSDM. No Crystal. Just agile. We saw this happen two decades ago in objects. We had various modeling approaches and methods from Rumbaugh, Booch, Meyer, Jacobson, and others. Those differences were eventually put aside and we now have merely objects and UML.
The next change I’d like to see (and predict will occur) over the next ten years also occurred in the OO world: We stop talking about agile. We stopped talking about objects a while ago-they won. No one engages in big debates about OO anymore. Sure, there are some applications, such as those with intense performance requirements, where we don’t use objects. And some projects are written in non-OO languages. But even in those cases I suspect the code being written has still been influenced by objects. I’d like agile to reach this same point, where we no longer need to talk about it. Rather than "agile software development" it is just "software development"-and of course it’s agile. No one asks me if the Ruby code I’m writing these days is OO. Of course it is. I hope someday no has to ask if I used agile on the project. Of course I did.
In another ten years I hope I am asked to reflect on what will then be twenty years since the Agile Manifesto. I hope by then it’s a largely forgotten document, like the Magna Carta. Yeah, that dusty old thing. My life is still influenced by the Magna Carta, and I was recently called to jury duty to remind me of this, but I hardly spend my days thinking about it. I hope for a similar fate for the Agile Manifesto. And when I do reflect back on agile software development ten years from now I hope we’ve stopped calling it agile. I hope we’ve stopped calling it anything at all and are just doing it.
About the Author
Mike Cohn is the founder of Mountain Goat Software, where he teaches and coaches on Scrum and agile development. He is the author of Succeeding with Agile: Software Development with Scrum, Agile Estimating and Planning, and User Stories Applied for Agile Software Development. With more than 25 years of experience, Mike has previously been a technology executive in companies of various sizes, from startup to Fortune 40. A frequent magazine contributor and conference speaker, Mike is a founding member of the Scrum Alliance and the Agile Alliance. He can be reached here.
Next: Real Organizational Transformation
I think we're already there in terms of "Agile is like OO", it's just that the process types (presently, Scrum, Kanban, XP, etc.) are like various OO languages. There are plenty of zealots who seem to care more about whether you're following the gospel to the letter rather than connecting with the Holy Spirit: whether it's the Gospel according to Gosling, the Gospel according to Matsumoto, the Gospel according to Sutherland or the Gospel according to Ohno.
I hope that we can, as a community, expand our reach from the team to the organization. We all have seen how Agile methods expose disfunction in the organization... and if the old structures aren't exchanged for new ones, the disfunction continues. It's perfectly analogous to recovery in mental health: the defense mechanisms that protected the child-aged mind from splitting apart... those aren't serving the now-adult; the human must become aware of and reconsider the mental structures. So too with organizations. The program management policies that served us well 10 years ago are prolly due for a review. And here we have a general process for getting things done in a swift and targeted fashion. True Organizational Transformation anyone?
So, while the Agile Manifesto was targeted at the team, let's start canonizing a follow-on Testament: a new, holistic, covenant with the Organization. What would that look like?
I certainly hope that the Manifesto does not become a dusty page under glass. I hope, instead that the Four Core Values are more like The Four Noble Truths of Buddhism: age-old, but perfectly relevant today. I hope that as new practitioners are inculcated, the tradition is handed down and renewed in that transmission.
- John Ryan, Agile Consultant, BigVisible Solutions, Inc.
Re: Reflections on the 10 Years Since the Agile Manifesto
For Agile to succeed even more, the Agile process needs to work, not just for software development, but for business development as well. One huge premise of Agile is that the project sponsors don't know exactly what they want at the start of a project. However, a lot of project sponsors act as if they do. They would often be better off to apply Agile to their business processes (e.g. product management and operations) as well, and involve the software folks to develop within an Agile business framework.
I think that in the next 10 years, organizations which use Agile for product management and business operations will move faster than those which use waterfall (even if their software development processes are Agile).