Staying Agile by Going off “Agile”

This is a blog post of a statement that I finally made after reading “The Decline and Fall of Agile

I am going off “Agile”

No, I am not going to give up test-driven development. In fact, I am doing more of it by adopting more behavior-driven development, which is actually harder at certain cases. It helps me understand the code and verifies the design (I believe it does that rather than “drives” out the design nowadays but that is another post).

No, I am not going to give up aggressive refactoring. Every time, and I do mean EVERY TIME, I slack on it, I end up paying the price one way or another and kicking myself. I have been proud of every single line of code that I have produced (cannot say that for all the code that I have inherited and worked on), and they always serve me and my team well.

No, I am not going to give up on iterative development in the form of Iterations or Sprints. They help my teams focus, avoid distractions, and can still response to the request from outside the team with crystal clear transparency.

So what is it?

I am going to take “agile” off my vocabulary in all communications.

Rather than saying

“Not able to have QA accepting the stories as soon as they are finished is not agile”

I’ll say

“We need to get those finished stories accepted as soon as possible, so that we can close the feedback loop. When they are accepted, we know we are doing a good job. And when they are not, we can trace back to our thoughts as we were developing them and understand where it went wrong”.

Rather than saying

“Not setting a goal at the begining of the Sprint and verifying them through the Sprint signature is not agile”

I’ll say

“We need to establish a way to provide feedback regarding our work and make continuous improvement to the way we work, so that we can provide better value to the people who pay us. One way we can do that is to look back at our progress in the past Sprint, talk about our experiences and thoughts, and come up with action items to make things better”

Apparently this will make conversation longer, because I have to present proof more than a good book (dozens of good books available as a matter of fact). Sometimes, I will have to wait, patiently, for the opportunity to present itself so that I can use as an example to persuade others to slow down, do it right, and do it well.


I have been thinking along this line for a while. I read the “Good Agile and Bad Agile“, felt annoyed because there is truth in what he is saying. From time to time, I get annoyed by the negative comments that don’t even make sense to me. I wrote one post about “Things You Cannot Get Certified For“, and argued hard on several news groups that I subscribe.

Very soon I got tired of it. Using the word “agile” has caused more distraction than its worth. Practices are sometimes picked upon literally and are attacked. Rather than looking at the value something is trying to bring, many seem to tend to look at the cost(time, tools, processes) first. It got attacked, it got debated, and at the end nothing is done and the bad things just keep going. And you get people from all over the world writing about how “agile” did not work for them and laughing at anyone who is interested in trying.

To add insult to injury, you can also hear usage of agile in the format like “Let’s be agile about it, instead of insisting on … “. It is really hard to argue in this situation, because you cannot just simply say “no, lets not be agile about it because we should insist on going through this three hour meeting to make sure that our stories are up to the standard”.

I have been avoiding throwing agile around for a while and I think I am happy with the result. I also have been ignoring the bad usage of ‘agile’ out there so that I can stay healthy to focus on bringing agility to my teams. (I swear this is the last time). A month ago, I went through all my blog posts and took agile out of the labels and categories.

I have been thinking about writing a post like this and finally decided to do it after reading James’ post “The Decline and Fall of Agile

