Is Your Software Development Team Incompetent?

You’ve heard of the Peter Principle, right? People tend to rise to their level of incompetence.

According to Wikipedia. “It holds that in a hierarchy, members are promoted so long as they work competently. Sooner or later they are promoted to a position at which they are no longer competent (their “level of incompetence”), and there they remain, being unable to earn further promotions.”

The same fate can fall upon software development teams. Here’s how it could play out for a software team wanting to convert from waterfall to any agile approach such as Scrum, XP or Kanban.

We deserve a promotion!

Let’s say the team has been doing okay — perhaps not great but good enough to declare success on most projects. They read about agile software development and decide that trying a new approach may make them even better.

So, they ‘promote’ themselves to being an agile software team using XP. Being over-achievers, they dive right in using daily stand-ups, stories, pair programming, etc.

They don’t get business buy-in right away but conclude that they are good enough to work passed that issue and get the buy-in later.

Soon, they realize that some team members are falling back on waterfall because it fits within their comfort zone. Also, the business is demanding some of the traditional waterfall artifacts like requirements documentation.

So they corrupt (sorry, ‘enhance’) XP to make it a little more like waterfall — hey, it’s a blended approach! Little by little the software development team falls out of sync with the business folks and the team’s performance suffers.

They have risen to their level of incompetence!

They are forced to abandon XP claiming that it doesn’t work for them. So they ‘demote’ themselves back to waterfall and their performance improves. Obviously, waterfall is superior to XP (and by association, other forms of agile software development).

So is this band of over-achievers truly incompetent? Not at all. They needed training and/or coaching. They also failed to recognize the importance of getting buy-in from the business folks. If the business side of the organization is not engaged in the agile approach, improvements in the software team’s outputs will be minimal at best.

So, consider this:

  1. If waterfall is mostly working well for you, no agile approach will help unless you can change the behavior of the entire organization — a difficult challenge.
  2. If waterfall is not working for you, an agile approach might help — even if you cannot get full organizational buy-in.

Every situation is unique. Be sure you know what problem you want to solve and what result you want to achieve.

Updated: March 15, 2011 — 8:42 pm

1 Comment

  1. OK. I completely agree. I’ve seen it several times. The solution here is not stated quite strongly enough: training.

    If a team and company are very small and very close or you have an agile expert on staff who is leading the entire process, including executive and user engagement, then you have great outlook. However, if you exclaim, “we’re agile!” and then buy an agile book for each developer to set on their desk, it will not work. More importantly, if you maintain a traditional thick layer of middle management, proxied communication and/or silo’d responsibility – you’ll be frustrated and not enjoy success. You should seek training. You should find a good coach to come onsite and train your whole org, executives to phone support.

    You’ll never regret that worthy investment

Comments are closed.