The Agile Acid Test

A while ago I blogged about how I define Agile:

Agile teams produce a continuous stream of value, at a sustainable pace, while adapting to the changing needs of the business.

I’ve gotten a little flack for it. A handful of people informed me that there is only one definition of Agile and it’s in the values and principles expressed in the Agile Manifesto. The implication was that if my definition is different from the Manifesto, it must be wrong.

At Gary Brown’s urging, I reread the principles in the Manifesto. And I discovered that my “definition” is indeed in there. It’s in the principles: “…continuous delivery of valuable software…changing requirements…sustainable development…maintain a constant pace indefinitely.”

OK, so I’ll relent. Agile is defined by the Manifesto. And my “definition” is my Agile Acid Test.

Lots of organizations claim to be adopting Agile. Few have the courage and discipline to do more than pay lip service to it. Then they claim “Agile doesn’t work.” (My favorite take on this is Ron Jeffries’ “We Tried Baseball and it Doesn’t Work.”)

So, if a team tells me that they’re Agile, I apply my acid test to see if they’re really Agile. I ask:

How Frequently Do You Deliver?

When I say that Agile teams produce a continuous stream of value, I mean that they deliver business value in the form of shippable or deployable code at least monthly, and preferably more frequently than that. Shippable/deployable means ready for production. It’s done. There is nothing left to do. It is implemented, tested, and accepted by the “Product Owner.”

Some organizations are taking this to an extreme with continuous deploy. In those contexts, the time between when a developer checks in a line of code to the time when she can see her work in production is measured in minutes. Obviously continuous deploy isn’t necessarily appropriate in all situations. But even if you work in a context where continuous deployment to production doesn’t make sense, consider what continuous deployment to a testing or staging environment could do to shorten your feedback cycles.

In short, Agile teams deliver shippable product increments frequently. Delivering “almost done” or “done except tested” every month doesn’t cut it.

Could You Continue at This Pace Indefinitely?

“Sustainable pace” means that the team can continue to add capabilities to the emerging system at more or less the same velocity given no increases in team size.

There are two critical aspects to achieving a sustainable pace:

  1. people
  2. technical assets

Prior to working on Agile projects, I was accustomed to spending the last few weeks or months of any project in “Crunch Mode.” Everyone on the team would put in long hours (80 – 100 hour weeks were typical). We’d be hyped up on caffeine, stressed out, and cranky. But we’d do whatever it took to ship.

Having shipped, we’d celebrate our heroics. And then we’d go crash.

A few days later, we’d all drag ourselves back into the office. “This time we’ll do it right!” we would declare. We would spend buckets of time up front on planning, requirements, and design. And, let’s be honest, we were still exhausted, so we’d work at a slower pace. Inevitably, as the deadline loomed, we’d run short on time in the release and once again we’d be in Crunch Mode.

This is not a sustainable cycle. A few rounds of this and people are just too fried. Some leave for greener pastures, lured by the promise of higher pay and/or more sane schedules. Others “retire on the job.” The few remaining people who stay out of a sense of loyalty and who retain their work ethic find it impossible to get anything done because they’re surrounded by newbies and dead weight. Progress grinds to a screeching halt.

So caring for the people is the number one way to ensure work can continue at a sustainable pace.

But it’s not enough. The other side of sustainable pace is caring for the technical assets. Every time we take a shortcut, like copying and pasting huge swaths of code and not refactoring to remove duplication, shoving code somewhere expedient instead of putting it where it really belongs, or failing to write an automated test we know we really ought to write, we’re creating technical debt. As the technical debt mounts, the “interest” we pay on that debt also mounts.

Simple changes require touching multiple files. The code base becomes fragile. Eventually the team gets to the point that any change causes massive regression errors. For each new tiny bit of capability added, the team has to spend days playing “whack-a-bug” to get the features that used to work fine back to working. Once again, progress grinds to a screeching halt.

(Also note the connection between the human and technological aspects of sustainable pace: burnt out people tend to take more shortcuts.)

If the organization is not caring for the people, and the people are not caring for the technical assets, they will run into trouble. Maybe not today. Maybe not tomorrow. But soon, and for the rest of the life of that code base.

How Does the Team Handle Change?

I visited one team in the middle of a transition to Agile. The team was very pleased with their progress to date. They were delivering in 2 week sprints, and they were doing quite well with establishing and maintaining a sustainable pace.

But the kicker came when they showed me the project plan. They had every sprint laid out for the next 6 months. They were only a couple of sprints into the plan, but I could see trouble ahead. “What will happen if the requirements or priorities change?” I asked. The project manager squirmed a little. Promises had been made based on the master project plan. They weren’t allowed to deviate.

But change is inevitable. I don’t know the ending to that particular story, but my bet is that the project manager ended up redoing that Gantt chart a gazillion times before they shipped.

If the team is planning too far out, they won’t be able to adapt when, inevitably, priorities and needs shift. They’ll be able to continue delivering at a sustainable pace, but what they’re delivering will have substantially less value to the organization than it otherwise would.

Few Are Truly Agile

Often when I speak to an audience I ask how many people are on Agile projects. These days, no matter what audience I’m addressing, lots of hands go up. Agile is the new hot thing. All the cool kids are doing it. But when I ask audiences to self-assess on these three criteria, and then ask again how many are on an Agile project, hands stay down. Very few organizations are achieving this level of agility.

