Tuesday, November 18, 2014


Whenever I hear someone start to talk about Agile methodologies I start to worry because, while the industry has agreed that Agile is the way to go, Agile is often misunderstood.

Agile is often sold to management as a way of getting better quality software faster, with fewer bugs showing up in the field. Well, that might happen as a side effect but Agile is really about being flexible. Change is a big problem on any engineering project. With most engineering disciplines change is very often fatal but at least it's easy to understand why. If you design an engine for a car and it doesn't fit, you're basically screwed. This is where the saying "measure twice cut once" comes from. With software it's not as obvious sometimes why a change would be particularly difficult because software is just a bunch of instructions. Just change the instructions! Duh.

It's never that simple. Software isn't constrained by the laws of physics. As a result, software projects have a tendency to grow in complexity until they become unmanageable. A typical project is a tangle of inter dependencies. Some of these dependencies are design assumptions, some of them are organizational assumptions - like budgeting and estimates. For example, if you write a piece of software for a desktop computer and find out that it really needs to run on a smartphone, you're basically screwed. It's doesn't matter that it's software.

Agile methodologies are a series of mitigation you build into your software and organization to make it resilient to changes during development. Those changes can be discovered difficulties or they could be mistakes.

In order to get into the Agile mindset you must first be convinced that planning is pointless. That the world is too full of unknowns and surprises that trying to plan is like putting on a contact lens in the middle of a sandstorm.


  1. Your time estimates are random numbers
  2. The man in charge of the requirements is a raving madman
  3. The chief architect has some kind of dementia
  4. What you're trying to build might be a logical impossibility anyway
So what does all this mean? It means you can't rely on estimates, the requirements still need to be discovered, you're going to make mistakes at the design phase and the whole thing might be a waste of time anyway.

In other words, it's a typical software project.

The only one thing you're not allowed to assume is that your programmers are idiots or are evil. If your programmers aren't excellent, trustworthy professionals then you're doomed no matter what you do. You might as well go outside and play Frisbee all day. You'll fail either ways but Frisbee is more fun.

Agile mitigation consist of things like this:
  • Chopping the project into many small pieces
  • Prioritizing these pieces with the goal of getting something useful quickly
  • Doing each piece one at a time; avoid over-design - YAGNI
  • Giving this "something useful" to the customer and finding out if you're on the right track as soon as possible
  • Re-evaluating the priorities of these pieces every day as new information is discovered during development
  • Pushing decisions to the edges of the org chart (developers or other) to allow developers to solve problems without a heavy vetting process (self organizing teams)
  • Lightweight, flexible and adaptable process - one that allows people to adapt to changes
  • Improve communication channels between people (co-location, burn down charts to track progress, bug database, unrestricted channels (anyone can talk to anyone else in the organization))
  • Techniques to write maintainable code. Unmaintainable code is by definition hard to change.

My key point is that Agile methodologies don't make change free. It doesn't make software development magically faster or higher quality. It's all about being flexible and mitigating the damage done by routine changes during software development.

No comments: