Although Agile can start anywhere in an organisation, very often it starts somewhere near programmers. Very often it will be a programmer who has had prior exposure to Agile or a development team who introduces the process or framework.
There is a hidden danger in this that is often overlooked. As a programmer, I find the concept of self-organising teams fundamentally important. I have worked for enough companies where programmers controlled by a hierarchy who had no idea about how to deliver working software to know that if you want programming work done, you let the programmers work out how to do it. Of course, this requires the appropriate context to be set – everyone needs to know what is required in order to help achieve it.
So the first stage of an Agile introduction is typically a small self-organising unit that doesn’t represent all of the roles required to deliver the software. Over time, the other roles are brought into the process, so that everything can be “done-done” within the Agile team.
It is when these new roles are added that the problem occurs. The maturing Agile team forgets the power of self-organisation and begins to dictate how the other roles should operate. They may know better, because they have experience and practice, but instead of applying the principles of Agile, they demand that their process is applied. This doesn’t work.
Carl Rogers explains that the hardest part of being a therapist is keeping quiet when you know the exact answer to someone’s problem. Instead of telling them what is wrong with their personality, why it causes the problem and how to fix it, the role of the therapist is to lead their client to discover these things for themselves. While telling them immediately may save time, helping them to discover the truth for themselves has a lasting and positive effect. (Read “On Becoming a Person” for more on this).
So if you find yourself in the position of Agile coach, whether as an officially mandated role or due to your valued experience, you need to let each role discover its own way of working – even if it isn’t what you would do. You can lead them towards better ways of working, but as soon as you introduce the command and control method of introducing change, you’re missing many of the benefits associated with having motivated and energised people trying to do the right thing in their own way.