Alastair Handley

alastair.h@home.com

Pragmatic Software Consulting.

Regardless of the quality of team management, or client management, a team is doomed if its players cannot collaborate in an effective manner. How than, can we create a situation where by a group of developers can be introduced to an agile process, and grow to embrace this change? The answer includes understanding, education, and communication.

Asking a developer working within a heavy weight process, or alone, to abandon their current process and adopt a completely foreign one is asking them to take an enormous leap of faith. We are asking them to abandon a process that they know and understand and step outside of their comfort zone. For developers eager to partake in an agile processes the step is welcome. Others will approach it with caution and some will approach it with fierce opposition. If an agile process is not carefully introduced, some developers may fiercely fight this change, while others will embrace it without fully understanding it.

The paradigm shift that these developers need to make in order to become effective members of an agile team can not be trivialized. Underestimating the difficulty that some developers will have making this shift is a grave mistake. Conversely other developers will believe that they have made the shift when in fact they do not fully understand the new process or the principles behind it. To successfully introduce an agile process we need to harness, and direct, the enthusiasm of eager converts while tempering the opposition of those that resist change. We need to manage people through the paradigm shift that is required to become an effective member of an agile team.

In some instances, developers will make the shift very quickly, for others it will take longer and for some this shift may be impossible. I suspect that the ease at which the shift is made may be based on many factors including experience, attitude, self-confidence and the level of trust that they have in the person or persons who are introducing this process. When we ask people to follow a new process we are asking them to trust our abilities, our experiences, and us. If they lack this trust they will not want to accept the risks associated with this change. We must listen to their fears and work hard to understand the real or perceived risks felt by the individuals on the team.

The risks associated with this change will vary from person to person. What are we asking them to give up by working in an agile process? What are they risking? What do they fear? Well, there are many possibilities, consider the following. An older more experienced developer may be assisted by a junior developer. Is there a loss of face, does the older developer feel threatened? Does a developer lack confidence in his code, does he believe that others will find it flawed or poorly written. Does the developer believe that their code is far superior to that of anyone else on the team and that by sharing it with the team it will be degraded? Is a person afraid to admit that they don’t know it all? Do they want to work on their own with their headphones on? Are they uncomfortable because they are being asked to work on a small unit of work while perhaps they do not understand or know the full scope of the system under design? The risks or fears that might be felt by a developer are many and to that person they are very real. A person can not hide in an agile process and for many, that is a very frightening prospect.

Restraining the eager convert can be as difficult, though much more fun, than dealing with an unwilling participant. These converts may not understand why other team members "don't get it". Their unbridled enthusiasm may be threatening to other members of the team. It is also possible for them to make misleading or incorrect comments about the process being introduced.

"We're doing XP. We run unit tests and pair program". While done with the best intent such comments and behavior indicate that the agile process is not fully understood.

Whether it is fear, or lack of understanding, the effects of these two states inhibit the introduction of an agile process. We must understand the fears of developers, and know what it is that they do not understood, so that we can mitigate the risks associated with these two states through education. Education requires effective communication. So the successful introduction on an agile process requires, understanding, education, and communication.