As I learn and grow my agile experience, I continue to find value and power in the notion of transparency. It’s one of the softer of the agile tenets and one that gets mentioned often, but rarely emphasized as a critical success factor.

So what is transparency? Let me give you an example. In many agile instances teams and structure don’t simply come into being. Usually functional managers or other leaders put some serious thought into the composition of their initial agile teams:

  • What should be the team size?
  • What is the most effective ratio of skills, for example developers to testers?
  • How much experience does the team need? Specific leaders?
  • How many developers of what sort (Front-end, Back-end, Middle-tier) should be on each team?
  • Does the team have the requisite skills to get their work (as defined in the Product Backlog) done?

being a sample of typical considerations that are made.

Usually team composition involves trade-offs. For example, some team members simply don’t want to work on or in some areas. Individual strengths come into play—as do their professional and personal preferences. Some of the trade-offs might even be considered private or confidential.

When you expose this team composition to the organization, explaining your rationale and trade-offs, you’re practicing transparency. Why do it? First, it serves to expose things to the much broader team. It forces you to articulate your rationale and field questions or challenges. You’ll also field suggestions and alternatives—which will encourage you to consider them in your ongoing thinking.

Two key advantages are that decisions are made out in the open—subject to wider-team scrutiny. And that it provides you feedback on alternatives, which usually creates or fosters stronger decisions—in this case on eventual team composition.

But…there’s a danger

Your level of transparency is dependent on the level of maturity of the receiving organization. In a perfect world, you want to be fully, 100% transparent. But what if you live in an organization that to use Jack Nicholson’s words – “Can’t Handle the Truth!”?

Or what if your colleagues in other functional groups don’t reciprocate the same level of transparency that you do? Now you’ve exposed the inner workings of your organization and decision-making processes or the rationale behind things, but others still remain opaque. Worse—they take advantage of your transparency in challenging your decisions or poking holes in your logic or using the information against you in open debate.

But in the same breadth, they haven’t shared to the same level themselves and don’t have the thickness of skin to defend their own decisions. Thus creating a transparency imbalance that is unhealthy and unfair. You might argue that this is ok. That transparency as a rule is the right thing to do.

Unfortunately, I don’t think this is so. I think organizational transparency needs to be balanced, congruent, reciprocal, and based on maturity and open trust. Let’s explore a couple of examples to drive the point home—

Lack of Honoring or Trusting Role Boundaries

An important part of transparency is individuals understanding the fundamentals of their roles and responsibilities. Let me use a Scrum example to make my point.

The Product Owner is the role in Scrum that is responsible for defining a backlog that meets the demands of the customer. A backlog that is ordered in priority—trying to deliver the highest value features first to the customer. So that they get valuable features front-loaded; delivered early and often.

Now the Scrum team itself contributes to the discussion on prioritization, work items, and value. They collaborate heavily with the Product Owner and driving healthy debate about the organization of the backlog. In many cases, their opinions and feedback factors in quite heavily into the backlog.

But at the end of the day, the ultimate responsibility resides with the Product Owner on backlog organization and the team needs to align with them after passionate discussion and debate—fully supporting their decisions. Trusting them to do their job and honoring their role and its inherent responsibilities.

But what if the team continues to second guess the Product Owner—both within the teams’ context and in public? What if when the Product Owner shares their rationale for decision-making, the team uses these transparent insights against the PO to undermine their credibility?  Or they constantly challenge the decisions over and over again—based on the detailed insights they gained by the Product Owners’ transparency?

This sort of behavior will eventually undermine the Product Owners trust in their team. Sure they’ll collaborate with them and share information. But they’ll begin to filter information from them when they view it as volatile or controversial. They will start to add opaqueness to their decision-making rationale. And you know what? I can’t blame them.

I think transparency needs to be earned in both directions. Both the sender and receiver need to be able to trust each other…otherwise filtering will occur. And within agile contexts this can be a very serious impediment.

Lesson #1 – Transparency has equity as its underlying element; that and a fundamental support of team-based trust.

Another Example - Maturity

Let me try another example. I once was the project manager in a traditional team. We were in the endgame of a project, trying to winnow down software changes and bug fixes as we hopefully approached a much needed customer release point.

It came to my attention that a particular component of our application was not stabilizing from a quality perspective. When we asked the development team if they needed any help or what was specifically wrong, they would deflect. They would get defensive and tell us that they had the software under control and that this was only a temporary glitch.

Initially, we simply trusted them. However, several iterations went by and the software didn’t improve. In fact, some of the newer bugs that were surfacing were not only regressions, but they were more severe than their previous instantiation. Clearly things were getting worse.

I asked members of our testing team if they had any additional insights as to what might be going on. I probably should have asked them much earlier. Sure, they replied. We know what’s wrong. It’s Bill and Eddie’s changes that are de-stabilizing the component. And they have been for two months. Bill was one of our more seasoned engineers and Eddie was a college intern who was working with him.

It turned out that Bill was working overtime. Way too much overtime—around 70 hours a week and he was seriously overloaded on the project. This was one of three components assigned to him and Eddie and they were losing ground on being able to support them all.

Unfortunately, instead of asking for help, Bill was defensive about his capacity and the quality of his work. And his boss fell into the trap of supporting him—all at the cost of delays in the project. Once we got through the opaque defensiveness and immaturity, we adjusted the load across the team and brought in some help for Bill and Eddie. Almost immediately quality began to improve in that component and we were in a release position in two weeks.

If we had regret; it was that we hadn’t forced transparency sooner so that we would have understood root cause better and been able to make a much quicker adjustment! You see it wasn’t about Bill or Eddie—it was about the team getting a project out to their customers.

Lesson #2 – Transparency needs a level of maturity and trust; the realization that early exposure is always best.

Wrapping Up

Transparency turns out to be a bedrock of the agile tenets. It serves as the foundation to many of the activities of a good agile team—daily stand-ups, information radiators, sprint & release planning, sprint demos, and retrospectives. Virtually all of your teams’ agile ceremonies need to be transparent. However, in many contexts, transparency must be earned.

There needs to be congruent and fair play across all aspects of your organization—leading to consistent levels of transparency. A baseline for this is trust. Everyone needs to be on a level field as far as trusting each other’s roles and responsibilities and honoring each other’s skill, ability, and efforts.

If there is inequity, I advise that your transparency level be normalized towards the minimal level that everyone is operating at. Otherwise, it will foster incongruent and odd cross-team behaviors that will often continue to reduce your transparency. Inconsistent transparency will also heavily impact your decision-making as you’ll be getting different levels of information from different groups.

There needs to be fair play when it comes to information. No “I told you so’s”. Instead, you need to foster a fair, equal, and level ground for information sharing. One that will allows the core nature of your agile teams’ to flourish as they face their challenges and adjust towards improvement and success.

Agile Project Managers—are you up to the challenge? I can’t see your answer…

Stay agile my friends,

Bob.