A Working Definition of Agile

In a recent workshop, a participant asked me, “What does agile mean? How do you know if you are agile?” He wants to use kanban to see the flow of work through his group. Someone told him he needed to use iterations to be agile. (I had a little rant about this in What Does Agile Mean to You?)

I suggested this could be his working definition:

  • You can deliver what you want (some form of value).
  • You can deliver that value  when you want.
  • You can then change to the next most important chunk of valuable work.
  • You learn from the previous work you did, both about the work and the process of doing the work.

That's not all agile is, but it might be a good working definition. If you work towards being able to deliver what and when you want, move to the next thing, and learn, you have the feedback cycles. (You might also look at the agile principles behind the Manifesto.)

These are practices that increase your agile capabilities:

  • Iterations, because they limit the work a team can commit to in a given time period.
  • Kanban with work in progress limits, because they limit the work a team can do, and show the flow of work.
  • Retrospectives because you learn from previous work. (Someone important said if they only did one practice it would retrospectives. I can't remember who said that. Sorry.)
  • Standups because they reinforce micro-commitments to finishing work.
  • Technical excellence practices from XP, because they make changing the code and tests easier.

You don't need any of these to be agile. They help. You might find other practices to be more helpful in your context.

I have some previous posts that might be interesting if you also are wondering what agile means for you:

For me, practices are interesting, especially if I choose to experiment with them. What could I do to increase my throughput and learning, and therefore, my ability to adapt? Agile is not about specific practices. It is about a mindset of finishing small valuable chunks, feedback, and change.

8 Replies to “A Working Definition of Agile”

  1. There is always the “start finishing, stop starting” mindset that is often associated with the agile way of doing things. Maybe one check of “am I agile” is whether I am getting the things done that I want to get done – and getting them done quicker and quicker.

    1. Jack, I like that a lot. You are right. It’s not enough to limit the work you take on, you need to release it (for some value of release). That goes directly to the start finishing, stop starting mindset.

  2. “Quicker and quicker” scares me. Over the course of my career in IT (18 years) I’ve seen very little problem with delivering fast enough, but huge issues with delivering value. Delivering late causes short-term frustration all the time, but is usually quickly forgotten after someone gets their wrist slapped. Delivering the wrong stuff kills businesses and leaves no one to blame for it. So if you ask any operating business what the biggest problem with IT is, they’re likely to think of the delivery problems they’re currently or recently experiencing. But ask a failed business what the biggest problem was, and they’ll have a very different answer.

    1. Paul, agile came about because people thought it would help the “deliver the wrong stuff late” problem.

      As you correctly point out, if you deliver the wrong stuff fast, that doesn’t help at all. If you deliver the right stuff too late, that might be a huge problem. (See my Cost of Delay posts.)

      Agile (and lean for me) is about finding enough value to deliver soon enough to get feedback. That feedback should (a difficult word) provide value to the people doing the asking.

      I like your distinction between short-term problems (such as late delivery of needed functionality) vs long-term problems (delivering the wrong functionality, often late). We try to manage this in agile with roadmaps (as in other approaches) and frequent delivery of small stories. Does every team succeed? No.

      If this was easy, they wouldn’t pay us.

  3. At the core of agile is acceleration. Not straight line acceleration, but change in direction or velocity.

    I think of it as the ability to adjust the plan to avoid an obstacle, or facilitate better value delivery without “materially” slowing down progress or incurring significant cost.

    I might add, that those adjustments should be done without drama, stress or excessive force.

    In service of these goals, planning small deliverables, making small commitments, and establishing small feedback loops are key.

    All of these and all of the practices exploited by the established frameworks serve to shorten the planning decision cycle time and planning adjustment cycle time that allows us to embrace change rather than resisting it.

    1. Rich, lovely. I like the idea that acceleration can change. Too many people (especially managers) think that velocity is something that should always go up. Not so. If you’re doing a prototype, you might have acceleration on understanding, and not final deliverables.

      You might if you realize something is flat out wrong, have a decrease in acceleration to rectify the problem.

      Just as we adjust our acceleration on the highway to allow for traffic (we change how fast we drive), we might do the same for our projects.

  4. One of the things I liked a lot about Rasmussen’s The Agile Samurai book is that, at the end, after all the chapters on backlogs, iterations, user stories, TDD, etc., he closed with the following:

    All I can say is if you think you’ve made it and you’ve got it all figured out, you’ve stopped being agile.

    So, don’t get hung up on the practices. Take what you can from this book, and make it fit your unique situation and context. And whenever you are wondering whether you are doing things the “agile way,” instead ask yourself two questions:

    • Are we delivering something of value every week?
    • Are we striving to continuously improve?

    If you can answer yes to both those questions, you’re being agile.

    1. Chris, yes I quite enjoy Rasmussen’s book. On the Prag author mailing list, he is the “other JR.” Well, one of us is.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.