“Why do you have brakes in a car? Because then you can drive faster. [1]” I like this quote, and I find it very relevant to modern software engineering. Teams that know when and how to use the brakes can drive a project fast and still arrive safe and sound at the final destination. But some agile teams are speeding; driving too fast, reluctant to actually use the brakes, and so they drive a project off the road. For example, sometimes you see teams being so much focused on implementing customer visible features that they forget about the importance of a sound and solid internal infrastructure. It seems like the old “nah, we are in a hurry, let’s write tests and documentation later” (which nobody did of course) has now been replaced with “nah, we are in a hurry, let’s do proper design and architecture later” (and this will of course never happen either).
Agile methodologies encourages you to do things in small steps, often in cycles that can be measured in seconds or minutes. It does not really matter if you do ‘think/change/test’ or ‘add test/change/refactor’, sometimes you will meet challenges that require many hours or days or even weeks to do properly. Just as we in the old days could spend months on a Big Design Up Front (BDUF) before starting to code, we must now be prepared to pause once in a while and spend some time thinking. For example, suppose you are to implement a feature where you need to store some values for later retrieval. You realize that you need some kind of persistence mechanism – and it is obvious that a big chunk of internal infrastructure is missing. This is a time where you need to slow down and make sure that you do this properly. Being agile should not be used as an excuse for just mocking up some poorly designed ad-hoc persistance mechanism.
If you do not slow down when required you will end up with bad design and architectural rot. Soon developers will start to complain about: “it is hard to find stuff”, “it is hard to add stuff”. Despite everybody working very hard, the real progress of the project is next to nothing. The project is like a car stuck in the mud, now pressing hard on the accellerator pedal is not what you want to do. This is not a time for more hard work, now you need to start thinking. You have wasted a lot of time and effort already, but if you are willing to backtrack a bit you might be able to fix the bad design, improve the architecture and get the project back on track. Not slowing down when required will cost you a lot in terms of time and effort, but also in frustration and lost confidence from developers and management. Actually, just like when driving a car, the penalty of driving too fast is so high that (most of us) always prefer to have a large security buffer. If you are eager to successfully complete one project after another, then behave and drive sensible. But of course, in software engineering there are no real cops watching you, so if you can see a very long open stretch, then go for it…
[1] I first heard this quote from Kevlin Henney at ACCU 2008.
Geektalk 
Great post! There’s to many “mocks” around that has somehow made it to production because the teams implementing them thougt that agile equals speed. They didn’t realize that things tends to stay they way you do it the first time. As someone wise once said: the fastest path between to points is seldom a strait line.
I guess the brakes-thing is why agile teams should remain pretty small. A big team will gather momentum like a 500 tonn truck. When traveling at 200 km/h you can apply the brakes all you want – you will still need a complete development cycle (or more) to come to an halt.
Excellent Post! Now for the previous comment, not only a big team in Agile will gather momentum, but there’ll be so much noise while driving that it’s easy to take a wrong direction. Large teams are not well handled by Agile, this is one of the agile limitations.
Again this is a great post, and I’m interested in republishing it on PM Hut. Please contact me through the “Contact Us” form on the PM Hut site in case you’re OK with this.
I love the quote, and the concept behind it. IMHO agile work is not about “going fast.” It’s about doing value-add things rather than non-value-add things. If you just do the value-add things and forego the non-value-add things, you will finish a given amount of work in less time. A focus on “going fast” may lead teams to “forget about the importance of a sound and solid internal infrastructure.” It isn’t about speed; maybe that’s not as obvious to some people as I thought.
PM Hut: Your choice of words betrays a poor understanding of agile methods. We want to avoid “large teams” and handle large projects by using multiple small teams. I think this is generally a better way to structure projects regardless of methodology.
This is not a “limitation” (a judgment-laden word) but merely a “characteristic” a (value-neutral descriptive word) of agile methods. The problem with using a judgment-laden word is that it carries the unspoken implication that traditional methods may be effective for large projects. That is a misconception that has cost industry billions of dollars in the past few decades.
With multiple small teams contributing to a large project, management has to coordinate the release plans of the teams. This can be a different sort of challenge than with traditional methods, but still definitely do-able.