If you are not familiar with the term “Agile”, it typically refers to a genre of software development methodologies. These methodologies attempt to make software development work better/smoother. The concept is summarized in “The Agile Manifesto”, as follows:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes
- Working software over Comprehensive documentation
- Customer collaboration over Contract negotiation
- Responding to change over Following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Initially, this concept was started by people who were buried in bureaucracy and were seeking an (honest) way to be more productive. Good for them! Unfortunately, the concept was quickly hijacked by a genre of programmers known as “cowboys”.
After a cowboy recites the Agile Manifesto, he will be unable to speak about how Agile can be used to add discipline to a project. He firmly believes that Agile is meant to repel all forms of discipline. If you have a sense of humor, you might smile on the inside as an agile cowboy exaggerates the Agile manifesto and make it sound more like this:
Empowered free-thinking humans who get stuff done vs rigid and thoughtless obedience by robots who sit in a dark corner counting beans
Programming by unfettered creative geniuses instead of rotting in legal quagmires
Golly, when you put it like that it makes it so difficult to choose. Should I pick the ones on the left or the right? Hmm, they both sounds so tempting it is just so hard to pick one.
Of course I am being sarcastic (and maybe a little snarky). However, if you have ever met an Agile cowboy, you will be amazed how much they actually sound like this. It is almost as funny as it is scary.
Cowboys are naturally free-wheeling creatures who are repulsed by formality and structure. Therefore, when someone presses a cowboy to grow-up and start following a process, the cowboy immediately becomes defensive and hunkers-down as he prepares to resist “change”. The first time that a cowboy hears about Agile, he will definitely commit it to memory, because it sounds like something solid to hide behind when the bullets start flying. This is because Agile is a well-respected, formal methodology that sounds like it won’t impose responsibility on people. A cowboy will wear it like a tuxedo with the sleeves ripped-off, or perhaps a nice new tuxedo t-shirt. It may seem spiffy if you look at it from just the right angle. Otherwise, it seems like some kind of a joke on the real Agile.
In reality, Agile itself does not actually require a dev team to reject all responsibility, formality or documentation. However, you won’t be able to tell it to an Agile cowboy. The cowboy will draw a red line through any formal processes and add a footnote: “Agile says: This is evil. Don’t do it”.
On the inside, a cowboy has strong reasons for rejecting formality. Here is a quick-list of common (bad) rationales that cowboys use for hiding behind Agile:
- Less-formal processes – Cowboys dislike discipline and formal processes. Formal processes make people more accountable. If things were more organized, there might be more fingers pointing at the cowboy.
- Less-formal planning – No matter how chaotic things seem, a cowboy can always claim that everything was intentional and according to plan. However, if folks had to write-down a plan before starting any work, it would probably make a cowboy look bad. Heck, a cowboy might not even be able to follow his own plan.
- Keep the customer involved – The more involved the customer is, the more the customer can shoulder the blame of any mistakes. When things go wrong, the cowboy can blame the customer and the customer will be ill-prepared to dispute it.
- Respond to changes – Even if there isn’t really a dire need for a team to respond to change, a cowboy can always say that the software industry changes frequently. Even if the cowboy is not keeping up with the changes in the software industry, it sounds plausible.
- Less-formal documenting – Cowboys don’t know how to make good dev plans, diagrams and models, nor do they want-to. If a programmer gains the experience and gets good at it, he might be expected to do it more often. That sounds boring.
- Avoid other forms of planning – “Who truly knows the future? Do you have a crystal ball or something?” cries the cowboy. “After all, making plans for future stuff is just an optimistic guess and that is just un-scientific”, adds the cowboy. He is worried that if he tries to make some plans or predictions, he is certain to get some of it wrong and might receive criticism.
- Following a methodology = formality = discipline = responsibility. Discipline and responsibility are not much fun.
If this describes you or anyone on your team, then Agile is not going to be beneficial for you, simply because it will be your enabler. You need to break the bad habits, (described above). Once you get yourself together, then come back and read my article about when to use Agile and when not to.
Oh, and just in case you think I’m singling-out one particular person or group: you can relax. I’ve worked with a half dozen teams who sound just like this. It is actually a common problem and I wish the Agile community would be more responsible and talk more honestly about the conditions under which Agile is not a good fit.
The way to tell if you are a good agile shop or just cowboys with tuxedos, is this: Have you ever been successful with another methodology (or two)?
If you have, then you already have the discipline to follow a formal methodology. In which case, you are probably choosing Agile for the right reasons. It will help you respond to legitimate problems and overcome hurdles that otherwise would stand in your way.
However, if Agile is your first foray into using a formal methodology, or if you couldn’t get anything else to work, then you are probably only using Agile because you don’t know better and you don’t want to know better. Agile is not going to provide a value to you. In fact, it will probably reinforce your (already) bad habits and you will use it as an excuse to avoid improving yourself or your processes.
Basically, Agile can be a strong tool to hold you back and stifle your improvement. You won’t grow until you let go of it. Hearing this will make you mad. Which only solidifies my point.
Leet-up cowpoke. Time to hang up those spurs and grab some beans to count. Remember that you are not afraid of anything. Not even formal processes. You can do it.