The Agile Project Manager—The Clarity of Transparency

The Agile Project Manager—The Clarity of Transparency

You are currently viewing The Agile Project Manager—The Clarity of Transparency

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 transparency fence—obfuscation. 

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 no one 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.

…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.

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 folks what you think they want to hear—nor 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 or 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 any and all feedback

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?

Leave a Reply