I’d like to begin this post by trying to describe some of the anti-patterns or characteristics of non-transparent work behaviors. This list will probably not be complete, but it should give you a sense of the other side of the fence.

• There are several show-stopping defects in your current code base and you are either not tackling them with your best people or hoping their intermittent nature won’t surface inopportunely before general release. So essentially you are throwing a few bodies at the problem and hoping nobody truly notices.

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. 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 reconcile numerous requirement clarity questions with them along the way. You’re having your release demo tomorrow and they now 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 look in and react, in real-time to the good AND the bad of your project state. Willing to literally get in the game with you and adapt 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 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 do is show off all the gory details of a project for the world to see, digest and then constructively and realistically react to. 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 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 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 action. 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. When 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, she asks for more information and recommendations for corrective actions—what do we do?

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 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 obfuscation and into clarity. It’s all about delivering to our goals. If there is a risk, then how can we deliver the most value becomes our mantra. Short-selling quality is not an option. Working like dogs is not an option. Making scope compromises based on early detection and early, mature, and considered reactions to reality is the only option.

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

Stay agile my friends,

Bob.