If you’re transparent, you must acknowledge and manage quality—being willing to “stop the line” if things aren’t’ right and fix them. This takes courage and commitment.

• Your team is working incessant over-time; making more and more mistakes as they go—daily adding rework and risk to the project on a daily basis. Not everyone on the team seems to think you’ll miss the deadline and nobody in management is willing to “admit defeat”, so all project status reports are still shown as GREEN and the project as “doing fine”.

If you’re transparent, you resist the lack of character & courage to tell the truth about project state for fear of ramification. Instead you routinely tell it “like it is”, and look to make healthy adjustments from “where you are”.

• You began this project three months ago and the business stakeholders were ecstatic when you kicked it off. They even threw a party. But then they “went away” and you haven’t been able to clarify and reconcile numerous requirement questions with them along the way. You’re having your release demo tomorrow and now they all seem to have the time to come and check out the results. The “Great Reveal” is at 3pm and it should prove to be exciting.

If you’re transparent; folks need to be willing & sufficiently engaged to participate and evaluate, in real-time to the good AND the bad of your project state. They need to literally get in the game with you and become involved in moving the project forward— guiding the project towards success.

• You are struggling to deliver the fixed set of features in your latest release. You know which features are at risk, but can’t have the discussion to drop any of the features because the business insists that ALL are 100% required. As a result, you slipped the release date five times and eventually delivered a release with low quality, 14 weeks later than your initial commitment. Oh and did I mention that seven of the most critical features were missing?

If you’re transparent, you acknowledge adversity, look it square in the eye, and make adjustments to your goals. You do so from a position of business value and priority—realizing that everything isn’t equal. You realize that delivering something has great advantage over oscillation.

Now that you have an idea of situations and responses that can be linked to transparency, let’s delve further into more definition.

What is transparency?

From my perspective, it’s the honest and open dialogue about the current state of software development within a project context. There’s no real value in telling you what you want to hear. No providing misleading or hiding information. I have the phrase “It is what it is” running through my brain whenever I think about transparency. What you need to do is show off all the gory details of a project for the world to see, digest and then constructively and realistically react to these details. For example:

• Show your open defect counts and their rate of increase/decrease
• Show your number of sprint escapes or rework that cascades into the next sprint
• Show your project feature-set burndown for the release
• Show your teams’ sprint burndown
• Open the door to your daily stand-up meeting; ask the team not to filter anything as a result of attendee mix
• Open the door to your sprint planning sessions
• Open the door to discussions around what to do about your highest priority feature that is  struggling to see the light of day
• Run a company-wide retrospective for your latest release; taking feedback on all aspects

As an Agile Project Manager, you want to create situations where your progress is simply – transparent in as many situations as you can. There’s the notion of Information Radiators in the agile methods that are intended to serve this purpose. They don’t comment on state as either good vs. bad. They simply radiate it for everyone to see, digest, and react to.

What does transparency create?

Transparency creates congruent conversations which drives congruent actions. Imagine one of your teams having the following burndown chart for an existing sprint and your progress is right in the middle of the “danger zone”, where it’s obvious that “things” aren’t going too well. 

 I’m actually delighted when this happens. And when a stakeholder attends one of our daily stand-up meetings and quietly listens to the discussions. Afterward, they pull me aside at the sprint burndown chart and ask—“We’re not doing so well right now, are we?” And I say “No.” But beyond that, they ask for more information and recommendations for corrective actions—“What do we do now?”

Ah, now that opening leads into all sorts of prime conversational real estate:

• We can and should start looking to jettison content from our sprint goal if possible. No, not the highest priority things, but the lowest. Additionally, can we reframe stories so that we can still hit the goal, with less scope?
• Another point is to get the team engaged in the discussions. In fact, they’re behind in their own commitments for the sprint—so they need to be engaged. What ideas do they have about root cause and corrective adjustments? Can they move work around the team or attack things differently? Do they have any impediments that they want to disclose?
• Does the experience of the team come into play? Is the wrong person attacking this work? And would an assignment change, shifting work around, help us to recover?
• If it’s related to defects, is this an ongoing trend? Is it related to exhaustion or excessive overtime? Does the team lack core, requisite skills? Or domain experience? Or are they simply sloppy in their professionalism?

You see, transparency leads us away from obscurity and into clarity. It’s all about delivering our goals. If there is a risk, our mantra should become - How can we deliver the most value? Short-selling quality should not be an option. Working like dogs is also not an option. Making scope compromises based on early detection and early, mature, and considered reactions to reality is the only option.

Reactions must be made, tightly partnered with your business stakeholders, in a non-confrontational, but truly collaborative fashion. Agile Project Managers must do everything they can to effectively guide their project stakeholders and teams in THAT direction!

Don't forget to leave your comments below.