In the Software Industrialization blog entry Software Development Gone Insane, Mitch Barnett puts forward the case for CoCoMo, the software COnstructive COst MOdel developed by Barry_Boehm in the 80s.
Mitch’s initial target is ‘Scrumban’, an apparent portmanteau of Scrum and Kanban. Like Mitch I haven’t read Corey Ladas’ book, but I’d have to concur with Mitch that the author’s various articles and blog do smack more than a little of MBA newspeak – though I have more of an issue with Corey’s use of the redundant “Personally, I”. In defense of Corey though, I think he’s try to articulate an important point: that there are existing solutions from other disciplines – in this case manufacturing – that current software processes can benefit from.
Mitch’s other chief contention is that our industry is driven by fashion – and I find it difficult to disagree with him here. I’m still waiting for aspect-oriented programming to take over as I was told it would almost a decade ago – and if someone hits me with another xDD new paradigm I’m likely to stab them in the eye with a fork (for the record, I fully appreciate both TDD and BDD.. though both have had other names in the past). We have to be open to new ideas – and there are many new ideas to contend with – but we also have to be wary of old ideas just being repackaged as new ones.
Sometimes we forget that we stand on the shoulders of giants. If we look at the history of Scrum you can see a lineage tracing back to CoCoMo, via another of Barry Boehm’s significant contributions to software development: namely the Spiral Model, a direct ancestor of the iterative approach to development used in agile methodologies. To dismiss CoCoMo – or indeed any other “old school” model – out of hand is to fail to recognize the fundamental basis that our modern ideas are built on.
Scrum claims to be an empirical methodology, though it should be stressed that ‘empirical’ here is as understood as controlling development ‘through frequent inspection and adaptation for processes that are imperfectly defined and generate unpredictable and unrepeatable outputs‘. It’s a slightly more ambiguous meaning than ‘empirical’ in the scientific-method sense of the word, but the two notions aren’t that distinct. Essentially we are talking about progress being measured by observable phenomena and not against just a theoretical plan. Scrum also owes a debt to the venerable Plan-Do-Act-Check model of the Deming Cycle, where the results of one cycle and feed into the next as a mechanism driving constant improvement within a project. A ‘sprint’ is an example of the Deming Cycle model applied within Scrum.
Cases where I’ve seen Scrum fail badly is where the process is perceived as a panacea, with no heed is given to the history or foundational ideas underpinning Scrum.
A project I worked on a number of years ago used Scrum as the backbone methodology, with a sort of ad hoc statistical analysis thrown in for good measure. One of the interesting things to come out of the process was the observation that within each iteration something between 25% and 30% of all work that appeared in the Sprint Backlog by the end of the sprint was unscheduled at the start – that is, almost a third of all work executed in the sprint was ‘discovered’ in the course of an iteration. Management were convinced that this previously undiscovered work was an aberration and we would “do better next time”. Such wishful thinking flew in the face of the data we were collecting and denial that there was something inherently wrong with our scheduling. And yet the same thing happened, month after month.
Obviously the team wasn’t following strict Scrum rules, as we were allowing new work to be added during an iteration. Some of this was things the team hadn’t thought of at the start of the sprint, some was stuff that management now deemed suddenly important and worth disrupting the sprint for. The statistical ‘evidence’ we were gathering pointed to a 25-30% cost overrun in each sprint, yet it was being blithely ignored by the business. Instead each subsequent sprint was overloaded like the last, everyone ran around like crazy trying to complete an impossible task, developers burnt out – and no-one spent any time considering why we were consistently running over budget.
An alternative – and one that I tried to get past management – was to budget for 30% ‘undiscovered’ work each sprint. They wouldn’t have a bar of it of course – which I understand. The managers were part-time developers too, susceptible to the same optimistic estimations that many coders are guilty of. Yet here was a clear “empirical truth” that was being denied. We were guilty of treating Scrum as a silver bullet, and not applying the scientific rigour the situation required. In this we did a disservice to both the Scrum process and to our own project. It’s possible that if we’d used something like the CoCoMoII we could have instrumented our implementation of Scrum with tools to manage the project effectively, given us the factors to explore our estimates and progress using statistical analysis.
Sometimes the cost of scientific rigour is difficult to justify in a “it builds, ship it now – they need it urgently” environment. But it’s important to know what you are trading off. Sometimes it’s just a matter of business priorities, sometimes it’s a way to satisfy an innate desire to run wild.
CoCoMo is arguably a scientific approach that could have a place in a lean model of software development. Agile could probably benefit as well, as a means for providing the important feedback loop that methodologies like XP value so highly. For agile methodologies to work they have to have the right mix of practices and processes for the job at hand. My chief concern with CoCoMo is that it assumes the Big Design Up Front model that’s just not appropriate in many projects, where the scope or risks aren’t clearly defined and have to be discovered through an iterative process. That shouldn’t be taken to meaning that CoCoMo can’t be adapted to different projects or processes, nor indeed new uses found for this older technology.
It’s interesting to note that Ohloh ostensibly uses CoCoMo to derive its metrics on open source projects. The estimates on Ohloh often seem way too high – sometimes by an order of magnitude – but as a software developer I’d have to acknowledge the tendency to underestimate how long a project will take anyway. As an investigative tool, CoCoMo may have some merit in examining how much a project should have cost – as a post-implementation tool to uncover inefficiencies in a Scrum project, and as means of benchmarking across projects.
I think that what Mitch is ultimately driving at is that young software developers would do well to look at lessons learned from the past and build upon them. I’m not convinced about the utility of CoCoMo in many of the projects that young programmers will face – the landscape has changed and project management has moved away from the large-scale up-front specifications that made Waterfall the dominant model of development. But maybe one of these young up-and-coming developers will find new ways to use old tools. Perhaps we’ll hear of “Agile CoCoMo” becoming all the rage. And perhaps the old timers we would have become won’t be so jaded as to dismiss it out of hand.
