Radical Transparency

cokin-filter-field-hand-1050

 

 

 

 

 

 

 

 

I’ve always been a big fan of transparency in Agile projects. I love the idea of project stakeholders having an unobstructed view into the work that the team is doing. Of course, what does transparency really mean? To me, transparency means that anyone, whether or not they are a member of the team, can easily see for themselves the current state of the work. That includes all work completed, work in progress, and work remaining to be done. It includes all impediments, risks, and retrospective action items. In short, the customer should be able to see all of the artifacts that the team produces. That’s the idea anyway.

But what happens in practice? Well, if you are intimately acquainted with the team then you will have no trouble reading their stories, understanding their acceptance criteria, and otherwise deciphering whatever agile artifacts just happen to be pinned to the wall.

But what if you have multiple projects taking place at once? Suddenly any given story, of the hundreds of stories in progress, is likely to be completely opaque. Without the context of what the team is working on, coming in as an outsider can be disorienting. Try it out yourself. Walk into a team room of a team you don’t ever work with. March up to their task board and see if you can understand just what the hell they are working on. The odds are pretty darn good that you won’t have a clue.

Actually this makes a lot of sense if you consider that the backlog and the task board are a reflection of the learning that the team has done as they work to deliver a project. Together the team shares a collective set of lessons learned that has been acquired over the duration of the project. You really can’t expect someone to come into a project midway through and understand everything that the team is currently working.

Teams create their own shared understanding of the work they are doing. They often develop a shorthand to describe what they are doing that is difficult for an outsider to initially understand. If we understand team learning this way, then is it really reasonable for a team to have meaningful “transparency” once they have made significant progress on a project?

I think it depends on the information that one is looking for. It’s probably reasonable to expect to see a burn down chart and be able to understand what it tells us, even without knowing anything at all about the work the team is doing. You should be able to at least answer the question, “Are these guys going to deliver everything they are working on in this sprint?” There are a few artifacts that fit this description:

  • Burn down charts
  • Release burn down charts

Yikes! That’s not much to work with! But just about anything else you look at is very likely to be opaque if the project is even reasonably complex. It’s doubtful you will recognize what is in the product backlog (but not unreasonable, because we hope it is expressed in business terms). My experience is that teams start adding their own material to product backlogs fairly quickly. Once they start adding their own stories, they’re starting to share in the learning with the product owner. They are starting to alter their collective knowledge of the problem (aka learning). Some teams will be able to keep the backlog in business terms that everyone can understand, but that actually seems to be pretty rare. Teams tend to switch into their own shorthand fairly quickly.

OK, so maybe the backlog is transparent (maybe not). How about the task board? I can almost guarantee that the task board is going to be a complete mystery to your average project stakeholder who hasn’t been involved in the day to day development of the project. That’s OK, they usually don’t want to know the gory details anyway.

I used to have a notion of radical transparency when it came to development projects. Now I find myself questioning the utility of that notion. Not all the information that is important to the team is necessarily important to the team stakeholders. This seems to be especially true the larger the number of teams that you have working together.

3 Responses to Radical Transparency

  1. lancerkind says:

    Nice problem summary. Management trying to understand what’s going on with projects they aren’t involved with can only follow at a high level. You’re right that there will be a communication gap. I can’t decide if the problem is that these managers must attempt to better understand what’s going on via more individuals and interactions (Agile Manifesto) or need a better information radiator to communicate to those at the project portfolio level. To communicate at the portfolio level, one strategy is using a set of metrics across all teams by which to judge if things are going well.

    Still, I’m uncertain at the wisedom of having managers have such a filtered view and wonder if they can manage?

    • Tom Perry says:

      Lance, exactly! I’m struggling right now to find the right balance in providing that portfolio level detail to execs and it is rapidly driving me insane. Part of it is the mechanism – trying to summarize at too high a level just starts to lose too much meaning. Part of it is the context – a broadly distributed company with hundreds of projects. Part of it is the culture – what is the appropriate level of detail (and perhaps control/comfort) that stakeholders should have?

  2. Great job describing the exact problems that I, as a product owner, have been trying to solve. Businesses needs to understand those things that drive other parts of the business, like launch events, marketing efforts, sales, support, etc., and much of this is informed by the product cycle.

    In our process, we have a continuous improvement cycle, so we’ve been focussed at the feature level — those things that incrementally add value to the product. Our transparency starts at that point and goes down to show what’s completed, in-progress, scheduled, or in the ice-box. Most of the executive team won’t go to this level, but it’s there if need be. The dev lead and I built a dashboard specifically for this purpose.

    The interesting thing (to me at least) is where you touch on impediments, risks, and so on … but I would also include things like scope creep, focus factor based on the changing needs of the business, and changes to velocity. All of these things together begin to provide “proof” as to why we are, where we are, at any point in time.

    Thanks for the great read!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: