4 steps to deal with a ‘Bad Apple’ in Agile Transition


Working with the “Bad Apple”

We’ve all heard the phrase “One bad apple can spoil the whole bunch.” While its origins are not entirely known, I would imagine that it originates from an apple orchard farmer who would purposely remove that apple from the bushel so that it’s disease would not spread to the rest of the apples.

When teams are in the transition to good Agile practices, whether from another ALM (Application Lifecycle Management) or from poorly implemented Agile practices, you will often find your team has a “bad apple.” They will often reveal themselves in one of a few various manners such as:

• Half-hearted participation: They won’t update their task/story cards on the Board, will show up to meetings consistently late, will size all stories the same, or some other means of half-hearted participation to indicate that they either don’t care or don’t believe in the changes.
• Combative participation: They’ll attend meetings but you will find that they are combative during the stand-up, during sprint planning they are un-comfortable no matter what the size of the commitment is.
• Refused participation: They just refuse to participate in the meetings, code reviews, pair programming, unit testing, or any Agile practice.

When to Step up / When to step back
As an Agile practitioner you have to be able to discern between “when to step up” and “when to step back.”1 Before we look at what to do with the “bad apple.” Let’s first look at what I mean by “stepping up” and “stepping back”.

Stepping Up
Determine if it is time, as a leader, to step up and “assist/guide” them towards success. You don’t want to find yourself where you constantly have to come to their rescue, but you also don’t want to let them continue to fail either.

Stepping Back
When working with team members stepping back goes beyond trusting them to do the job they were hired to do. What this also entails is allowing the team or team members to experience the failure within the team. This way the team can learn to be self-managing and learn to be successful from its failures.

As with the bad apple in the bushel, the “bad apple” on the team needs to be dealt with to prevent spreading of the “disease.” However, it isn’t always recommended to just “remove” the bad apple. So what do you do?

Understand their reasoning: Talk with the team member apart from the team to better understand the reasons why they are resistant to the transition to Agile. Be sure to not discount any of their reasons.

One of the possible reasons for their resistance is that they may have experienced failed attempts transitioning to Agile.

Recognize their strengths: Point out the team member’s strengths and offer insight as to how the team member can use their strengths to help the team.

Possible strengths may include their knowledge of the business logic, their understanding of the technology, or their experience in their particular practice.

Minimize their weaknesses: Recognize the team member’s weakness and offer suggestions on how to minimize that weakness or turn it into an item of strength for them.

Weaknesses can include a lack of understanding or experience with Agile methodologies, their passion to not repeat past mistakes, lack of experience with technologies, or being uncomfortable with change.

Provide smaller challenges of change: Based upon the team members reasons for their resistance, their strengths, and their weaknesses, offer smaller challenges of change to them.

Unlike the bad apple in the bushel, your team member can learn, change, and grow. Resistant team members need to be guided, encouraged, and mentored along the way.

What’s your experience with a bad apple in an Agile transformation, and how did you handle it?

1. http://www.accelinnova.com/docs/stepup.pdf

Sogeti Labs


SogetiLabs gathers distinguished technology leaders from around the Sogeti world. It is an initiative explaining not how IT works, but what IT means for business.

Related Posts

Your email address will not be published. Required fields are marked *