The Problems with Overachievers on Agile Teams


Agile and the Overachiever
With an overachiever, a common theme emerges of the hero pushing aside the team. The values of the agile manifesto—that people are important—become hollow words, Products are no longer built around motivated individuals (emphasis on the plural), but are built around an individual. As the Agile Manifesto states: “Build projects around motivated individuals. Give them the environment and the support they need, and trust them to get the job done.” [4] Note that this refers to “motivated individuals” working collaboratively, not to individual contributors working alone. The effect of an overachiever can mitigate many of the great principles of the Agile Manifesto. For example, the manifesto states: “The best architectures, requirements, and designs emerge from self-organizing teams.” [4]. Too much emphasis on the individual is the opposite of what Larman and Adkins so aptly described in Agile and Iterative Development: a Manager's Guide and Coaching Agile Teams.

Agile development emphasizes decentralized and lateral control structures and reciprocal power relations and encourages employee creativity and initiative by putting the context of the work squarely on the shoulders of the team. Team members must be comfortable enough to make mistakes; otherwise, the team cannot develop and use its abilities. Leadership must promote acceptance of ambiguity, facilitate collaborative teamwork, and promote exploration [7]. Leaders—through formal training, individual discussions, and example—must coach the team on effective group dynamics, build the team’s confidence, and help team members embrace ambiguity [6].

In an agile environment, the team should be the center of work and productivity. Yet, each sprint provides an opportunity for the hero to pull out the stops and meet the sprint goal. This can become a positive feedback loop for the overachiever, who is gratified by his contribution. This behavior artificially inflates velocity since the team completes more work than is possible under a sustainable pace.  Eventually this rush to completion at all costs leads to another iteration of overly optimistic commitments.

An overachiever may hoard tasks or even whole stories, ensuring that he is the center of the team’s effort. Even pair programming [8] can provide an opportunity for an overachiever to show off as he reduces his partner to a passive observer.

User Comments

1 comment
Dave Maschek's picture

The key to this article was that the overachiever "secretly felt insecure". The authors make a good case how overachievers can subvert an Agile team by trying to do everything and thus not allowing others to function as full team members. However, I have seen insecure underachievers cause trouble on a team also. The corporate world has insecure people who can subvert a team by not sharing information, playing safe by always painting a rosy picture, putting up unnecessary roadblocks, giving outdated advice, stubbornly acting against Agile principles, insisting they are always right and so on.  

August 14, 2014 - 12:25pm

About the author

Charles Suscheck's picture Charles Suscheck

Dr. Charles Suscheck is a nationally recognized agile leader who specializes in agile software development adoption at the enterprise level. He is one of only 11 trainers worldwide and 3 in the US certified to teach the entire cirriculum.  With over 25 years of professional experience, Dr. Suscheck has held positions of Process Architect, Director of Research, Principle Consultant, Professor, and Professional Trainer at some of the most recognized companies in America. He has spoken at national and international conferences such as Agile 200X, OOPSLA, and ECOOP on topics related to agile project management and is a frequent author in industry and academia. Dr. Suscheck has over 30 publications to his credit.

About the author

Andrew Fuqua's picture Andrew Fuqua

Andrew Fuqua is an agile coach with more than twenty-five years of experience programming, managing, and coaching. Much of his experience is with commercial software development at various independent software vendors, though he's had increasing experience with IT organizations for the the last seven years. Andrew has been using agile methods since 1999, including five years pair-programming in a test-driven environment.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!