A long time reader wrote to me asking what I thought of the idea of letting management have full access to an internal bug tracking system. He said that the idea made him nervous, but that others were pushing for it.

This person works in a traditional, non-Agile environment, one that has historically practiced information hiding.

But I think visibility is important even in non-Agile environments. After all, most attempts to impose control are a reaction to lack of visibility. Think about it: quality gates and heavyweight processes with reporting requirements are usually given labels relating to bringing projects under “control,” but they’re really about visibility. Such practices are a managerial response to the feeling “I don’t know what’s going on!”

Management is responsible for the success of the project, and must make decisions about projects every day. Ship or delay? Staff up or ramp down? Authorize additional resources or make do with what we have? It’s really difficult to make good decisions about a project in the absence of concrete information - like what kinds of bugs remain in the code. So my first reaction was, “Why wouldn’t you give management visibility into bugs? What could you possibly gain by hiding that information?”

But my correspondent (who shall remain anonymous here) pointed out the curses of full visibility:

• The managers don’t understand the details and need a lot of help interpreting it. And even then they still don’t really understand the technical implications of any given decision.
• In this particular culture, these managers tend to use such information to play rounds of pin-the-blame-on-the-techie.
• The managers also tend to use such visibility as an opportunity to override decisions, decisions that they would be perfectly happy with otherwise.

Ah yes. The problem with visibility is that it’s so visible.

Even in Agile teams, visibility can be a double-edged sword. I’ve witnessed some managers behave a little irrationally when the visibility afforded by Agile development made it quite clear that the real problems in the organization lay within the corner offices and not within the programming bullpen. When an organization is built on information hiding, visibility is guaranteed to upset the current power structure.

But I can’t help but notice that last concern my correspondent had about managers overriding decisions, and I think that is the crux of his problem.

Here’s an area where even traditional phased projects can take a page from the Agile book and separate decisions into two categories: business and technical. Agile processes are quite clear about who gets to make what decisions. If it’s a question of what we’re building or how important it is (requirements/enhancements/fixes and priorities), it’s a business decision. If it’s a question of how, or how long it will take to do the work, it’s a technical decision. The business stakeholders (”management” in this case) make the business decisions. The implementation team makes the technical decisions. Neither side attempts to do the other side’s job.

Once everyone agrees on who gets to make what decisions, it becomes safe to reveal any and all information without fear that the information will be misused. And if a manager tries to override a technical decision, perhaps telling the technical team to fix the floobitz bug by renormalizing the object array and subclassing the relational database to a singleton, the technical team gets to say, “Thanks for your input; we’ll take it from here.”

In fact, I think lack of visibility is far more dangerous than an excess of visibility.

Keeping internal stakeholders in the dark about things like bugs creates an imbalance of information. That imbalance that leads to all kinds of odd political games and maneuvers in which information is power. Such political maneuvering creates unhealthy work environments. So while visibility might be scary, the alternatives are worse. Icky things fester in the dark.

If visibility causes pain, the solution isn’t to hide the details. Rather, the solution involves understanding why visibility is causing pain. Chances are it’s because the organization lacks clarity on who gets to decide what. And that’s the real problem that needs to be addressed.