The Veil of Transparency

“In the spirit of transparency,” she said, “be sure to send me an update by the end of the week.”

He glanced at her, casually responding, “Of course. And to be transparent, I’ll present the slides to the team at our next meeting.”

Despite the fact I am not clairvoyant, I am quite certain that the above conversation happened today. Perhaps it even happened in your respective place of work. Just like no company executive today would dare admit “we’re not agile”, the popularity of “being transparent” guarantees we assign transparency to everything we do. And so it goes: as everyone becomes “agile”, transparency becomes yet another buzzword in the great agile sea of expected change in peoples’ behavior.

What is transparency, though? Is it evident in some artifact of what we do? Or is transparency an attribute of a process or method?

I decided to try something (it’s not an experiment without a hypothesis) by asking my Google overlord, “What is transparency in Agile?”

Focusing on the top three results, of about 643,000 total, yielded definitions as follows:

• Sameh Zeid, the lucky recipient of the #1 search result, suggests that “objective implementation of transparency” might be achieved by a set of six actions, mostly by a product owner. Although the first action, “we are primarily discovering, not constructing”, speaks more like a mindset or principle to me. Regardless, a key takeaway here is the suggestion that transparency is implemented through behaviors and actions.

• In result #2, the excellent Bob Galen explores transparency from the angle of an “agile project manager” and offers a variety of scenarios to illustrate transparency as the outcome of activity. Examples include management sharing team composition decisions with the organization and a team member working overtime rather than asking for help. Bob makes a curious statement in one of the examples, lamenting the fact “we hadn’t forced transparency sooner.” Is transparency, then, something we force on people?
  

• Finally, result #3 was an article titled, “Transparency in Scrum” and contributed by David Cordeiro. Oddly, Mr. Cordeiro doesn’t provide a definition or framework for transparency. Instead, the article focuses on practices for Scrum ceremonies as argument for transparency. Given the framework of Scrum activity, the paper appears to suggest that collaboration, communication, and visible artifacts are just part of the transparency umbrella.

In each article, the authors use a heavy dose of Scrum — and the related ceremonies — as a case for transparency. After all, it’s right there in the official Scrum guide under the header of “artifact transparency.” In fact, the concept of transparency is completely centralized around artifacts generated by the Scrum framework. The Agile manifesto values and principles ignore transparency completely. This behavioral thing, such as people hiding their overtime or hiding their mistakes, seems to be completely ignored.

While not clairvoyant, I did witness the conversation at the top of this article at a company decidedly not Agile, let alone trying to mimic Scrum. Therefore, given the only prescriptive documentation for transparency is explicitly framed around Scrum artifacts, why is everything that we do, even in Agile-absent companies, about transparency in the workplace today?

Most often, I’ve observed people discovering they can use one word, transparency, rather than the 400% larger word count of, “I’ll keep you updated.” Who can blame them, after all, “be transparent with me” sounds so much more elegant and friendly than, “send me an update.” Perhaps we should empathize; with the war on managers, using the word transparency on top of status-quo behavior creates an instant illusion of genuinely caring about a human-friendly organization.

Regardless of whether transparency is an Agile buzzword or an abused concept, we can start to derive the logic — and practice — of transparency by first returning to the word’s definition. Rather unnecessarily, we’ve now managed to get business activity added to the dictionary under “transparent”, but let’s focus on a simple definition:

Transparent: Easily detected or seen through. — Merriam-Webster

Imagine two containers, each with lids covering the inside: the first made of clear glass, the second made of wood. Next, our people take the containers to another room and begin filling them with objects (let’s call these objects “our work”). It’s certainly possible that I could ask someone to tell me about the work inside the wood container. At the end of the week, someone might come by and explain the contents, or we could have a recurring meeting, perhaps even some form of document describing the activity of this highly interesting wood container.

All of these activities often occur under the guise of transparency. To be “transparent”, please do something for me. In the spirit of “transparency”, please prepare the information for them. Yet in the case of the glass container, the difference is that I don’t have to ask. No request needs to occur or an investment of someone’s time to inform me of the containers contents. If I want to know what’s inside, I simply need to look! It’s on full display; it can be seen through.

But if I keep the glass container in a room I cannot (easily) access or I never venture forth to look inside, the ease of transparency is lost. It is not easily detected. Creating a product backlog for all to see, or a Kanban board with sticky note tasks, will not create transparency if no one sees it (or understands it). Therefore, is transparency about others’ investment of time, then?

Instead, I offer a definition that ignores practices, artifacts, and behaviors:

Transparency is an environment where people can easily detect the information important to them because they have the safety to be seen through.

This definition brings to light a rather powerful question to explore:
What makes transparency appropriate in our work?

In the example articles provided earlier, each piece of literature focuses on important inputs of transparency: practices, artifacts, and behaviors. Yet, as inputs to the environment, we can only conclude that they might create transparency.

In the case of Mr. Zeid’s paper, one suggested action for a product owner is to perform a Gemba walk and experience the activity of software development. Yet if those observed don’t feel safe to be seen through, are we seeing “the real place”?

Bob Galen’s paper highlighted a team member under enormous pressure and failed to ask for help, resulting in overtime burnout (at the expense of both team and product). Yet what about “forcing transparency sooner” would have helped the situation, such that the person didn’t feel safe to be seen through in the first place?

The next time you hear transparency mentioned as part of activity, or a request, you’ve found yourself confronted by the Veil of Transparency and its attempt to cover up that which is inhibiting the environment. Don’t be coerced.

We do not gain transparency by implementing transparency.

We gain transparency when we have the safety to be transparent.