How Agile is Agile?
Agile ain’t just any damn thing – Ron Jeffries
Here is what I want to know… when does agile stop being agile? Is agile only agile when we have 6 or 8 people sitting in one room doing pair programming? Is agile only agile when those 6 or 8 people are delivering cross functional features every week or two? Do I have to pass the Nokia test to be agile? Can agile be agile when I have to blend it with some PMI style practices? Can agile be agile when I have to do documentation to meet our corporate governance standards? Is agile agile when I blend it with RUP or Lean or Kanban? How about when I have 1000 people working across three continents, can that be agile?
Maybe the question really is… how agile is agile?
Maybe it’s time to recognize that Ron is right. Agile ain’t just any damn thing. Maybe we need a new term for what might be agile-like, but adapted to meet the needs of larger more complex enterprises. I am generally of the mind that agile is about quickly delivering value to our customers, getting fast feedback, being able to quickly respond to change, creating people centric organizations… one where individuals can make difference. One where we plan, but are not beholden to the plan. One where everyone is aligned toward creating the best possible outcomes. For me, it’s always been more about the value I am creating than the rules I follow to create it.
So… maybe we are just learning that agile isn’t as agile as we thought.
Thoughts?
Comments (6)
Bill Gaiennie
The statement "are we agile?" or "is that company agile?" is somewhat like trying to have an absolute definition of quality…it is somewhat subjective, meaning, it is not an absolute destination that a team achieves, it is more aligned with the description Mike gave, the description/adjective agile describes a team with some key characteristics.
It is too bad how often I work with teams that feel that "they have been agile for several years" are anything but what I might call agile. Those teams that believe a training, a coaching engagement, or reading a book will make them agile are the ones that are not framing the word within the spirit it is likely intended. Teams that know there is no such destination, only a journey (I apologize for the corniness) are those that embody the incremental improvement aspect that allows for continuously seeking a greater outcome through possibly different actions.
So Mike, you began and ended with the question, is agile really agile? When I read that title, I interpreted it slightly differently, but it may still be a good question to ponder…is the agile community of coaches, trainers, and support organizations truly taking an agile approach to the discipline itself?
As some wise man once said, the answer likely lies within the question.
As always Mike, great post.
Bill Gaiennie
Daryl K
Why does it matter? Why is it important to put the Agile label onto something? What's the motivation?
Mike Cottmeyer
Daryl,
It might not matter. I'm just feeling extra edgy and disagreeable tonight ;-)
That said, what is in, and what is out, clearly matters to some. I'm interested in where the community sees the boundaries. My guess too, is that you have a litmus test that has nothing to do with labels. It has to do with what you deeply believe is really consistent with agile values and principles.
Mike
Anonymous
I enjoyed this thought provoking post. Here's my two cents — I believe a company can be "agile" without following every letter of the "Agile" manifesto and its guiding principles. How many times have you used something that didn't require some "tweaking" or "personalization" to make it a better fit for you?
The way in which a company embraces and leverages Agile should be no different. While Agile should compliment and improve a company's software development strategy, the company must still remain true to "what works" so that you're not "throwing the baby out with the bath water"!
I am encouraged by and proud of the fact that my company is "realistically" adopting Agile/Scrum in a manner that embraces the Agile practices and principles while continuing to include "what works" in order to efficiently deliver quality, working software to our customers as quickly and effectively as possible.
Thanks for allowing me to voice my thoughts…:-)
Winona Robertson, RMIC
Norbert
Mike,
Good question. I would define it as when the process cannot support responding to changes when and how the business/organization/entity requires.
Daryl, two answers: 1) this is how language works and 2) it comes from thinking about how to optimize the process or processes, we use to do development, by looking at their boundaries and defining characteristics.
Derek Huether
When I've asked vendors if they leverage Agile practices, I've discovered many shades of gray. I'm sorry to say, I've seen people pervert the original 12 principles of the Agile Manifesto to the point the mere mention becomes the punchline of jokes. It's easy for me to become incited, when Agile becomes the scapegoat for poor leadership or process. I still believe the 12 principles are the framework in which we decide if Agile is still agile. If the Manifesto is no longer the Agile bellwether, perhaps it should be refined? Agile will stop being agile when we start to detail all possible inputs and outputs and actually believe we can predict or plan our way out of every situation.
Best Regards,
Derek
http://thecriticalpath.info