Why Agile?

  • Posted on: 2 May 2017
  • By: leor

Why do we do anything at all? What motivates us to get up in the morning, and come to work? When you think about it, the morning rituals we go through to arrive at a set location at a particular time, with a bunch of other people who feel just like we do (in their own way) in order to do a series of activities most of us could frankly care less about if we weren’t being paid to, does not lend itself to model that results in a happy, engaged workforce where the focus is on the Team more than the Individual.

What is the RESULT? Every individual deals with things differently, but if we looked at the top of the bell curve, we would probably see many people on automatic pilot, waiting for the day to end so they can enjoy the tiny slices of life afforded to them in the evening hours - hoping for meetings to end rather than fully participating, performing a suitable amount of work related tasks so they aren’t chastised, and trying to avoid communicating with co-workers wherever possible.

Why is this the case? Are those people in question lazy, miserable, and unmotivated? Are you now, or have you ever resembled a person who felt or behaved that way? If the answer is yes, what would have been necessary to make you WANT to apply the same passion and engagement at work you might have applied to a personal project? If you’re a manager or Scrum Master, how can you get those results from your Team?

Agile methodologies have attempted to address some of the above items, with the degree of success very much having to do with the people involved, and the interpretation and execution of the practices. Like any other powerful tool, Agile can be dangerous in the wrong hands, especially if you don’t know what to look out for.

The myth is that if group of people do all of the ceremonies that they are practicing agile, but the truth is, if the focus isn’t on delivering valuable software in short time frames, you’re not really BEING Agile.  You’re DOING something else.

Agile development is all about solving the problems associated with traditional software development. The Agile Manifesto states, "We are uncovering better ways of developing software by doing it and helping others do it." But just what is better about Agile development?

Agile emphasizes delivering early and often, enabling the business to begin generating a return on its investment much earlier. Agile does ask for discipline and participation from the business as part of the deal, such as rigorously prioritizing the features and being available to answer questions during the development cycle. In return, the business gets its highest-valued features delivered early, and delivered with quality.  


The  creators of the Manifesto for Agile Software Development clearly stated what the real purpose of Agile is in the first of the Principles behind the Agile Manifesto.


The message is driven home again with the third principle.

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference on the shorter timescale.”

If there was any remaining doubt as to the intention of agile software development, it should be clear from the seventh principle which states:

“Working software is the primary measure of progress.”

How often are you actually delivering to your customers? How long does it take for a requirement, after it’s discovered, to be released to a customer? How many status meetings about dates, and escalation points do you have to endure when something changes?


No large enterprise is immune to being disrupted by a smaller, more nimble company with good ideas and great execution. Sometimes the erosion is very rapid (how many Tom Toms or Garmins have you seem on people’s dashboards lately?), and sometimes it’s a slow process of attrition leading to a death spiral (I’m looking at you, Yahoo!, Nokia… newspapers), but it’s never pleasant, and, for the forward thinking and team oriented, it’s avoidable.

Regarding teams, let’s be frank: people are annoying. George Carlin observed that when you are driving in your car, anyone going faster than you is a maniac, and anyone driving slower is an idiot. This will hold true for just about anything in life – walking, shopping, drinking, or writing code. You will find there is a small percentage of people who operate at something close to your speed, where you can transfer information at a rate you find comfortable, and everyone else is basically a maniac (or aggressive, or overbearing, or irresponsible), or an idiot (needs no clarification). So how can we successfully operate in an environment where most of us are looking at each other with a stinkeye?

The answer is never simple and always specific to the personalities, culture, enmvironment, technologies, and leadership involved. If you’re not addressing the whole picture, any progress you make will slowly erode, as we’ve all seen with the common regression of teams when the coach leaves. In order to achieve a truly lasting result, and gain the positive impacts Agile promises, but doesn’t always deliver, the problems must be approached by seeing the whole picture, understanding the underlying patterns, and helping others to understand. If this is successful top to bottom, people will be equipped with a new language they can use to identify the things that undermine their positive intentions, and their feeling of powerlessness (and the disengagement that comes with it) will be replaced by a sense that they can control their own destiny, that what they do day by day matters, and the difference will be visible in all the metrics we love to observe.

This is the path to sustainable, self-governing, self-organizing teams.