Agile charted

Here’s how I think of agile.

Traditional software development has the problem that it gets feedback only after it has lost its ability to make relevant changes.

Agile on the other hand aims to get the feedback quickly while still having room to maneuver.

The upper right-hand corner of the chart is the sweet spot for development. It is the place where learning is possible and true innovation can occur. This is the heart of agile development. If your agile process leads you to the lower left side for whatever reason, you are doing it wrong.

I’ve pessimistically drawn both arrows’ ends’ in the lower right. From innovation point of view, the goal of course is to stay as long as possible on the upper right, and for example Facebook has kept in that general area for admirably long. But there seems to be a very real gravity that takes successful products down on the chart. This is The Innovator’s Dilemma: successful competition in an established market requires sustaining innovation, and companies that invest heavily in it tend to lose their ability to change direction. (Example: Nokia’s phones in 2000-2010.)

But while the individual products and product families are brought down by gravity, a company may escape it by cultivating disruptive innovation. Apple and 3M show that it is possible, but it appears to be very hard, since there are not many companies like that.

4 thoughts on “Agile charted

  1. PM Hut says:


    What are you basing your charts on? I think many project managers won’t agree with the above chart (how the waterfall fails vs how agile succeeds.)

  2. Antti Tarvainen says:

    I’m trying to represent with charts how I think of agile. So they are only based on my thoughts, not data or anything actual.

    Let me try to clarify my intention a bit. The post is short and there are all kinds of biases and half-formed thoughts behind it, so I probably was not able to communicate very well what I was aiming to say.

    I’m not arguing that agile is better than waterfall. I’m arguing that a good definition of agility is the ability to make changes based on feedback. If you claim to be agile without this benefit, you are not really agile, according to my definition. If, on the other hand, you are doing waterfall and you have ability to respond to change, then you are agile according to my definition, regardless of your process.

    I am definitely not saying that if you follow Scrum (or XP or something), you are doing better. You can do Scrum and be very un-agile according to my definition. Most Scrum teams I have seen in fact are (but you can always say that they are not doing real Scrum (or real agile, which is what I am saying…)).

    In addition, I am claiming that agility defined this way is one of the most important aspects of innovation. Innovation in vacuum is not possible. You need to be able to try new things, get feedback and act on that feedback.

    Now, this definition of agile may be overly broad and not match the usual definition of agile (agile manifesto for instance). If so, perhaps I should not call it agile. But in the end I don’t care about the words. Which is one of the reason I used charts.

  3. Simo says:

    Sounds like you’ve been reading Adapt (“We should not try to design a better world. We should make better feedback loops.”) If not, it may interest you.

  4. Antti Tarvainen says:

    Thanks for the tip, Simo. Sounds like something I might enjoy. I ordered one to Leonidas.

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 )

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s