14. Predictability and agility
One of the core differentiators between successful and unsuccessful platforms is speed of execution. If the customers of a platform grow impatient at delays in deliveries from a platform, they are likely to take matters into their own hands:
- Defecting to an alternative platform
- Exiting the product area altogether
- Providing their own software, to fill in the gaps in the platform – thereby risking fragmenting or weakening the platform.
Customers of Symbian OS fell into all three categories – with the third category ultimately proving the most devastating to the future of the platform. In this sense, poor speed of execution was a key part of the downfall of Symbian. As we’ll see, the chain of cause and effect has many links in it.
One of the determinants of speed of execution is clarity of vision and singularity of purpose. If everyone agrees on what the key priorities are, things can happen a lot faster. As I covered in the chapter “DFRDs in turmoil”, we struggled in Symbian, in the company’s earlier years, with clarity about the central requirements of the platform we were delivering. Even once it had been decided that we would no longer target the creation of UI systems – and the phrase “DFRD” had slipped out of regular usage inside the company – lots of questions remained about the priorities of different technology areas. For example, how important was a real-time modification of the kernel? How important was a comprehensive re-write of the security infrastructure of the operating system? And how important were the very latest WAP and web technologies, etc?
Debates about the relative priority of technology enhancements are an inevitable aspect of the stage-by-stage creation of any complex software platform. Symbian’s TechCom forum provided useful input to our in-house team of Technology Managers, who collectively made the prioritisation calls that guided engineering effort. On the whole, this process worked reasonably well – though with some bad exceptions, that will become clearer in later chapters.
What worked less well, however, was the speed of the engineering effort. Even when the broad technology direction was clear, it took our engineering teams too long to deliver the software in our roadmaps. This chapter examines why this was the case – and the approaches taken to make amends.
One cause of the slow speed of Symbian platform development was the special focus that had come on the company, from 1999 onwards, on our releases being “predictable”. Rather than committing to delivering (say) 20 items of technology, in a particular release, we should commit to delivering just 10 items in that timescale – since we would then be more likely to meet the committed delivery dates for these technologies. That was what our licensees strongly requested.
The reasoning is that licensees could plan their own projects more reliably, once they had greater confidence in the timeliness of the contributions to their projects from Symbian. As for the items missing in our release, well, licensees would have plenty of time to make their own alternative plans to address these omissions, rather than finding out too late, well through their project, that Symbian would be dropping an item that was integral to their project plans.
Symbian’s focus on predictability became reflected in the metrics and objectives which measured the performances of software leads and project managers. Software managers whose projects missed their anticipated deadlines were regarded as failures. Unsurprisingly, this led to a change in the way that projects were planned:
- Rather than giving estimates for reasonable outlier dates, for when a project would be completed, team leads gave near worst-case estimates , “just in case” a rare combination of events would delay project delivery; these worst-case estimates could be 50-100% longer than estimates they would otherwise have provided
- Integration managers added further “buffer” into their project plans, to provide themselves with additional leeway, “just in case” factors conspired against them.
It’s similar to estimating how long you will take to complete a journey in a busy city with potentially unreliable transport infrastructure. Let’s say that, if you are lucky, you might complete the journey in just twenty minutes. Perhaps thirty minutes is the most likely time duration. But in view of potential traffic hold-ups or train delays, you could take as long as one hour, or (in case of underground train derailments) even two hours or longer. So there’s a range of estimates, with the distribution curve having a long tail on the right hand side: there’s a non-negligible probability that the task will take at least twice as long as the individual most likely outcome.
It’s often the same with estimating the length of time for a task within a project plan. But here’s a worrying paradox – first drawn to my attention in books written by Eliyahu Goldratt, such as “The critical chain”. If estimates for complex software projects are designed to be fulfilled around 95% of the time, and therefore including significant padding, they typically end up being fulfilled only around 50% of the time. That general principle matches what I saw happening at Symbian.
This “predictability paradox” deserves some careful reflection. Even though the estimates were generous, it seems (at first sight) that they were not generous enough. In fact, it’s the project planning process itself that causes the overshoots. Here’s what happens:
[ SNIP ]