Yesterday we alluded to better methods for IT to adopt, to fit its operations for the modern age. Methods arise from principles of operation, so what principles are of use in the age of uncertainty?
Software development VP Larry Cone, writing in ITtoolbox, has been presenting valuable views on the development process in his articles on failure management.
“A project in the age of uncertainty is less like a construction project, and more like an experiment.
“Because uncertainty is so prevalent in many projects or enterprises, the experimental model of success is a better match than the construction model. In my earlier years with software projects, I felt instinctively that the blueprint/construction project model was flawed, but I wasn’t sure why. It is this higher level of uncertainty that causes the blueprint/construction model, often referred to as the waterfall model of software development, to be inappropriate for many projects.” – Learning From Failure – Models for Failure
It sounds heretical, but then again it will take some heresy to break IT out if its many traps and into effective alignment with the rest of the organization. In this vein it’s worth also revisiting Andrew Clifford – another invaluable writer at ITtoolbox – for his take on the trap that IT is caught in.
“We are on a heretical journey. We have seen that the structures of IT - architecture, organisation, decision making – are largely a by-product of engineering necessity, and that these form an alternative reality that does not align with the realities of business. And our IT management response, rational and valiant though it is, further entrenches this misalignment. We are in a hole, and we are trying to dig ourselves out.” – IT entrenches misalignment
Yesterday we disposed of the false dichotomy between the notions of effectiveness and alignment, following Demian Entrekin’s observation that the two go hand in hand – after all it will be the business side that decides if IT is effective or not, which would seem to validate alignment. We’ll have more to say about this at another time.
For now we return to Larry Cone’s failure-management scenario, and his latest post in which he establishes some principles – methods – for using failure as a tool of innovation.
“Failure is not useful if the act of failing doesn’t help us move ahead. What is most important when declaring a project a Failure is what you do next. Upon failure, several doors open.
“One door is the door of analysis – with Failure, it is natural to try and figure out what went wrong. Actions are questioned, assumptions reviewed, and goals are thrown out. It is a natural time to question our methods, and to review our assumptions.” – Learning From Failure – Question Assumptions
There is much in this view of failure as a positive means of getting it right that resembles agile development. Dovetail Software is an agile developer and the Dovetail engineers’ blogs illustrate many of the principles – and tell many of the tales – of this methodology.
In many striking ways, agile development, with its short bursts of speculative iteration – saying in effect, does this work? – resembles nothing so much as an outright challenge to fail. Or to succeed, as the case may be. But either way to produce feedback quickly, so that the project can continue to invent itself, all the while learning, as it expresses itself against the process requirements.
