Don't Get Throttled
gga
#2009-10-06
The agile family of software development methodologies is now pretty firmly established. Developers have always been some of the most firm supporters of these approaches. And as developers, we like to focus on the good practices that produce better software: testing, story driven development, continuous integration, etc.
And these are all wonderful things. But, from the inside I think we forget the single best thing about agile software development:
Agile means your customers no longer want to throttle you.
Don’t forget this: it keeps everything in perspective.
My first real software development job out of Uni was at a small technology company. We had a core product, an expert system runtime, that the company was built around. We were organised into two major divisions: Products, who worked on the core technology; and Solutions, a traditional consulting division who delivered projects (usually) based around the core technology. Products would have been about 20% of the company’s employees. The rest, admin staff and Solutions.
I worked in Products. I like to think we did good work: during the four years I was there the product became much faster, finally ran on more than one OS, supported multiple platforms and countless other features were all delivered. Delivered on a three month release cycle. We had a roadmap of releases covering the next year and a half or so, with features allocated to each release. And every three months there’d be a new, mildly tested, release that had some of the planned features, some last minute features and a bunch of bug fixes and improvements for features from the last couple of releases.
At this point I would like to remind the uproariously laughing peanut gallery that this was my first job out of Uni and I knew no better. Clearly, neither did any of the managers.
I can still remember the moment of revelation when I discovered that all of Solutions hated us. Hated the Products staff, hated the product. One wag had joked that the company was divided into Solutions and Problems. How could this be? Our technology was great! Really! It was genuinely the best of its kind in the world. Why did they hate us so much? How could they hate us so much?
It’s obvious now: Solutions were trying to win new business and then deliver projects on time and budget. Invariably they’d find bugs in the product, or new features they needed. And our response? “It’s too late for this release; we’ll try to include it in the next one.” In four months time.
Now on an agile team what would I say? “OK, we’ll include that bug fix in the next iteration. You’ll have it Friday week.” That’s a bit glib of course. In reality there will have to be a discussion about what is going to get pushed out of the next iteration, and estimation of how long the new work will take. But when your answer can honestly be in terms of tested, working software and a couple of weeks delay, everyone is happy. And in particular your clients are not going to be frustrated and furious.
On only a couple of occasions since have I had to be the client to a waterfall team. And every time I’ve ended up wanting to throttle them: “How can it take as long to plan the work as it’s going to take to do, ferchrissakes?” And every time I have to remind myself that they’re not trying to be difficult — they genuinely want to help — it really is just this hard to turn the boat.