In the agile and lean communities, we talk a lot about transparency. This image is the transparency principle we used in From Chaos to Distributed Agile Teams.
I see the most product and program success when the various teams create transparency between them, the middle of the continuum. That’s the full-product transparency.
I see many organizations succeed better when the less the manager knows, the better the team works.
And, when there’s too little manager-to-team transparency, the efforts become much more difficult or fail. That’s because the managers don’t explain:
- Why this product
- Why focus on these customers
- Why this product now, as opposed to any of the other work we could do.
The managers don’t explain the purpose.
So, the managers request transparency about the teams’ work. And, the managers don’t offer transparency about the purpose.
That’s not reciprocal transparency.
Teams Need Internal and Cross-Team Transparency
I don’t see how “teams” work with no transparency (all the way on the left in the image ).
Transparency in the team, just left of center, occurs when the team members can see each other’s work and all the work in progress.
Full-product transparency is about the product, not the team. You don’t need a formal program to need full product-based transparency. You might only need two teams collaborating informally to create the product.
Notice that none of the transparency I’ve mentioned includes the “why” for the product or the organization.
When managers start to use the transparency on the right side of the continuum, they not only explain the current organizational state, they create a vision of the future. And, a much more agile organization.
People Solve Problems
What do technical teams do? They solve product problems. (Well, they’re supposed to, unless they’re a feature factory.)
What do agile managers do? They create and refine the organizational culture to free the teams to solve those problems.
That’s why we need organizational transparency to solve problems. We need to understand the context for the product, the customers, and our colleagues across the organization.
We need to know the “why” for the product. We need to understand our organizational constraints—the policies, procedures, and everything else that creates our culture.
And, when those constraints make no sense, the managers need to know so the managers can loosen those constraints.
What Else Do Managers Need to Know?
Managers need to know when the constraints prevent the team from working well. And, the managers need to know when the team has blockers that only the managers can remove.
Otherwise, I’m not sure what else the manager needs to know. Yes, even as remote teams. Maybe especially as remote teams.
If the team delivers something useful every day, the manager doesn’t need to know any metrics inside the team. That includes any interim measures, including cycle time metrics.
Aside from frequent feature delivery, the team creates the product backlog burnup chart and maybe a few other charts. (I wrote a lot about this in Create Your Successful Agile Project.)
The real question is this: What decision will you make with this data?
If the manager decides to punish the team with their metrics, or impose some standard process, the team might buckle under the pressure. Or, some people will leave. (Often, the informal leaders, the people who make the work even better for the rest of the team.)
That’s why managers don’t need a lot of transparency for what the team does.
Managers rarely need to know how the team does it work, as long as the team succeeds. Success means delivering reasonable solutions in a reasonable time frame, and that the team members still respect each other.
Optimize for Management Transparency, not Team Transparency
If you need to optimize for some sort of transparency, optimize for the managers’ transparency, not the teams.
When you make the purpose, and as much of the financials as possible transparent, people see the organization’s direction and any constraints.
Some people don’t know how to read a balance sheet. If they don’t know, educate them. If people don’t agree with the direction, discuss that.
Don’t keep secrets.
Let me exempt two pieces of data from that statement:
- If you’re working through a get-well plan, or an ease-out plan, don’t talk about that. That person expects privacy.
- I’m also not talking about a “quiet” period for public companies. If your employees don’t know about a quiet period, explain how you can’t discuss certain things.
But much of the rest of the policies, procedures, salaries and criteria for promotion? Oh, please, start discussing them.
The more people know, the more they will reinforce the culture those policies and procedures generate.
You might not like that culture—in which case, wouldn’t you rather know earlier than later?
Management Transparency Requires Time to Think
When managers stop micromanaging teams, they can start to think about the strategy and the organizational culture. The strategy informs the project portfolio and other planning. The culture informs a lot of how the teams will achieve that strategy.
Thinking takes time.
When managers stop micromanaging teams, they discover they have more time to think about the business.
And, if you don’t have time to think? Or, if the team can’t deliver something as quickly as you want? That means they have bottlenecks/impediments you might be able to discover and release.
When managers use transparency, they can discuss thorny issues with teams. Those include all the organization’s policies and procedures.
If you want to change any of those policies and procedures, you can create experiments with short feedback loops.
Great management requires transparency from the manager to the teams. Not necessarily the other way around.
Published on Java Code Geeks with permission by Johanna Rothman , partner at our JCG program. See the original article here: Create More Management Transparency Opinions expressed by Java Code Geeks contributors are their own. |
