Poor Uses for Transparency

In the Agile world we do a lot of things to try and create transparency within our organizations. We put up information radiators like burn down charts, task boards, and cumulative flow diagrams. We put information up on the walls with sticky notes everywhere you turn. We have team synchronization meetings every day. There’s a lot of information flowing around, so is it even possible that transparency can be misused? Is it possible for transparency to go wrong?

In most cases, I think my default answer to this question would be “no” – in general, I’ll take transparency anytime. However I have run across a few situations with transparency that have made me tear my hair out. There are three different cases that I’m thinking of: Frequency of request, Lack of Decisions, and Missing the point: value.

Updating status information on a regular, even frequent, basis can be useful – especially if the work is high priority. However, there is an upper limit beyond which frequent reporting becomes counter productive. It’s one thing to update status once a week, but when it becomes once a day, something has gone wrong. I’m not really sure that there is a discrete boundary beyond which the reporting becomes too much. All I can say is that you know it when you cross it. The problem is, it ends up creating more churn than productive action.

Transparency isn’t all that useful if it doesn’t lead to meaningful action. A lack of decisions is usually an indicator that there is dysfunction that the transparency is not helping to address. In fact, what you are probably finding is that you are only getting superficial transparency. The question is, why aren’t the decisions getting made?

Finally, transparency is only effective if it helps to understand how the organization delivers value. Often times transparency focuses on things that don’t reflect business value. This is missing the point of transparency. It needs to remain focused on the business value.

Building Glass Houses: Creating the Transparent Organization

Visual management occurs at many levels. There is personal transparency: the ability for people to see what you are working on within the team. Then there is team transparency: the ability for stakeholders and other teams to see what the team is working on. Finally, there is organizational transparency: the ability for people within and outside the organization to see what the organization is working on. Ideally, we have all three levels of transparency fully developed in an Agile organization.

Individual transparency consists of the ways in which we communicate the state of our work to the team. We can use both active and passive mechanisms to achieve this. Active mechanisms are things like using one-way broadcast like yammer, or just shouting out when you need help, achieve victory, or otherwise want to share with the team. Then there is two-way broadcast like the status in the daily standup, one-on-one communication, working meetings like the planning and demo. Passive mechanisms include updating things like task boards, wiki pages, and status reports. All of this information is primarily directed at the team.

At the team level there are active and passive mechanisms for communication. There are burn down charts, task boards, calendars, which are all passive. Then there is the active communication that takes place at the scrum of scrums and other larger forums where multiple teams and stakeholders meet. I’ve often seen teams struggle to get information out at this level. They tend to do really well at the individual level, but at the team level it is not uncommon to find that teams aren’t getting enough information out beyond their own boundaries.

Finally at the organizational level there are active and passive mechanisms for communication as well. There are passive communication mechanisms like annual reports, company web pages, intranets, and billboards in the coffee room. There is also active communication at company meetings, and…often not much else. This is an area where as Agilists we need the most improvement. It seems as though the communication demands get more challenging the higher up the organization that you go.

The Values of a New Methodology: Swarming

Perhaps the time has come for a new methodology. The old methodologies are showing their age as they are gradually incorporated and transformed by the large organizations of the world. There are many who feel that scrum today is but a pale shadow of what it used to be. One mediocre “transformation” after another has watered it down to functional irrelevance. Perhaps it’s inevitable that any method that you develop will eventually lose its vitality once it reaches the mainstream. Sooner or later you always sell out to The Man. That’s OK though, there is always a new young buck waiting to take up the mantle of The Next Great Development Process Breakthrough. What if it was Swarming?

If you were going to work on a team that used swarming as it’s only development process, what would it look like? This hypothetical team wouldn’t use any other processes, not scrum, not kanban, and certainly not waterfall – just swarming. It’s a pretty radical idea. Like many of the other methods, maybe we should start with the values. Values are the bedrock upon which we can build our new method. So what values would a swarming team have? Why don’t we start with these:

• Passionate Engagement
• Radical Transparency
• Natural Rhythms
• Simple Rules
• Abundant Alternatives

That seems like a nice set of values, but what does it mean? Why would these be values that a swarming team would hold most essential? Let’s examine them each in turn:

Passionate Engagement – When you look at swarms in nature, from flocks of birds to nests of ants, one thing becomes apparent very quickly: each individual is completely and utterly focused on their task. Bees don’t simply ‘like’ honey. No, honey is much more important than that. To a bee, honey is life and death. Bees don’t ever take a coffee break. Similarly, we want teams that are equally passionate about what they are working on. We want them to believe that it is important, in fact it is absolutely the most important thing that they could be working on. Passion like that is infectious. Other people are attracted to it and soon you will find them working with you side by side just as passionate as you are.

