Agile, The Control Paradox, and the Boring Software Manifesto

Noel Rappin, Friday, September 7, 2007 @ 2:45 pm

I'm probably not getting the quote quite right, but supposedly at one point during the C3 payroll project where XP was created, a developer said that it was so easy to make changes to C3 that they could turn it from a payroll system to an airline scheduling system without any strain.

Okay, it's not much of a story, but the idea resonates with the core of what Agile development means: driving the cost of incremental change so low that you can handle whatever the client or customer throws at you at any point in the process.

Gaining Control

There's two parts to that statement, of course. The first is that it's great to be able to easily fix bugs and make changes to the software over time. The second is that it's even better to be on a project that you feel is under control.

This is the paradox of being Agile. Agile dispenses with many of the artifacts that traditionally symbolize control in a development process -- big requirements documents, detailed UML diagrams, long-term Gantt charts, that kind of thing. At the same time, I've never felt more in-control of the actual day-to-day work then I do when in the midst of an Agile process. By accepting the inevitability of change in a software project, Agile allows the development team a structure by which the effect of changes can be mitigated.

The Boring Software Manifesto

Several years ago, I coined the phrase The Boring Software Development Process, in response to a former employer where project management really didn't think anything was happening unless we were trying to solve seven crises simultaneously.

The manifesto goes like this:

• Boring software projects favor tacking exciting problems, and focusing our energy on the most interesting and valuable parts by avoiding wasting time on avoidable problems.

• Boring software projects favor automated test suites over the excitement doing all your testing at the last minute and finding bugs after the project is "done".

• Boring software projects favor frequently integrating work from the whole team as opposed to the excitement of finding out whether you changes work well with the rest of the team after you have been working on them for six weeks.

• Boring software projects favor always having a working, if incomplete, system over crossing our fingers and guessing whether the newest build would compile.

• Boring software projects favor incremental design rather than spending six months crafting a UML document that is thrown out after one week of development. (I'm not exaggerating on this one, I reviewed a project that happened on)

• Boring software projects favor understanding that requirements change over being "surprised" when late change requests come.

• Boring software projects favor putting working, if incomplete, systems in customer hands early to get feedback as early in the cycle as possible rather than finding misunderstandings after the project is done.

I hope that wasn't too boring... Next time, something a bit more nuts and bolts.

agile ajax

Comments: 1 so far

• Leave a comment
• Comment feed for this post

1. 

   I totally agree, agile done correctly is really boring. If you have a solid framework for incorporating changes in a controlled fashion, then nothing really surprises you.
   After doing agile for several years, this becomes a real problem. Presumably, you can turn your teams excitement outwards towards developing cool new features or inwards towards tuning the process and gaming against your metrics, but I find the best approach is just getting a foosball table.

   Comment by chris, Monday, November 12, 2007 @ 3:02 pm

Leave a comment