The dangers of transparency

This is the first of a series of articles I am writing about agile transformations.

the entry

I am a Scrum Master and external consultant, thus I get to see different companies in their agile journey.

When I land in a new team, I need information;

• What kind of work or task is this team supposed to do? How are we currently doing it?
• Who is our business stakeholders? How is our relationship with them?
• What is the team health? Is it likely that this team contains the same members in 12 months? Does our skills match the task at hand? Is there factions in the team (fx front end developers / back end developers)?
• How does the team feel about agility? Have they tried it before? How is work currently structured?

All of the above is just a more detailed way of writing 'transparency'. Of course I will have been briefed by whoever hired me, but more often than not the answers to these questions are different from the briefing.

the how

In the past I would go straight into a sprint planning (planning work for the next two week period) meeting with the team, while often stressful to the team, I would learn quite a bit about the team. Just having the technical team estimate the work items at hand, regardless of their quality, is a good introspection exercise for the team, and for me. Who knows what about which work? Who disagrees? Will the product owner meddle? Is the priority clear?

I've experienced having to end meetings after more than four hours with no results, other than me having a good grip on what the next step is.

the preconditions

Full transparency requires a high degree of trust, which I have only experienced few times, in all cases there have been an unofficial leader in the team with a high level of integrity. Most often employees prefer a level of obfuscation, it protects from criticism of performance and method, its hard for anyone to meddle in something they do not understand. In addition it tends to make the individual seem smarter and less expendable.

the bad signs

Severe trust issues can come in many shapes the general message is "don't rock the boat". In practice, during the first planning meeting, it often looks like this:

• insistence on that a piece of work cannot be demo'ed to the business
• work that has no clear output or no desired impact
• people insisting that they do not have time or leave the meeting
• disputes in the team about what the purpose of a piece of work is
• no prepared work exists, so the team has to start from scratch describing work
• refusal in the team of cutting work into smaller pieces. "I have to work on this for two months and it cannot be understood by non-technician before done"
• questioning the value of the meeting
• the scrum master is pushed to make the meeting shorter or change the agenda

the problem

All of the above are symptoms that at least some of the team members are not interested in transparency.

Without a clear intent of the work to be done the team's estimates will be off, and the team will close few work items at the of the two week period.

This becomes apparent if you suggest that all incomplete user stories are moved to the next sprint. Resisting team members will argue to do all kinds of things that will meddle with the metrics. It will be things like:

• closing (unfinished) stories in the old sprint and creating new ones for the next sprint
• splitting stories arguing that a story was worked upon, so some time or story points should be registered in the old sprint
• claiming that a story is complete, but we should reserve time (make a new story) to fix bugs that might come up
• a complete story cannot be released, because it is waiting for a release window (and can't be demo'ed)

the employee cause

Reading books like "pseudo arbejde" (Danish book), "empty work", "empty labor" and "hacking work" will shine light on how many people sit around in large organizations and produce little to nothing, they get away with this because no superiors understands (or cares to understand) their work and missed deadlines have no consequences. Managers also fall into this category and therefore have no interest in rocking the boat. Although it differs how big a problem this is in a given organization, I have never been in a 50+ employee organization that didn't have it to some degree. I can recommend reading the above-mentioned books or googling the term "empty labor" to get a better understanding of this problem. Transparency is an obvious threat to these employees.

There are many dutiful employees too, “zero error culture” and “blame culture” both of which makes it more important to avoid mistakes than to make progress, makes dutiful employees wary of transparency. I think we underrate how vulnerable it requires employees to be fully transparent.

the solution

When I meet a team today, I do not start with the full transparency breakdown unless I feel that the team is ready for it.

Instead I do a lighter version where I have the team do the description of the user stories, and gradually put more focus on the quality of the description, acceptance criteria, story independence and estimation.

In parallel I work on team dynamics (team dynamics will require its own article, but in short), I identify stakeholders that can help build up the courage of the team, set up team rules with the team and focus on retrospectives, to let the team reflect on its own progress.

There will still be bumps on the road to overcome, but instead of having the whole team resisting transparency, it will be a third of it.