My entire career has involved technology in one form or another, but I have gradually drifted over the years from spending the majority of my time designing and developing technology solutions to a focus on teams and organisations. As both my role and technology have evolved, I have often been frustrated by the “one step forward, two steps back” story that has characterised the development of most corporate IT departments.
With the best of intentions, many IT Managers and CIOs have inadvertently set themselves and their teams up for failure through an overly prescriptive focus on process, metrics, best practices and the like. Whilst they all have their use, this focus has primarily served to take attention away from the actual point of the various projects, products, and services being delivered – the outcome, the business value being delivered to the end-user of the product or service.
Tom DeMarco recently paused to reflect on the evolution of Software Engineering as a discipline, including his own role in influencing its focus on metrics.
Like myself, the author of the much-quoted “You can’t control what you can’t measure” is staring to wonder whether this orientation has distracted us from the real point of computing, in his words: “The more important goal is transformation, creating software that changes the world or that transforms a company or how it does business.”
His conclusion, under the title “Software Engineering: An Idea Whose Time Has Come and Gone?” appeared in the July/August 2009 edition of the IEEE Software magazine. In this article, DeMarco defines “software engineering” as follows:
The term encompasses a specific set of disciplines including defined process, inspections and walkthroughs, requirements engineering, traceability matrices, metrics, precise quality control, rigorous planning and tracking, and coding and documentation standards. All these strive for consistency of practice and predictability.
Reflecting back on this book, he saw much truth, while also noting that this discipline operates differently than natural sciences like physics: “software development … metrics … must be taken with a grain of salt.” He went on to consider the book in relation to the concept of delivered value, leading him to now suggest that:
… the more you focus on control, the more likely you’re working on a project that’s striving to deliver something of relatively minor value. To my mind, the question that’s much more important than how to control a software project is, why on earth are we doing so many projects that deliver such marginal value?
Before concluding, he briefly suggested a more suitable incremental management approach whose spirit will ring familiar to Agile teams and their customers.
A concentration on outcome, delivery of value, and de-centralisation of control are all central to the Fu, and it appears that even the most traditional of practioners are now seeing the wisdom in this approach. In fact, this holds true outside of the IT department, and applies to the entire enterprise.
