How good is DSDM?

I recently initiated a discussion on LinkedIn entitled How good is DSDM? Although there was (unsurprisingly) a consensus that DSDM was A Good Thing, we were collectively unable to come up with much hard data until Jennifer Stapleton – a past Technical Director of the DSDM Consortium – kindly offered me some data from Xansa (bought by Steria in 2007) and British Airways. Xansa’s data is especially interesting, as it covers a number of clients (including BT) and Xansa was, at that time, the world’s largest DSDM practice.

The gist of the data is that DSDM offers huge improvements in productivity, team size, delivery time and project quality. Here are the basic graphs (not as contemporary as I'd like, but still solid data):

What, ultimately, is Agile about?

There is an interesting discussion of Agile going on at LinkedIn at the moment. The topic under review is 'Transitioning from command and control to a servant based style of leadership'. personally I think the idea of 'servant leadership' is both misconceived and redundant, as the answer (so far as I understand the issue) was provided by the German sociologist Max Weber about a century ago.

In brief, at least as far as successful Agile projects are concerned, I suspect that this change in the way organisations work under Agile is closely connected to the distinction between being a professional and an employee.

• An employee is someone you pay to be able to tell them what to do, and is best suited to command and control.
• A professional is someone you pay so that they will tell you what to do, and so works better in a collaborative environment - which Agile is designed to create.

Conversely, I suspect that whether an Agile initiative is successful depends heavily on the extent to which truly professional capabilities and a professional culture exist. In that respect it would be very interesting to hear from people for whom Agile had not worked as to why it had failed.

Note the causal direction. If companies insist on command and control, they get employees – i.e., people who need to be told what to do. If you give people opportunity and responsibility (and a non-trivial amount of skill), you will get professionals.

On the other hand, the training and coaching needed to get people who were previously treated as employees to operate as professionals (and therefore suite to Agile) can be very great. The transition is not easy or straightforward, not least because the skills required are by no means solely technical. There are personal and social capabilities that are also required to succeed at Agile. But they are encompassed by the concept of professionalism.

This can be exemplified by a major cultural problem Agile implementaitons often seem to face, namely empowering staff saying no to their boss (eg, the Agile PM). Managers need technical training (i.e., how to do Agile) but other team members need the social and personal ability to insist on their own professional perspective. Few organisations cultivate this attitude (though I have known a few), but I would say that it is crucial to making a success of Agile.

The same point applies at the other end – to business stakeholders. They also frequently need a change of culture – to become involved, to own the project, to participate effectively, to accept an incremental approach and to be able to change their minds without embarrassment or political penalty.