Agile: 10 years later
One of the interesting pieces of Mike Cohn’s post on the 10 year anniversary of the Agile manifesto was a comparison of the arguments in the previous decade around OOP:
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.
I really couldn’t agree more. Talk of agile just bores me to tears these days. What’s your iteration length? Are you doing TDD, or just unit tests? Are you doing BDD? Do you have one scrum master, or does it rotate? Who is your product owner? I hear these questions, and honestly it sounds in my head like adults in the old Charlie Brown specials:
Wah wah wah wah wah.
When I moved from IT to consulting, two things happened to change my worldview. First, I read The Goal, after much more suggestion and cajoling than should have been from folks like Scott Bellware and others. The other thing that changed was that I was actually in a position influence the schedule on when to ship code in to production. None of my other jobs afforded me that luxury, or anywhere close to authority (or to influence that authority) to ship code whenever I decided.
At our company, Headspring, we’ve made it a bit of a mantra for all of our projects to focus on delivering value to production as quickly as possible. That’s our “goal”.
All of the other means to reach that goal, whether it’s the Agile principles, XP practices, or software-engineering-flavor-of-the-month. Focusing on optimizing a continuous value delivery system, from concept to cash (production), produces a side-effect of quality. How quickly can we get working software that delivers value in to the hands of the users? How fast can we repeat that process?
Working software creates content customers. Working software delivered quickly produces happy customers. Working software delivered continuously and quickly fosters elated customers, and I don’t think that changes whether you’re in consulting, start-ups, product development or IT.