Why Newton was agile and the Titanic was not

Let’s be perfectly clear about one thing: 2009 will not only be known as the year the financial crisis hits in hard, it will also be known as the year everything turned agile. Please allow me to explain. The times when banks, insurance companies, car industries and the likes could start up multi-million software development projects of titanic ambition, with dozens of stakeholders, never ending requirements sessions and five year deployment plans are passed.

I mostly refer to such projects as titanic projects. They take forever to build, but sink at the first bump in the road.

Newton’s first law

Now, let’s add some physics. Back in 1687 Isaac Newton stated his three laws of motion. The first law nicely describes the current state of most titanic projects. It states: “A body continues to maintain its uniform motion unless acted upon by an external unbalanced force.” Here, if you replace body by project, titanic projects will never stop unless something really drastic occurs. “We have already invested 25 million Euro’s in this project, we cannot afford to stop now!” prowls the eager program manager.

Well, that was then, and this is now. We now do have an external unbalanced force. It’s called the financial crisis. For the majority, these titanic projects will be put on hold – or will shift to slow motion. Personally I consider putting such projects asleep to be one of the greatest benefits of the current worldwide economic situation.

Newton’s third law

So now what? This is where Newton’s third law motion comes in handy. Without going into much technical detail it can be simplified as: “To every action there is an equal and opposite reaction.” Doesn’t that sound good? Instead of running highly expensive, never ending, never delivering projects, there will an equal and opposite reaction. We all know what that reaction will look like: shorter, smaller, delivering projects. Agile projects. In 2009 and 2010 (late followers) nearly every respectable bank, insurance company and government agency will turn to look how agile practices can save their pet projects.

Being a longtime agile evangelist you might say: “Sander, what are your complaining about? This is what you always dreamed of. ” Well, yes and no. Of course I’m glad that agile practices finally become accepted. But there’s a dark side too. The sudden churn towards agile will trigger a huge demand for agile expertise in the marketplace, not only onshore as you might expect, but even offshore.

A new breed

As agile becomes hot, a whole new breed of agile practitioners will arise from the ashes of the titanic projects: the people that previously ran those projects. They all will be officially converted to agile, although deep down inside they very much believe that agile is not different from the way they’ve been conducting (failing) projects for the last twenty years. And who will treat projects in exact the same way as they did for the last twenty years, only with a small speak.

Thus we will see six month “iterations” – or longer, feature teams of over sixty members, project where the first ten iterations are used to establish the requirements, the next ten iterations for doing design, and the remaining iterations to build the software, and finally if there’s still time left, will use the last iteration to test the software. Projects that are agile in name only. Please be aware of this new breed.

Let me illustrate agile misuse with a small example I recently encountered. In the week before Christmas I received an interesting newsletter by a company that claims to be agile. Unfortunately, their newsletter writers are still left in the dark. A quote from this newsletter. “Government chooses agility in IT projects,” heads on of its articles. “As of 2010 all big IT projects run by government agencies are to be evaluated per stage on suitability for the next stage.”

In my humble opinion there’s not much agile about this statement. In fact, it sounds like waterfall with even tighter milestones to me. But the newsletter concludes: “The Dutch government clearly chooses for an approach based on agility.” Eh? As I said before: we’re in the year everything turns agile. I even got new year’s greeting cards wishing me lots of agility in the new year.

Agile popularity paradox

Service oriented architecture is out. It’s just too complicated. And agile is in. In 2009 and 2010 the term agile will be used for anything that people want you to apply to your projects. Think of highly proprietary code generators that were sold five years ago as service oriented code generators, agile frameworks that previously were mash-up frameworks, agile project managers with only waterfall experience, agile requirements tools that require the creation of multiple Word document per requirement ,and projects who claim to be agile just because their weekly progress meeting is now done standing up.

The risks involved form a true paradox. Yes, we know agile works. Hook up to its core principles, including collaborative teams, re-prioritization, short iterations, small units of work, and testing and delivering early and frequently. And then implement techniques to match these principles, such as daily (!) stand up meetings, agile dashboards, burn down charts, pair programming or retrospectives. Your projects will benefit.

But due to the exploding popularity of anything agile we are going to have to wade through the mud. Newton was right. A body continues to maintain its uniform motion unless acted upon by an external unbalanced force. The thicker the mud, the slower the motion.