Our engineering department at the Meltwater Manchester office recently held a full day agile training with Bob Galen (http://rgalen.com/). The whole day was pretty great, and Bob provided some fantastic insights and advice, but there was one area where we disagreed a bit, and I felt it warranted a bit more thought.
Bob presented a situation most engineers have been in. A product owner was looking for an estimate for how long it would take to build a feature. One of the engineers said it would 5 points to hack something together, 10 points to build something stable, but not refactored, and finally 20 points to build a robust, scalable solution. I initially gave the typical developer answer, “It depends”, but when forced to choose I picked the 5 point option. Bob felt that the 20 point option was always correct.
My goal was to get something out in front of users as quick as possible, which would make most business focused stakeholders happy. Bob felt that 20 was appropriate because we should only produce code that we’re confident is good. Poor code leads to technical debt and potential flaws, so Bob certainly had a good point. At the end of the day, business stakeholders would likely be more averse to a broken, but feature rich system, than waiting a bit longer for features. I agreed with Bob, but after thinking about it for couple of days, I’ve changed my mind a bit.
The correct answer is 25.
Bob was absolutely correct that the end goal is to have the best possible code; to build a feature that meets the business needs and doesn’t lead to technical debt and scalability concerns down the road. However, I don’t think the 20 point story would get you there. Anybody who’s worked in software knows that you almost never get it right the first time. Even when you take all of the time you need to build a first iteration of a feature, you will almost always find improvements to the feature from either a user facing, or technical point of view. This is where the 25 comes in.
The correct answer is both 5 and 20. In art, you almost always sketch or outline before you start painting. In writing, you create a rough draft before a final manuscript. In code, we should also create a rough draft / sketch feature first. Rather than treating the 5 point version as a hack to get the feature done, view it as a rough draft. It provides a way to get the feature to users quickly for feedback and provides a way to look at how to code performs to better inform architecture decisions in the final draft.
A lot of people may balk at the extra time, but I’d wager that in many cases it would be a wash. Any task carries risk of exceeding estimated time or effort projects, and larger tasks carry larger risk. By tackling a rough draft first, you can significantly de-risk the larger task. You will have a better picture of how users interact with the feature and clear metrics on how the code performs. In addition, letting some users get early access to these features helps sales and business focused stakeholders start generating buzz and potentially reduce sales churn.