What is Agile?

It’s been more than 20 years since a group of software professionals got together and created the Manifesto for Agile Software Development. And yet, I think this question is still just as valid today as it was in 2001. Most people think “Agile” is about daily stand ups, pairing, TDD and the like. They think it is about the processes and rituals that development teams practice on a daily or weekly basis. However, these practices represent XP (Extreme Programming) or Scrum and not Agile Software Development. So if Agile is not about practices, what is it.

The reality of the manifesto is twofold: 1) it was a reaction to waterfall and 2) it represents the only points that the people that created it could agree on. Each of the signatories of the manifesto went to Snowbird with different ideas, different processes, and different theories on how to create software better and in the end, the four points in the manifesto really represent the intersection of all those ideas.

We can get a hint about what the manifesto is about by looking at the words, or word, used. In particular, “Agile”. What is agility? According to the Oxford dictionary, Agile, or Agility, is the “[ability] to move quickly and easily.” This is important. The Manifesto is about moving quickly and easily. It’s not the Manifesto for planning software development or the manifesto for ritualistic software development, it’s the Manifesto for Agile Software Development.

Let’s look at another definition; “ability to think and understand quickly.” At the heart of both of these is the idea of change. Changing easily and quickly in response to some stimuli. It means changing course, focus, ideas, visions, and most importantly, plans.

I would posit that planning and agility are antithetical to one another. If you have plans, you have rigidity. You have ideas that cannot change. If you have a 3 or 6 or 12 month plan for features that have to be, or should be, released and ROI calculated on those features, etc., you don’t have Agility. Therefore, in order to be Agile and follow the ideas in the Manifesto, you can’t have plans. The question I know many are asking is how do you develop software without a plan.

Simple; you develop software through feedback. Remember, a aspect of Agility is the ability to respond quickly. But to respond to what; shareholders, stakeholders, customers, user research, etc.? Yes to all of the above. The basic idea here is that you create an MVP (Minimal Viable Product), release that into the wild, and respond to the feedback that you get. And by MVP, I don’t mean something that you take months to create. This should be something that is created as quickly as possible and then released to see how it fairs. This is an experiment.

At the heart of Agile Software Development is the idea of generating experiments and see how they do. Some will fail, some will succeed quickly and then plateau, and some will get adopted slowly and then take off. But at the heart of all the experiments is the fact that you now have data. You have experiences and anecdotes and stories that can be used to refine the original idea and make it better. And best of all, you have spent as little money as possible. Instead of waiting for 12 months and releasing something that is perfect only to watch it fail, you can release an idea, gather feedback, and ensure it will succeed by slowly developing it according to what your users really need.

At the heart of the Manifesto is the idea of eliminating guesswork, “well I guess we need Y in 12 months, or we hope their will be a market for Z in 2 years” and instead, releasing software by knowing exactly what you got right, what you got wrong, and what amplifying the former and reducing the later. Guesswork and hope is replaced with data and the ability to respond quickly to that data.

That is what Agile is.





One response to “What is Agile?”

  1. Paul Sobocinski Avatar

    Great post! I really like how you described the manifesto as an intersection of ideas, processes and theories brought forward from a variety of software development viewpoints. I’ve never thought of it that way — as an intersection. I suppose that partly explains the paradox: while the manifesto itself is not controversial, its application usually is.

Leave a Reply

Your email address will not be published. Required fields are marked *

Copyrighted Image