2006 "Sooner Not Faster" article

This is a blog I wrote on ButUncleBob (the Object Mentor blog) in 2006, republished here verbatim because that blog is not always available and because it still matters.

Sooner, Not Faster

There is a widely-held myth (well, near-myth) that Agile software development is about "going faster". It's really not. Oh, you might go a little faster, but that's not what it's about. To go faster, one will tend to optimize by shortcutting the process and accepting lower quality work, by sacrificing health to long hours, etc. Agile methods have strict discipline to avoid these things, and agile projects do end-of-project work sooner and more often than a typical waterfall project. Agile actually adds some valuable steps to the process. It's "more work", though it's more certain.

Faster can be dangerous. If you are running at break-neck speed, and then you come upon a steep downgrade, you are likely to go pinwheeling out of control and break something. Hopefully something cheap. Pushing someone who is running as fast as they can is likewise unhelpful. They will make much *less* progress when they're lying broken on the track. You probably can run a little faster than you think, and a little longer. If you are on foot and going faster than you can run, however, you are in big trouble.

Likewise, coding faster than you can safely code is dangerous. Things are left undone, things are broken in subtle ways, things are not tested, problems are not understood. The effort quickly pinwheels out of control. It's likely that you develop code faster than you think you can, but if you are going faster than you are able to manage, you are in very big trouble indeed.

Agile helps maintain control. You know when you're breaking more code than you're fixing. The feedback (tests, partner, etc) says you'd be better off at home, in bed, than creating disasters for the next four hours. You're not going faster or working longer hours per day. You're using the best measured pace you can sustain. You may end up going a little faster than you thought you could, but you won't be going faster than you are able.

If you are going faster than you are able to manage, then what you are doing is not agile, it's just hurried. Your managers and customers want code sooner, but do they really want "hurried" code from an exhausted, out-of-control team? I can't tell you how often in my early career I've been on teams pushed to go faster and faster, only to be blasted by the same managers for being out of control. They didn't really want faster. They wanted sooner.

Instead, Agile projects are about being "done" sooner, more certainly, and more often (for larger values of "done").

In agile projects, you are always ready to deploy, starting with the end of the first iteration. Mind you, nobody may want that pathetic first increment, but nonetheless it is supposed to be ready. The extent to which each team is succeeding is the extent to which each release is ready to be deployed. If there is patch-up work, integration work, and testing to be finished, then your iteration is actually not done. The "no partial credit" rule says you have to be finished with all tests passing. If you still have to "finish" anything then, by-definition, you are not done, yes?

Being done is more work than not being done. You have to prepare the build system sooner, the installers sooner. You have to have a working build system sooner. You have to keep these things in good working condition all through the project. But being able to deploy to a project stakeholder means that there will be more feedback on the work that's been done. This feedback allows validation sooner, and that means that correction can be done sooner, hopefully before a real customer deployment. That means that it will be correct sooner, even though you're not working faster.

You are supposed to be "done" often. Every month, every two weeks, every week.

Mind you, the world will still want "faster" too. But agile will give you sooner instead. Be sure you know what you want.