Not surprisingly, that means few organizations are really getting the benefits of Agile. In the worst cases, “Agile” is resulting in worsening quality, increased pressure, and more burnout. People on those projects are reporting that Agile is ruining their lives.

In such environments, Agile is often implemented as:

  1. Compress the schedule (because “Agile” means “faster,” right?)
  2. Don’t document anything (because “Agile” means no documentation, right?)
  3. Code up to the last minute (because “Agile” means we can change anything at any time, right?)

This is a recipe for pain: increasing levels of technical debt, burnout, chaos, and eventually inability to deliver followed by numerous rounds of Point the Finger of Blame. So yes, in these organizations, “Agile” (or the corrupted version in the form of a frAgile process) is indeed ruining lives.

My hope is that if you are in an environment like that, this Agile Acid Test can help you communicate with The Powers That Be to change minds about what Agile really means and what it looks like when done well.

Remember, just because someone says they’re doing “Agile” doesn’t mean they are. As Abraham Lincoln said, “If you call a tail a leg, how many legs does a dog have? Four. Because calling it a leg doesn’t make it a leg.”

19 thoughts on “The Agile Acid Test

  1. Great article. You will always get flack from the purist and Agile haters. I think your short definition was accurate and to the point. If you aren’t ruffling someones feathers, you’re doing it wrong. 🙂

  2. Awesome. Love it. What strikes me most is that I have seen situations where one team is doing well according to your test, and the team next door is just as strictly followng your “dysfunctional agile” with all three “points of pain” firmly in place. On different applications.

  3. agree! In fact agile is becoming a fad, and unfortunately when that starts to happen, dogma is not far behind and then eventual doom. People think they are doing agile, they fail and then blame the method and find a new fad.

    The biggest problem(benefit) of going agile is solving the “people” factor. People come forefront in agile. Communication over documents and that’s a culture shift. Organisations don’t care on that so fail

  4. >>> Agile teams produce a continuous stream of value

    Have you ever found the term or material form of “value” or “business value” being contested? do you have any instance where stakeholder disputed claim of the team having delivered value?

    It think “value” fundamentally is problematic term as it is born out as a very personal and private experience and is time variant. Value of Value changes with time and situation.

    If there is one thing that is fundamentally prone to reification fallacy (and all ills associated with it) – that is the phrase “value”.

    When we are forming definitions (or acid tests) – we must struggle hard to avoid terms that are abstractions and ones that are likely to be reified.

    You are talking about not only value but a continuous stream of it. Did you ever encounter any problems with this “misplaced concreetness” ?


  5. These are great and remind me one interview with a potential employee 🙂

    Quote: “Don’t document anything (because “Agile” means no documentation, right?)”

  6. I’m sitting here reading this, maybe 6 months into an “Agile Project”, going “Uh, huh”. “Yep”. “Exactly”. There’s still hope, but sadly, it’s not up to the developers to force management into doing things the right way. We keep trying, though.

  7. The example you use of a team that had planned everything out for 6 months makes me think of the trade-off between time and the complexity of a project. I work on a team that is pushing shorter and shorter delivery cycles seemingly to the detriment of lower level architecture. We’ve gotten really good at delivering smaller features quickly, but it’s at the expense of infrastructure improvements. How have you seen agile teams successfully deal with this type of situation?

    Btw, I’m glad you took the time to reflect on your definition of Agile. It might be that you ultimately went back to the Manifesto, but it’s important to re-examine such artifacts every once in a while.

  8. Pingback: Weekly Reads – 12/22/2010

  9. Hi Shrini,

    I think we’re seeing different aspects of “value.” I’m not referring to the nebulous and very personal notion of value as in “value to some person.” Rather, I’m talking about the business value that the business stakeholder identifies.

    Both Scrum and XP have a name for the role responsible for defining value. In Scrum it’s the “Product Owner.” In XP it’s the “Customer.”

    In both cases this is a role that is part of the delivery team. The person in this role has the authority and responsibility to define “What” for the system. They listen to the cacophony of conflicting demands from all the other stakeholders, distill a clear vision of where the system needs to be, and convey that vision to the implementation team. Together the implementation team and the Product Owner forge a step-by-step path forward.

    The Product Owner role is a difficult one, and is critical to the success of the team.

  10. Pingback: QuickLinks for December | (Agile) Testing

  11. Pingback: | Качество программного обеспечения

  12. Pingback: links for 2011-01-23 « Dan Creswell’s Linkblog

  13. Pingback: The Agile Acid Test | Smoldering Development

  14. I am familiar with the agile manifesto and I prefer your statement as a definition of agile because it counts. The attributes in the manifesto are attributes of teams, but they are not measurable. To me the word “agile” is what it means in English, namely the quality that some organizations have to move quickly.

  15. Great! Its a short, clear and crisp definition of what it means to be agile.Well said..

    “The intersection of Technology and Leadership”

  16. Pingback: Terse Systems : The Core of Agile

  17. Honestly, I do not think the manifesto forwards a definition at all. It reflects beliefs. But it does not even specifically name “agile” to be a noun, much less a proper noun. We did that… not them. They reflect on values and principles, but these are all in pursuit of a goal. In my mind, you have named the goal. Personally, I treat the word agile the way our language does – its just an adjective. Becoming agile – that’s a result – not a defined process, not a religion, not a singular truth, not even a thing. Certainly not a synonym for anyone’s particular approach. Its a desirable result – but I have seen plenty of “agile” that looks nothing like the next guy’s “agile”… but they were getting it done. Your post – I consider this clarity. Thanks!

Comments are closed.