Truthfulness in Agile

I believe in Agile. To the best of my knowledge and based on my experience, Agile methods are the best way for teams, organizations and communities to get stuff done. Doesn’t mean it’s easy though! The biggest challenge of Agile is in the need for truthfulness.

Most of us live and work in environments where the truth is not totally welcome. Maybe it’s “little white lies”. Maybe it’s hiding behind the raw facts. Maybe it’s withholding information. Maybe it’s exaggeration. Maybe it’s “rose colored glasses”. Maybe it’s self-preservation. Maybe it’s getting attention. Maybe it’s lack of confidence or over-confidence. Truthfulness is compromised on a regular basis in most work environments and in most interpersonal relationships.

Agile methods have several powerful benefits. To get those benefits, agile needs to be done right. To do agile right, requires truthfulness.

Why does agile require truthfulness? Because agile methods have fewer checks and balances, fewer gating points, far fewer bureaucratic procedures, than other methods. This lack of safety mechanisms means that it is possible to subvert a team using an agile method more easily than it is to subvert a high-ceremony, high-rigor, high-paperwork type method.

That said, there are


mechanisms in agile that promote visibility. Visibility is different than truthfulness. Visibility is promoted through the frequent demos, through the team status meetings, through the emphasis on having the team all in one room, through the insistence that the results need to speak for themselves (rather than having documentation do the talking), through the tracking of actual velocity, through the use of information radiators, etc. These are powerful tools. But all of them can be subverted.

Here is a worst case scenario.

Someone on the team is frustrated or angry about something. This person, let’s call him Joe, decides he’s going to lash out. He starts by spreading some not-very-nice-nor-accurate gossip that gets the other team members to not trust each other as much. He then makes up some sort of technical risk factor and starts to inflate his estimates and convinces a couple other people to do so as well… just in case. The team’s velocity appears stable, but their actual output has decreased. The team is not yet mature enough in their interactions so these things are not mentioned in the retrospective. Joe gradually finds ways to demoralize everyone on the team. The team starts having more and more problems with code quality which slows it down. The process facilitator, Mary, notices these things. However, Joe was planning ahead. Joe has been talking with Mary to help her see how everyone else on the team is subverting the process, thus deflecting attention away from himself. Mary, also relatively new to her role, isn’t careful about checking facts and steps on some toes. Now she is almost powerless to influence the team to get it back on track… and the final blow comes as Joe starts raising obstacles in the daily status meeting that are “made up” and designed to be difficult if not impossible for Mary to help with thus solidifying her impotence in the minds of the rest of the team. Ug.

Is there any way out of this? Not really. Intervention is possible by an experienced coach, but not guaranteed to succeed. The best thing to do is probably to disband the team get an expert retrospective facilitator in to try and extract some of lessons, and then try again with a new team.

What else could be done? Is there a specific intervention that could be performed given that we don’t know that Joe is behind it all? Could this really happen in an agile environment?

Affiliated Promotions:

Register for a Scrum, Kanban and Agile training sessions for your, your team or your organization -- All Virtual! Satisfaction Guaranteed!

Please share!

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.