Agile for Powerplant Design?

June 23, 2011 Luke Walter

It’s all too easy to think of agile as a silver bullet – a magical solution to any organization’s dysfunction and the failings of its product development process. We often have to warn our clients of the silver bullet mindset at the outset of engagements so that they don’t have false hopes about what agile will do for them. In reality, practicing agile well can instead resemble one of those large magnifying cosmetics mirrors, the ones that when you stare into them reveal every pore and hair on your face in stark detail. The mirror won’t fix your skin or teeth or whatever it happens to be magnifying so effectively, but it certainly will show you your problem areas.

So I had to check myself when my second impulse upon learning of the multiple nuclear reactor meltdowns at Japan’s Fukushima powerplant – after the first one of horror and concern for colleagues and friends in Japan – was to think “Who the hell signed off on the use of that reactor design? I wonder if they’d used Scrum to design and build that plant this would have happened?” On the face of it, this is an absurd notion, for a great many reasons, the least of which is that civil engineering projects of such magnitude are usually poster children for waterfall development and predictive process rather than the empirical and adaptive processes of agile. But upon closer inspection, I think there are grounds to at least entertain of the notion.

The knowledge of the technology in question is one of them. Empirical approaches such as agile and Scrum are well suited to projects whose technology is unknown and whose requirements are highly changeable. The GE Mark I reactor chosen for the Fukushima plant was based on a design from the 1950s – the adolescence of the nuclear age – and nuclear power generation could hardly be considered to have been known technology at the time. Of course, an actual nuclear reactor probably can’t be built iteratively, but designs for one might be so that the technology assumptions made by the design & development team could be informed by feedback from stakeholders and customers.

What risks or requirements might’ve been raised and given credence in the Fukushima plant design by a more iterative and adaptive approach? It is difficult to imagine that with the full knowledge of the weaknesses of the Mark I reactor design, the stakeholders and end users of the product – which would include at the very least the people of Fukushima – would’ve agreed to the use of reactors of a type so sensitive to power failure on a coast with a known history of catastrophic earthquakes and tsunamis.

Scaling hypothetical stories and epics up to the size of those necessary to design and build a nuclear power station (indulge me), one such requirement could be expressed as an epic that might read: As a local resident, I want the reactors to remain stable in the event of a natural disaster foreseeable for this region (8-9.x magnitude earthquake + tsunami) so that the effects of the event are not compounded by release of deadly radiation.

While they weren’t stakeholders in the Fukushima plant project, Engineer Dale Breidenbough and two of his fellow engineers publicly resigned from GE over the failings of the reactor design used in the Fukushima plant. By analogy, what would happen if three programmers of a development team building, say, critical flight-control software resigned over what they considered to be a design safety issue? Do you think if such a project were using Scrum – with frequent interaction between the development team and the customers and stakeholders – the people paying for the project might take notice of such an event and reconsider some decisions?

Consider, too, the following anecdote, which highlights another reality of human work systems that waterfall projects fail to account for – namely, the dangers of groupthink: individuals working in groups of homogenous disciplines tend to come to the same conclusions, resulting in solutions more rigid, less creative, and more error-prone than those generated by heterogeneous groups of individuals from diverse disciplines.

‘The Mark I design stemmed from a model developed by General Electric in the 1950s, and from early on there were concerns about its safety. A revealing interchange on the subject took place in 1972 between Stephen H. Hanauer, an official with the Atomic Energy Commission, the predecessor of the Nuclear Regulatory Commission, and Joseph Hendrie of Brookhaven National Laboratory, later NRC chairman. Hanauer wrote a memo suggesting that the Mark I design—which the industry favored because it was economical—be discontinued because in an accident, pressure from hydrogen buildup might rupture the containment. Hendrie agreed, but complained that the Mark I was so popular with the industry and regulators that “reversal of this hallowed policy could well be the end of nuclear power.” ‘

This is another reality that agile is designed to address, through the emphasis on cross-functional development teams. Did the Fukushima plant’s planning committee include a geologist familiar with the tectonic history of the site? Because before the most recent quake and resultant tsunami, earthquakes & tsunamis of similar magnitude have struck the very same region 3 times before in the last 1200 years.

Previous Article
TeamForge For The Masses
TeamForge For The Masses

Engineers are typically from the ‘seeing is believing’ school and we’re no exception here at CollabNet. We’...

Next Article
CollabNet Subversion Edge 2.0 Released
CollabNet Subversion Edge 2.0 Released

I am pleased to announce the release of Subversion Edge 2.0. It is available for download and as an update ...