.

21 July 2008

Scrum, Agile and the Enterprise - Part 1

"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 soon ...

By Carruthers via Aide-mémoire

2 comments:

Mark Cohen said...

Hi Kate,

I'm a Scrum evangelist, and I swear Scrum and Agile development work brilliantly. I'd also happily confess that I've seen them fail miserably. It's a methodology not a silver bullet.

The biggest obstacle to the success of Scrum in my opinion is when senior management, marketing, strategy and sales teams within a business refuse to move from demanding a fixed date for delivery. This is usually handled by estimating, padding out to improve certainty, adding some contingency, and only then going back to the business with an ETA

There's a great book called "XP Refactored" which discusses XP (Extreme Programming) and how it went wrong at Chrysler. It is definitely to be taken with a pinch of salt but it's well worth a read.

Mark

dw said...

Hi Kate,

I'm personally drawn to and wholeheartedly endorse the principles espoused by the Agile Manifesto. See:
http://www.agilemanifesto.org/principles.html

Simple, clear articulation of the desireable essence in my view. Web facilitated continuous change is the paradigm shift in commercial interchange we have no choice but to come to grips with.

And while I agree the fundamental issue confronting project execution utilising these principles is reluctance to change, in my experience it is not only senior management but technical practitioners themselves that impede the way forward. Both management and the key practitioners delivering the solutions want less uncertainty and yet from every side comes increasing demand for iterative flexibility.

You pose the question; "have we found a better way? And, is that way agile or is it merely another illusion?"

I'd postulate that the winners in all this will be those who can make Agile work efficiently as an interface between business objective realisation and the work processes entailed in getting there.

Key to this being achieved is the enterprise and its outsource partners rising above tactical level play to efficiently embrace strategically informed interplay between IT project governance and the firm's marketing orientation.

Whew that's a mouthful - but it goes to the heart of the dilemma. There is an unprecedented convergence of skills disciplines involved in all this which defies simplification for early adopters. Bottom line it is hard and will get harder for a while until the paradigm shifts achieves a degree of normalisation.

Intended outcome (marketing orientation) must continuously inform project governance as an ongoing sustained cycle of engagement.

Fascinating stuff.

Dion