The Elephant In The Room – Part II – Don’t Camouflage Him

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 person in the wrong context?  A low performing person 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 person 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 team 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.


About Mike DePaoli

Mike DePaoli has been contributing to the IT community for over two decades and practicing agile and lean approaches to software development since 1996 in roles from programmer to CTO. His evolved approach to crafting successful lean-agile software development organizations was forged by the meaningful challenges he undertook at prior employers and as an Agile Coach at companies such as eBay, Adobe Systems, AOL, NetApp, Disney, Boeing, EMC, and Trizetto. Mike’s area of expertise is helping organizations craft strategic change initiatives that educate on and establish agile and lean values, principles and practices at every tier of the organization. Mike applies systematic thinking with a multi-discipline approach to his work. Mike is a Certified SAFe Agilist, Certified Scrum Professional, Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO). He is a highly-regarded speaker in the Agile community having spoken at Agile conferences in North America, South America and Europe. He is currently based in the San Francisco Bay Area.

No comments yet... Be the first to leave a reply!

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development


Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development

The Agile Horizon

Lean-Agile Leadership - Exploring the Creation of Fertile Environments and Culture for Lean-Agile Software Development

%d bloggers like this: