As early as 2007 Agile practitioners, or at least people who blog about Agile, began to observe that we live in a post-agile world. I’m not sure what means but Agile is a conversation about the best way to manage the software development process that has been going on for a long time. Has it been too long? What comes after Agile?
Eventually all wisdom becomes dogma. Many engineers feel strongly that we’re already there with the process for process’ sake when the scrum master moves into the cubicle next door. Fair or unfair it’s a criticism needs to be explored. However nobody has put forth a process to succeed Agile–one that builds upon it’s strengths and shores up it’s weaknesses. At this point in the history of software development were we to abandon Agile we might as well go to ouija boards and seances to plan our projects.
So in truth, we make it up as we go along. That’s what most experienced scrum masters mean when they say they are flexible about adapting the processes of Agile to the culture and business needs of an organization. Poor Agile implementations are only a few second-guesses away from good ones.
Perhaps it’s time to take what we’ve learned in the 10 years since the framers of the Agile Manifesto met in Snowbird and create something that fits even better with the technological and business climate of the Mobile-Cloud-Long Tail-Social-Search Driven-Virtual world we log into every morning.
I’d like to start with the very first value of the Agile Manifesto:
Individuals and interactions over processes and tools
Do we still value people over process? Is it that simple? From this value the principles of customer satisfaction, working with business people, building projects around motivated individuals, face-to-face conversation, sustainable development, and team reflection are derived. Change this value and we change the equation for all of Agile. Do we weaken it? strengthen it? or replace it with something else?
Even with the unique challenges of developing software for servers you can’t touch and cell phones with fingerprints all over them we know what true process-for-process’ sake is like. We call that Waterfall but it was many more manifestations. It’s the paperwork you fill out in the emergency room and the electronic EULA you click “agree to” without ever reading.
So we have to keep it. In fact I would argue we have to make it much more imperative: A rule that is never broken which says it’s OK to break the rules!
I don’t mean we should give up our process at the drop of a hat (or the crash of a market). But we must give it up when our people will be rendered ineffectual. Issac Asimov’s Three Laws of Robotics can inspire us with a new rendering of what is, perhaps, the most important value of Agile:
- A process may not injure a team or, through inaction, allow a team to come to harm.
- A process must obey any orders given to it by a team, except where such orders would conflict with the First Law.
- A process must protect its own existence as long as such protection does not conflict with the First or Second Law.
If it will keep our robot overlords from killing us it will work for keeping an overzealous Agile process in check!