Invisible Information

“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!





Team Metrics

“The past cannot be changed, forgotten, edited or erased. It can only be accepted.” – Unknown

Let’s Define some metrics!

I had a conversation with a relatively new scrum master recently who was working to help establish some base level team metrics for their organization. They had made the journey to scrum from the role of a project manager and seemed to really transition the mindset of driving to create an environment of trust and transparency within a team and shunning the ideas of controlling the time/budget/scope and “resources” (word I hate when it comes to talking about people) viewpoint of traditional project management.

So my initial question was “who are these metrics being designed for”? This is something we often do not consider. There is a different need for reporting transparency and one to help teams improve. If oversight is the driving goal then the assistance to the team may become minimized. If the goal is to create metrics that are learning opportunities for the team or generate insight for a conversation then the construction of these may be much different but may provide less insight into what management may be seeking.

All metrics are not created equal …

Except, when it came to metrics it seemed. Most of the metrics they were developing were centered around trailing level metrics (lagging metrics for those who are KPI inclined) for the team. A lot of the focus was on the past as a predictor. So I raised the question; “why are you so concerned with the past” in terms of metrics?  They explained to me that this is how he could help the team improve by knowing where they failed or made bad decisions beforehand. So I asked again “given the dynamic nature of iterative development, how can you ensure that the same cause will generate the same effect”?

We discussed in detail that they were extremely proud of was the tracking of “estimated” versus “actual” hours on tasks. They worked really hard to convince me that learning the difference between the two would help them more accurately estimate the work to be done. I let them go for a while and then I had to call bull%^#$ on this.

In my opinion, the only way an “actual” at a task level will be a predictive metric is if the the same circumstances occur exactly the same way the next time. Estimation is just that. It is not predictive in nature, it is a best guess based on the knowledge known at the time. And before anyone says it, you can make a better estimate by reducing the unknowns but you can never eliminate the unknowns.

If I have a headache,  I had road rage on the drive in,  I had more meetings than normal, I volunteered to help someone, I was tired …  A whole lot of things could impact the differences between my estimation and delivery.  So in my “estimation”, this metric is a “narcotic metric”, it tends to make you feel good but it actually could be very damaging when using it.

And what if we do know this information? The key is to be able to take information learned and make it actionable. How do we do that? Send an email and tell the team to estimate better? Begin to question their estimates? Make them sign off? I cannot see how you “use” this information to help them actionably improve.

Refinement Metrics

One type of metric I always recommended for consideration is one I consider a refinement metric. This type of metric is designed to allow the team to perform self-reflection on a recent event given the context of more knowledge and apply that knowledge to a past decision. Instead of comparing the past to the outcome, it asks “given the things we learned, do we think we made an accurate assessment of the work”? Sounds similar but with a couple of differences. 1) It’s never at a task level. 2) It’s a team level rather than a individual developer level as the goal is that the team learns to become better as a team, not as just an individual member.

So what I suggested is something we would often do as part of a retrospective with a team. We would examine the stories for the sprint just delivered and look at the assigned story points. Then we would have a discussion and asked if given the knowledge today, would we apply the same story points. This typically leads to a discussion of dependencies, issues, etc and the team centers pretty quickly around a “stand/raise/lower”. This does not help them get better in defining the individual number itself but helps them reflect on this type of work and the hidden complexities that can be present to determine questions that they may ask themselves or the product owner to create a better consensus around an item in the future to the potential complexity of the work.

Just in Time Metrics

One metric that I have read about after working as a scrum master that I liked was a daily vote of confidence. If you have ever been in a U.S. hospital and had surgery there is a common tool used by nursing staff to determine the level of pain you are in to report and administer treatment. It is called the “pain assessment tool” often and looks like this:


This allows the patient to quickly indicate the level of pain that they are perceiving and reflect this to the nurse, doctor, etc. The blog post I had read (which I wish I could recall the link) suggested using a similar scale for each team member to allow them to forecast their confidence level to meet the current sprint commitment. This allows each team member to express their confidence on a similar scale from “Yep, we rock!” to “Hey guys, I am really, really worried where we are right now” so conversations can be had to determine what’s going on for the purposes of communication at the first responsible moment or to allow the team to swarm around and issue, etc. A simplified version of this has been used by teams that involved “Roman voting” (thumb up affirmation, thumb down condemnation) as well. This type of metric gives you perception of the current state of work in a very real form and let’s you make it actionable. This is often easier to use than seeing potential patterns within a sprint burndown (which is another post).

So just as I asked this scrum master, I ask all of you. Do you have metrics? Who are they created for? Are they actionable or are they just data? How do you use them? Are they actually helping you and even more important are they bringing value back to your team(s)? How do you know?

I leave you with a quote about the importance of knowing why you are actually measuring something …

“Remember, what gets measured; gets managed” – Peter Drucker