Where’s the Incompetence?

Scrum is no silver bullet, and that it does not bring out excellence, but exposes incompetence.
— Ken Schwaber

So this is a great quote and it really resonates with any organization that is implementing scrum.  What you will inevitably find while implementing scrum is that certain team members and more importantly team functions and or departments are just not able to get the job done, or simply incompetent.  Maybe incompetent is not the best choice of words, but what I’ve found is that those people or departments that are asked to do something different, maybe step-up, or simply be around — stick out quickly when they are not performing well.  Within larger organizations, it’s not too uncommon to have team members that are able to hide and do just enough to skate by — this doesn’t work well within Scrum teams.

Weak LinkThe analogy to the weakest link in the chain is a great one for understanding the impact of a person or team that is not strong enough or capable of delivering on commitments made.  Just like a chain where the sound links of the chain can absorb the stress for a period of time, eventually the weak link breaks, the chain fails, and repairs must be made.  With implementing scrum, the level of stress remains constant and steady; thus, in short period the weak links appear.  When they do, preventive action should be made promptly to keep the chain, I mean the team, from failing.

So, what can be done?  Here are a few ideas that may work for your team:

  • Process Training.  This one is a lay-up.  Sit down with the team member or department head(s) to discuss their level of understanding regarding the Scrum process, how agile changes impact them, and how they can benefit from being part of the changes.  Identify opportunities for core agile process training, tool training, or possible soft skill training.
  • Identify the Strengths.  Often when a team member or department is failing, it is because they are working outside their strengths.  This does not mean that you change the team member or departments responsibilities, but it does mean that you might consider identifying ways for the team member or department to get their commitments complete while leveraging what they do well.  I wrote a previous blog about Strengths Finder, this is a great exercise for all teams — this will help a team to self-organize to ensure everyone can be successful.
  • The Team Adjusts.  Since the Scrum Team is cross-functional, identify ways that the weaker team member can meet their commitments.  This may be through have a team member move from developing core functionality to assisting QA on building out a test harness or possibly a QA team member working on documentation.  Often, when a team member is not performing well, it often ruins their self-confidence and this lack of success will continue.  Find tasks that the team member can be successful, get them some small wins, and see if that improves their outlook and inevitably their ability to perform.
  • Make the Hard Decision.  It may come to a point where a team member is just not cutting it, or because of their inability to meet commitments — they are bringing down the rest of the team.  It may be time to for a significant change — and a need to release the team member.  This is often better for the team, the individual, and the organization.  It is a hard decision, but one that needs to be made.  Allowing a non-performing team member to continue with the team and not meet commitments sends the wrong message to the rest of the team, and the Product Owner will start questioning the leadership of the team.  If it is a department that is not performing, it may be time to face this head-on and escalate the need to get better performance from that department.

My career journey has had me wearing many hats ranging from Systems Analyst to Programmer to IT Manager to Programmer to Director. Today, I work as a coach and instructor to the leadership and team members of organizations on their agility journey. I'm constantly practicing to be a good learner, aspiring to be an inspiring leader, and I'm constantly walking the line between pragmatism and conviction when it comes to the application of lean and agile principles and practices.

Matt’s purpose is simple, “I believe in working with teams to help them get better, learn, and be successful in building stuff while having fun.”

At the end of the day, Matt believes in integrity, hard work, curiosity, people, and faith.

Leave a Reply

Your email address will not be published.

CommentLuv badge
Previous Story

Technical Stories – How to Work Them

Next Story

Reinvigorated Retrospectives

Latest from Agile Engineering