“Well established hierarchies are not easily uprooted;
Closely held beliefs are not easily released;
So ritual enthralls generation after generation.”
Tao Te Ching
All change is difficult. It requires strong leadership and an understanding of foundations needed to instantiate the desired change. Most of all change requires that ingrained habits are replaced with new habits. And, since we are creatures of habit, change is very hard for human beings.
For the practitioner of scrum and agile development techniques this aversion to change and the resilience of old ways is a key challenge.
Within any enterprise exists an established hierarchy. Inherent in this hierarchy are rules that govern rewards, promotion, power, punishment and failure. Many people within that hierarchy have invested large amounts of effort, emotion and pride into meeting the demands of these rules.
We have vast amounts of longitudinal evidence that it is hard to build what users want to meet their budgets and time lines. The well known Standish Reports on software development projects show that in 2006 “19 percent of projects begun were outright failures, compared with 31.1 percent in 1994”. These are not very good results, even if they have improved over a decade.
Agile methods such as scrum are an attempt to address this perennial problem. However, in trying to implement them we are embarking upon a significant corporate change program.
For the past 30 or so years we have inculcated in people adherence to a system of software development that is generally termed “waterfall“. This software development life cycle (SDLC) approach is very structured and is actioned like a Henry Ford style production line. This means that the hierarchy around software development in most company’s IT department is tied in strongly to the waterfall approach to systems development.
This focus on the waterfall SDLC is also reinforced by non-IT management who like it because it appears to offer control and structure. The documents, GANTT charts, diagrams and other artifacts give management comfort that all is under control.
Yet the very results we see for software projects every day around the world tell us that this control and structure is merely an illusion.
The question I have been asking for several years now is have we found a better way? And, is that way agile or is it merely another illusion?
More to come on this topic later …