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.
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.
No comments:
Post a Comment