In my last post I began the discussion about the big Elephant Impediment in many agile development teams. Here I will continue the discussion of why we tend to have them around and also explore making sure you actually do have this Elephant Impediment and not something else.

In the current politically correct and litigious American social and business culture, many companies are resistant to removing those non-committed, low performing resources in fear of legal action or because some managers fear it is too much of a hassle given the corporate policies put in place for doing so.

Instead, low performers are often tolerated and allowed to reduce the capabilities of a team and bring down the morale of others on the team. This is especially damaging to an agile team where respecting the commitment a team makes requires empowering them to be decision makers, self-organizing and largely self-managed. To not do so will usually handicap an agile team in realizing continuous improvement which also impedes their ever reaching the ‘perform’ state. So how does this form of impediment get removed? The answer is with courage and servant leadership.

Successful agile development organizations have servant leaders. One of the key roles of a servant leader is to facilitate the removal of impediments that either they see for the team or that their teams themselves report. In my experience, the impediment of a non-committed, low performing team member is one of the more commonly reported impediments that is rarely dealt with for the team and organization’s benefit.

Of course care should be taken when making this assessment. An individual who is not performing well on one team shouldn’t be labeled as a low performer in general. The question needs to be asked; Is the non-committed, low-performing resource in the wrong context? A low performing resource on one team may not be that way in a different context. By context I mean the combination of work assignment, personal life, company / team culture, personalities, and physical environment.

For instance, a resource may be committed and capable but there are other things going on in their life that are affecting their performance? Does the team understand this? Consider the example of a vehicle driving down the road in a sporadic way weaving in and out of traffic… What is your reaction? More often than not, it’s probably pretty negative and inclusive of an explicative.

Now take this same vehicle and put a Red Cross symbol and the word Ambulance on the sides… now what would be your reaction? Having more information can change the way one interprets behavior because it helps them to understand motivation. This understanding tempers the way one reacts. This is true in a team environment as well.

If a team member isn’t delivering on their commitments to their team in a low trust and poor communication environment, the interpretation of the performance is usually pretty negative. Now say that there was trust and open communication in place. If the individual who began missing their commitments communicated that their Mother had passed away and they were a bit distracted, the reaction would almost certainly be different.

Other team members’ negative interpretation of the low performance usually switches to one of understanding and support. Having trust and open communication on an agile team is one of the keys to enabling and realizing value from self-organization. Team member contribution can ebb and flow to handle situations where another member’s contribution is affected by a change in their context. This understanding and support only furthers the bonds on the team and elevates the level of trust. This type of team trust can’t be instilled by an external force such as a manager.

For all the skeptics and “touchy-feely” avoidant folks, I’ll state the obvious. This won’t work if everyone on a team does not have all their cards on the table. You can have a manipulative individual who fabricates excuses that elicit a more human response of understanding and assistance from their team to get them to do their work. On an agile development team, because of the iterative nature of execution, this type of behavior will eventually become obvious. This self-serving type of person is poison to any team environment and should be identified early and excised from the team as a surgeon would do with a tumor.

In my next post I will explore some of the tools and techniques teams and organizations may want to consider in addressing this Elephant Impediment in the room.

Join the Discussion

    There are currently no comments.

    − 4 = 1