Your team has been trained and coached to deliver new chunks of software in a short time frame. Those using Scrum will be able to deliver in a Sprint. Those using Kanban will deliver as soon as their small feature is done. You’ve learned alternative ways of estimating which don’t include time as a measurement. Maybe you’re using story points, t-shirt sizes, or pills of vicodin to measure the complexity of your work. Delivery has clearly improved, but you still get asked every December to estimate year-long initiatives for annual budgeting meetings. Something doesn’t make sense and you’re having a hard time explaining it to upper management. Ever hear of incremental finance?
The Problem
Let’s look at the issue from another angle. When you take your car to a mechanic to get new tires, you get a quote based on the set that fits your wheels, the brand and quality you expect, and a time estimate for when it will be finished. If any of the variables don’t line up with your needs, you’ll head toward a shop that can meet your expectations. When you get your car back and pay for services rendered, there were likely few surprises. The shop finished on-time, the cost was what you expected, and the brand of tire you requested is on your car as you leave the shop. The people who finance your projects are trying to make a similar decision regarding development initiatives. How much quality can we get for what price? When will it be finished? What will we get for that money? The difference here is that changing tires is a repeatable process. Auto shops do this every day.
Software projects are complex with many unknowns about the technology, the people, the problem, etc… The larger the project is, the exponentially more uncertain things become. If you’re a software developer and think “I’ve done this before, I can estimate it”, think again. Just look at a problem you solved a year ago. If you had to resolve the problem using the same technology, would you write the code the same way? If you said yes you’re lying to yourself.
I’ve never met a developer who enjoys their job that isn’t constantly improving the way they write code. Writing software is more like writing poetry than changing tires. It can always be written better, more concise, more readable and maintainable, even in the same language with the same tools. Coding style changes over time as a developer hones their craft. I remember a situation going through code I deemed too unreadable to avoid rewriting, but hit a wall. Unable to decipher the code, I went off to find the author to ask questions. After looking at the digital tags identifying the author, I realized I had written the bad code just 6 months ago. This was proof to me that I would likely never solve the same problem the same way twice.
On the delivery side we manage complexity by breaking large projects up into small and manageable pieces that can be delivered quickly. This technique is why we are agile and can respond quickly to change. If a mistake is made or the customer doesn’t like what was made, it’s far easier to change direction if we didn’t go too far on the wrong path before having something to deliver.
More on managing complexity
To understand why you would consider an "incremental finance" approach, let’s look at a couple other examples of complex systems that your finance people and senior management will better understand: The stock market and hurricanes.
No one will guarantee estimates of the behavior of these systems in the long-term. No one legally knows what the stock price of their favorite tech company will be in one-year’s time. No meteorologist really knows where hurricane johnny is going to be in a week.
The best tools we have involve creating a forecast, inspecting at a regular cadence and updating the forecast based on new information. Let’s take a look at a financial forecast:
Figure 1 - S&P 500 2012 forecast
At the end of 2011 this graph represented the best information available to forecast what 2012 would look like. Notice the wide cone... its representing a large range of possibilities that could occur by the end of 2012. Also notice none of them involve the S&P 500 hitting 1000 or 2000. The range of possibilities narrows as you are nearer to the present. As it turns out, the S&P closed at 1257.60 on December 30th 2012. Just north of the bottom end of the cone. For passive investors, applying a dollar-cost-averaging tactic can help smooth out the rocky ups and downs of when you purchase and keep ROI favorable. This is an incremental finance technique.
Hurricane forecasting is very similar. This is a forecast made for Irene
Figure 2 - Forecasted path of Hurricane Irene
While the actual path of Irene was somewhat different than the original forecast, it remained within the forecast the whole time.
Figure 3 - Actual path of Hurricane Irene
To understand forecasting complex projects, you need to understand the cone of uncertainty. Its an easy-to-digest model representing the variance in estimates you’ll find in a complex system. When you are close to done, estimates vary less. When you are much further from done, estimates vary much more and it’s not a linear relationship.
Using this model, you’ll want to be closer to done when you estimate. The closer you get to done with any work, the more likely you’ll be right in estimates about when it will be finished. The further you are, the worse. Still feel comfortable giving an estimate to that e-commerce website rewrite?
Figure 4 - The cone of uncertainty
Explaining "incremental finance" to senior leaders
It’s important to discuss this with your senior leadership and to explain the complex nature of software development. Show them that long-range estimates include exponentially increasing variance as predicted by the cone of uncertainty. The key to success is breaking up large initiatives into smaller deliverable and valuable pieces... and fund those. If you can get your initiatives down to 3-month, completely finished projects, you’d be on the right track to better estimates and better funding decisions.
Projects often get batched larger and larger. Resist that urge and encourage your senior leaders to do the same. This technique is not that different than earnings forecasts wall street analysts produce and their follow up examination of true earnings public companies report quarterly.
I strongly recommend you employ an empirical process to investing in your company’s initiatives through with incremental finance and break the large batch project funding cycle that prevents true organizational agility.
Originally posted on www.responsiveadvisors.com
References
- https://en.wikipedia.org/wiki/Complex_adaptive_system
- http://money.cnn.com/2012/01/02/markets/stock_market_outlook_survey/
- https://en.wikipedia.org/wiki/Cone_of_Uncertainty
- https://www.google.com/finance/historical?cid=626307&startdate=Dec+30%2C+2011&enddate=Jan+2%2C+2012&num=30&ei=PN53WPCTCYe62Aam_4XoCQ
- http://www.investopedia.com/articles/stocks/06/earningsforecasts.asp?lgl=bt1tn-no-textnote
- http://w12thrd.blogspot.com/2011/08/hurricane-irene-update.html
- https://en.wikipedia.org/wiki/Hurricane_Irene#/media/File:Irene_2011_track.png
