Radical Transparency
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.
#Teams #Agile #Metrics #radicaltransparency #transparency #visibility