Radical Transparency – Mobilize everyone to look for and manage team threats and opportunities. Share accountability, so that everyone can have the same responsibility for success and failure. All project information should always bet available at a glance on the walls, on dashboards, on my mobile phone, even at home. Access to information needs to be ubiquitous. Anywhere you look it can be found.

Natural Rhythms – A lot of the environments that we work in today don’t honor natural rhythms. Just ask anybody who works swing or night shift. On a swarming team, we want to make sure that we use the cadences of nature where ever possible. Our attention and focus have natural limits, so we can break up the day into smaller chunks. If we are happy and passionate about our work, does it really matter if its a Wednesday or a weekend? The norms of industrial society do not apply to a swarming team. They take their weekend whenever they feel like it.

Simple Rules – Use simple protocols to help enable the highest possible functionality of the team. We need to have simple rules of engagement that enable us to rapidly uncover disagreement and help us to promulgate learning as quickly as possible. Using simple rules requires conscious attention to their maintenance and upkeep. The team needs to keep their rules clear and disciplined in order for them to function well and not decay into disorder. Everyone in the flock needs to have the same signal for turning left.

Abundant Alternatives – Swarms thrive best in complex environments. There need to be an abundance of alternatives to explore, because that’s what swarms are really good at. When swarms find themselves in an environment characterized by scarcity, then they move on to more fertile ground. The same should apply to our teams, if they are working in an ecosystem that is rich with complexity, then they are probably well suited to it. If not, they move on.

These are what I would propose as values for a team using swarming as a development process. These ideas are what support and enable the kind of environment where swarming can happen. The tools are all there, we just need to be bold enough to use them.

 

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.

Getting Attention

I heard a story once from Jeff Sutherland about a team that didn’t have a backlog. Their product owner had checked out for one reason or another and the team was left at loose ends with nothing to do. Rather than tolerating this state of affairs, the scrum master decides to send the whole team home! That’s right, everybody go home until we have some work to do. Go surfing! Have a great time! I’ll call you when the company has work for you to do.

Of course, this was a brazen act that caught the attention of the company executives and they jumped right on the problem and fixed it right away. Nobody went surfing.

At the time, I didn’t fully appreciate what was happening in this little story. There is almost no way that I could see myself telling an entire team to go surfing! The absurdity of the idea was just too much for me to entertain it seriously. Now Sherman, let’s spin the dial forward on the wayback machine to a few years later…

I’m on a project that is going down in flames. It’s bad, really bad. Teams encounter impediments that bring development to a complete stop. We can’t resolve them ourselves, and dutifully escalate the impediments to executives for help. We meet with the executives, explain the problems and the proposed solutions…and get nothing. It’s like reliving the titanic disaster. Somebody shouts “iceberg!” and the executive team continues to drive the ship right into the berg. We’re all going down together and some asshat is playing a violin the whole time.

As a scrum master I screamed, I hollered, I made noise. I did everything I could to draw attention to the problem. However somehow I failed. I went over it time after time trying to work out what I could have done differently. I felt like Robin Hood Daffy, “Ho! Ha ha! Guard! Turn! Parry! Dodge! Spin! Ha! Thrust!” …and then there is that bit where Daffy Duck gets the quarterstaff right in the kisser. Every time.

Recently I was dealing with another project in trouble. The backlog was empty. Again, the team and the scrum master did a terrific job of identifying the problem and escalating the issue to management for help. Again, it was acknowledged and ignored. Yes, thank you very much, now go back to work. However, this time, after the first pass didn’t fly I had an inspiration: I announced that if the team didn’t have a backlog ready for them by Friday, then I’m sending the whole team home.

Now, did I actually have the authority to do that? No. It didn’t really matter – everybody completely freaked out! Why doesn’t the team have a backlog? This is serious! The problem was sorted out in very short order and the team had their backlog.

I’ve decided that there is something about the common ways we communicate in some companies that makes us deaf. If you need help you can’t just tap someone on the shoulder and ask, because you will very likely be ignored. Dramatic actions like threatening to send the team home can serve a useful purpose within a company by getting everyone’s full focus and attention on an issue. Something about that kind of drama punches right through our collective apathy. That’s what happened in this case. It required a little boldness, a little courage, and perhaps a dash of mischief, but it got the job done.