Waterfall is quite effective when tackling a Known Problem with a Known Solution.
Agile works best when faced with a Known Problem and an Unknown Solution.
With that said, I strongly believe that Waterfall and the old guard of Product Development will become less and less prevalent as we accelerate time to market. In today’s technology sector, by the time you are finished with the 3rd review of your SRS document, another company will have already beaten you to market with a Minimum Viable Product using Agile and Rapid Customer Development.
Perhaps their early release will lack a certain polish from your perspective, but then again you have a slide deck, and they have actual customers.
Technical Debt is a phase coined by Ward Cunningham to help illustrate the pros / cons of releasing software in a quick & dirty fashion vs a long term, cleaner solution. In a nutshell, technical debt is much like financial debt, as it incurs interest in the way of level of effort over time.
Financial Debt comes with a very negative connotation in these tough economic times, but as Eric Ries stated recently it isn’t inherently a bad thing. Releasing early has it’s own benefits such as receiving much needed customer feedback for your product. These leading indicators may provide the direction you need with future software releases.
How does an agile team decide whether or not the technical debt they incur is acceptable?
I have a couple suggestions below:
Address Technical Debt in Retrospectives – Keep a running tab of your technical debt so that it doesn’t run rampant. Your retrospectives should include items such as Refactoring Debt Incurred and Refactoring Debt Paid. If you trend these data points over time and notice debt incurred going up like a hockey stick, it should be a cause for concern.
Release Early with Customer Feedback Loops – While there are certainly scenarios where a feature needs to be pushed out quickly, the code should include some level of empirical data gathering to measure customer impact. With tools such as Google Analytics and Mixpanel available, take the time to run A/B tests with your code. If your early release results in a 20% boost in conversion, it is much easier to reconcile the technical debt you incurred. Without this data however, you will be missing key elements to your decision process.
In short, be wary of teams that use the phrases “quick & dirty” with “path of least resistance” too frequently without empirical data to back it up. Keep your technical debt manageable by trending it over time, and bake in customer feedback loops to justify your early releases.
I highly recommend the recent Eric Ries Webinar on Lean Startups. They’ve uploaded it to YouTube, and Eric is now accepting registrations for his Lean Startup Tutorials. (Almost Sold Out!)
Loading ...