“Information is not knowledge” – Albert Einstein
One of the things I always found particularly stressful in a standard software delivery model was the visibility and context of information. I found myself time and again asking for information only to be shown a project schedule or some other document and was admonished with “but there may be some changes not in here” or “this is not the latest version”. And coupled with the fact that I had to know who to ask or where the secret location of the latest and greatest resided, it was even more frustrating.
We have solved some access issues by making all sorts of cloud based access to files and there are tools that recalc everything based on newly provided information that can be stored. But what we have not seemed to solve is the communication and context under which we share that information.
This is why I like the agile approach of BVCs (big visible charts) as a part of product development. The goal is to keep it current and the impetus is on allowing me to pull information as I need and adapt it to my contextual goal. Sounds like a reasonable approach. But, as technology is want to do, we want to be smarter …
As a scrum shop, I started with 4 corkboards (Product Backlog/Sprint Backlog/Doing/Done) and index cards. These sat in an open area that anyone could walk up to and view. So, at a glance, anyone could see what was in the backlog, what we had committed to work on this sprint, what was in flight in terms of tasks and what work had been completed. The burndown chart itself was hand calculated by myself as a scrum master each morning before the team arrived. There was visibility and simplicity in this approach. But it required someone to physically walk over to the team area and view this information. So we decided that it was a good time to make the shift towards a more electronic model so that people could view the information from the comfort of their own desk. So, what was the outcome?
We did create a broader sense of ease to get to the work items for the team itself. Boards were now accessible to team members without leaving the computer in which they were working, product owners could work on stories from anywhere and there was the potential for anyone to still “virtually wander up” and see where things were. It now calculated the burndown for the team so one person did not have to ensure it was up to date each day.
Sounds like a rousing success right? For all of the things it did right, there are some things that it actually made worse in my estimation.
From Information Radiator to Information Refridgerator
One thing that this move from a manual process and chart approach did was slowly to begin to turn information into something that was always visible into something that had visibility when sought. It began to recreate the initial problem that I was so frustrated with in the former system. It created an “information refrigerator”. What I mean is that like a fridge, it became again incumbent to look inside just to get information as to being something that radiated information to be consumed or ignored. It became like opening the fridge door to just see if the light was on. Not very transparent in my estimation.
Whereas personas, visions, backlogs, burndowns were formerly pieces of paper plastered out for anyone to see who came to the team room, product planning items often became non existent due to lack of general visibility or decoupled from the work being done. The idea of feature roadmaps and release charts began to occupy the space of people’s heads and not available to be consumed. Other items began to splinter and I began to see strategic planning items begin creating their own silo locations
What started as a transparent and visible approach slowly wove its way into retention of information with limited visibility and therefore limited learning and focus on that information.
You may think that at this point I am blaming a tool for this problem. If so, you would be incorrect. The tool did not create the problem but without the proper institution of transparency into the culture itself, the removal of the physical manifestations that drove being transparent, the organization opted to use the tool and “assume” that it was being transparent. Because teams and product owners had visibility into these tools (those doing the work) and that it was “available” to anyone else, the idea of transparency was generally assumed by all. But upon closer inspection the cracks were there. Team information was there for the team, product owners were able to work their backlogs through this tool but when it came to the overall transparency to the organization as a whole, it was more shaded as it was not the world that the rest of the organization necessarily worked in. Sure, we could provide the link and they could see stories, burndowns, sprint backlogs and such but did it hold meaning for them? Did we explain what they were seeing? Did we make it as frictionless as possible to gain the information by a pull system as opposed to a push?
So what do we do?
First, stop. Take a moment and consider your current level of transparency. Does the organization know what you are planning, what you are accomplishing and is it as frictionless to them as possible? Are you pushing information to them or have you created an environment in which they can pull information at will. Is the information visible in general? Can anyone in your organization gain insight to ask questions they may have? Do you have a strategy for visibility and transparency into your work? Have you instilled a culture within your organization that makes it acceptable that failure is an opportunity to learn or have you mitigated this by hiding the work?
Start with visibility as a primary goals for your teams. Instill it in the culture and how you work as a whole.
I go back to my original days of the corkboards and asked why this was good. It was because it allowed anyone to wander up, look at what’s going on and derive meaning and formulate questions. It kept the work as transparent as possible given the physical nature of the boards. With tools that can be accessed anywhere, how can we make this even better?
I recently had a conversation with a colleague in the industry that was struggling to gain information about where the teams were in terms of their commitments and the overall features and was met with resistance by a scrum master in providing this and provided insights like “they are on track” or “everything is fine”. As a former scrum master, I know that a primary duty is to protect the team and to allow them to focus but in my estimation, a scrum master who would be immediately resistant to being transparency is actually demonstrating somewhat of a team impediment and not helping the agile culture as a whole. Instead of taking a hard stance, maybe they should have sat down with the director and the people to whom he was having to supply information and unpacked the information they needed. Some might have been reasonable, some maybe not. But until they truly understood the context and the concerns, they really could not assess if this was reasonable. If they had just taken a moment to have these conversations, they may have been able to determine the “why” behind the need and found a way to increase transparency. Just drawing a hard line in the sand created a more contentious relationship between the scrum master and director and may have raise questions of the agile transformation itself. Finally, considering how to make this frictionless to those people seeking information could have helped the organization better understand the team’s work. A little transparency can actually go a long way.
So when met with these types of requests, how can you understand, assess and facilitate the best transparency of the work of the team? I am not saying compromise your work to create mindless or lagging indicators but what do you know today that you can share in a more actively visible and transparent way?
I know that even within my own organization, transparency and recurrent visibility is a struggle. I constantly try and think of ways that can make information more meaningful and more visible. Just taking one more small step to do so may make a huge difference for your organization and my own.
Until next time … Stay agile … and transparent!