What, ultimately, is Agile about?

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 being an employee.

  • An employee is someone you pay so you will be able to tell them what to do.
    • So it’s is best suited to command and control.
    • Which is the opposite of Agile.
  • A professional is someone you pay so that they will tell you what to do.
    • That’s why, when you go to your doctor, you (hopefully) don’t tell them what’s wrong with you or tell them how your condition should be treated – you just don’t know enough, and they (hopefully) do.
    • So it works better in a collaborative environment – which Agile is designed to create.

In short, the rule for dealing with professionals is Ask, don’t tell.

I suspect that whether an Agile initiative is successful depends heavily on the extent to which truly professional capabilities exist among your personnel, and whether your organisation has a professional culture. In that respect it would be very interesting to hear from people for whom Agile had not worked as to why it 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. But it’s not quite one way. If your people are not ready to be professionals, treating them as such probably won’t work. So what do I mean by professional? It’s a very big question that I won’t even try to answer here, but you could try this test: Are your people:

  • More expert at what they do than you are (at what they do)?
  • Self-disciplined enough to be trusted to solve or eliminate a problem once you’ve mentioned it, without any further direction from you?

Many years ago I had a boss whose definition of a ‘principal consultant’ was very similar to this: It was someone he could mention a problem to and he would never hear about it again.

It sounds simple. Which it is, in principle. But the training and coaching needed to get people who were previously treated as employees to operate as professionals (and therefore suited 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 implementations often seem to face, namely empowering staff to say No to their boss. Everyone needs 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 one or tw), 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. Not to mention being will to accept that other people – especially people who are more junior than them in the corporate hierarchy – should have authority over things they know about.

About the Author:

Chief Architect, Agile201.com.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.