6 Comments on “Staying Agile by Going off “Agile””

  1. Good post. I wrote about something similar, getting rid of the “Agile” prefix in this piece: “Is ‘Agile’ Distracting You?”:

    When you think about what goals you are trying to achieve, the practices that are working well transcend movements, even though it’s harder than trying to follow a formula.

  2. Shane says:

    Hi, thanks for leaving the comments and another great reference.

    I do want to play the devil’s advocate by pointing out that this can also abused and cause trouble (speaking of paradox). You can very well get someone asking for “the value of pair programming” or “the value of collocation”. Those of us we have done this for a while all agreed without exception that they are both very good practices, yet none has been able to put a money amount on it. At certain projects, we really had to *bully* others into this

    I feel that each situation is different and the best way to judge is not by personal preferences, but by how successful the project is and how happy the people on the teams are

  3. Alan Keefer says:

    Thanks for posting this, Shane. I can understand why Shores is frustrated about how the “agile” name has been co-opted in a way that essentially sets “agile” projects up for failure, but I don’t think that’s the only reason that people in general see “agile” as a bunch of hype. As per my last post here, I think the even XP often fails to really discuss real-world issues very well, so people just reading through the literature see a bunch of practices that they can’t actually apply because their circumstances are different, followed the constant caveat “all the practices are self-reinforcing, so you can’t drop any of them, and don’t even consider deviating from them once you really know what you’re doing.”

    The end result is that people drop the agile practices that are essential to making things work not just because they’re hard but also because they don’t apply to their current situation and they’re not sure how to make them apply. Take our team for example: it’s way too large to do XP with the whole team, we have a huge codebase that no one person can understand, our PMs have to act as proxies for real customers, our tests take too long to run, we release infrequently, we have to worry about API stability and upgrades, etc. So it’s easy to look at agile and say, “Okay, we’re going to do agile . . . expect that part won’t work, and neither will that, and we can’t do that either, and that’s not really appropriate, but we’ll try the rest.” So certainly some of it is people taking the easy way out and avoiding things that are hard, but a lot of it is also people avoiding things that they think have no chance of working.

    I’m honestly not sure what you can do about that; the reality is that software development is just hard, and doing it sustainably over the long haul is way, way harder than just hacking out a version 1.0 and calling it a day.

    I’ve found it helpful with my team to focus much more on the reasons behind the practices and what failure modes they’re trying to avoid; we have no choice but to deviate from the ideal practices even though we’re not that experienced with them yet, but at least we can hopefully do so while trying to keep the principles around and while trying to avoid the same sorts of failures.

    Perhaps we need a new word or phrase, not to use as a way to beat people over the head (“you’re not being agile enough!”) but as a way to emphasize a philosophy of development that focuses on long-term sustainability by avoiding technical debt and burnout, and that’s focused on tackling the hard problems and avoiding the sorts of failures that plague most development teams. To me that’s what “agile” really should mean, but it’s gained this connotation that it’s supposed to be some sort of silver bullet.

    Maybe any one word is always guaranteed to gain all sorts of unintended meanings, though, and so rather than trying to coin a single word or phrase to sum up all those concepts we’ll just need to constantly have those conversations explaining what sorts of traditional failure modes we’re trying to avoid and why certain practices work together to help avoid them.

  4. Alan Keefer says:

    Apparently, I can’t type this morning. Among the many horrific typos, in the above comment I meant to say that XP practices are often followed by the caveat “all the practices are self-reinforcing, so you can’t drop any of them, and don’t even consider deviating from them *until* you really know what you’re doing.”

  5. Shane Duan says:

    Hi Alan,

    Thanks for leaving the comment and voicing your opinion. In your case, I do see your argument and trust your observations.

    Obviously, I cannot speak for your team since I know nothing about this. But speaking from my personal experience, some of these practices ARE hard to learn and do require a hard upfront commitment of do whatever it takes to make it work. I just think most of the case people give up too early.

    Again, this is something that has to be decided at case by case basis, which is the same reason that I will jump on any chance to attend one of Mike Cohn’s SCRUM master certificate training classes, even though I dislike the idea of SCRUM master as well as the idea of certificate.

    At the end, I feel that your comment confirmed my belief in giving up on “Agile”. If any reads your first three paragraphs and my second one,, he or she will get the idea that we strongly disagree with each other. Then if he or she reads the last part of your comment, and my resolution on the blog post (about talking about the goal of practices when pushing for them), we are actually pretty much doing the same thing, and, most importantly, looking for the same thing in software development.

    I do agree that software development is hard, or, most of us who are still enjoying it probably would say, challenging

  6. Jelena says:

    Oh, dear. I know how you feel, I feel the same about using “agile” for some time now. When I started blogging I avoided using the “A” word for a very long time, and succeeded, actually. But then, maybe that is not the way to go. I am still somewhat undecided.

    At first, a long time ago, the majority neither heard of nor wanted to be Agile. Then it became an alternative movement, which became cool; for the elite. Soon after, it became the buzzword of the week, month, year… now it is a bit of a mainstream, and seemingly everyone wants to jump on the Agile bandwagon.

    At the same time, enough time has passed for it to become misused, misinterpreted, abused, criticized… As you said, and I agree “And you get people from all over the world writing about how “agile” did not work for them and laughing at anyone who is interested in trying.”. Maybe it is a part of natural evolution of things.

    So, yes, I feel frustrated and bitter sometimes, but whatever happens, the values behind Agile will hold in the long run, I believe that.

    I wrote a (sarcastic) post today here: dedicated to the instant culture of becoming “Agile” that took over a big part of the world some time ago.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s