I think this post highlights one of the most helpful things about this blog. Rather than defining rigid, black-and-white-only opinions, Mike does a great job adapting Agile principles to specific situations and the real work environment. As someone who is studying this site to learn and improve at my own job, which is neither in software development nor in an Agile environment, that makes these articles really insightful.

Thanks, Haden.

Good reminders, Mike - I had written something similar a year back (https://kbondale.wordpress.... - the key is responsible, disciplined transparency to avoid the dark side of TMI or misinterpreted/misused information.

Great, Kiron. I’m glad we’re aligned.

I have a question about a metric
"The number of hours of work taken on by each team member"
Do we even suppose to keep track of number of hours work by each team members? As in Agile it is all about story points?
Second, in Agile it is all about team efforts?

I want to get clear about should we even bother about hours?

Hi Meena,

There isn't anything in Agile (or Scrum for that matter) that dictates that we use story points to measure size of work. While many teams do use story points and the classic Fibonacci sequence, others might just use the number of items on the backlog to measure work remaining. Other teams will go the other direction and break up stories or similar pieces of work into smaller chunks and may estimate time to accomplish those tasks in days or hours. Some teams have found it useful to gauge any load balancing issues by using those tasks with hours that individual developers have taken on.

Whatever way you look at estimating work (story points, hours, number of items), it truly is up to the team to decide what works best for them in their specific situation. I completely agree that Agile efforts should focus on the team in every case, because that is where the magic really happens.

I like to call it "Strategic Transparency".

Good term, Doctor!

Just a nice acknowledgement in your future blogs and books will do. ;) HaHa.

One important aspect to me is sharing the content of retrospectives. I firmly believe in the Vegas rule and even in open environments I strongly advise the team to go for storing retro results in private spaces/folders. For me this is an important aspect of providing psychological safety. I everybody assumes that whatever is being discussed in a retro is public anyway, critical issues will not be raised in the team.

Agreed

Thanks for not hiding this important idea to us :P

About outside the team like stakeholders, I often try to experiment how much information we should share with stakeholders iteratively. For example, check reactions of stakeholders by increasing/decreasing quantitative/qualitative information.
This approach is good to know the characteristics and preferences of stakeholders for succeeding with continuous conversations.

Great idea to experiment and then adjust based on how that goes. Thanks.

Thanks again Mike for touching upon a "holy" concept in our Agile community with a practical example and framework for thinking :)

🤔I will share my take on what could be better than "share unless there is a good reason not to share".

For example: how long one of the developers worked in a sprint: "16 hours last sprint".

How might we make it safe enough to share even this type of data with the outside world?
How might we educate people in the org. about focusing on the team outcome rather than individual effort?
How might we showcase that concerns like "what if a team member is procrastinating" can be solved in a better way within the team rather than outside intervention?

☝ A good thing about transparency is you can observe how people react. Then you can start a conversation about the questions above. But when you hide, you might miss this valuable conversations leading to a better understanding of a healthy environment for complex product development.

Then teams don't have to waste their time with what to hide and what to make transparent based on each manager's understanding about "how a group of people(!) develop a complex product".

I am currently teaching my MBA students about Quality and Metrics in Software Development, and the subject of transparency came to the fore a couple of weeks ago. My answer was "as with anything in our lives, too much of anything is bad for you". When in doubt, check your values and in case they are apparently in conflict, err on the side of that value that protects the human being -- choose "respect" over "transparency", and always provide a safe environment for your team. Your article has been shared with my class! Thanks.

That’s a great way of explaining it, Renato. And thanks for sharing my article with your class.

Great article Mike, as always! I believe it is context sensitive, each team each organization is different and they evolve.
If the receiver of the data/metric does not have the full context, or skill to interpret correctly, it will be irresponsible to share it. We will spend many moons explaining(defending) the data, instead of focusing on the features!

Good points, Swamy.

Excellent post, Mike, on what I think is a very important topic. Whilst openness is to be valued, if it is misused then it has to be managed. In a truly agile culture, the people outside of the team will appreciate the openness and won't misuse data or information but will come and ask for clarification if things don't look good/right. Unfortunately there are very few organisations where I would have full confidence that this is the case.

That’s a good way of putting it, Rob: If openness is misused we need to manage it. I think it’s one of those things where I trust (most) stakeholders but if they burn a team by misusing or abusing data, I get a little hesitant to be as open until I’ve fixed the underlying problem.

Hi Mike, This post is very timely for me as we are going through extending our transformation to other groups outside of the preliminary stream. I really like the idea that being careful about what is shared is important for building trust as these new groups learn more about Agile. Thank you :)

Thanks. I’m glad it’s timely for you.

I completely agree with the external team part. I also saw these numbers being misused. However, the second point about hiding things with in the team has 2 problem in my opinion. First, which is the obvious one, is that it is a slippery sloop. Once yo justify using this option it could be very easy to abuse it. Second reason I don't agree with the second part is that it immediately starts to pull ranks with in the team, this will cause a huge rift with in the team. Even in your example you mentioned a "Scrum Master" and a "Senior Team member". I believe having to hide anything within the team is an indicator of a bigger problem, which could be solved by better coaching or even more transparency with in the team.

Thanks for this detailed explanation, Mike. And eventually when teams are working, unknowingly they follow this matrix bit somehow become reluctant in doing so as they get confused if they are doing right or not. This article will definitely help.

I’m glad you think this will help. Thanks.

Very good point of discussion. Yes we always talked about transparency but need to be careful about how much to transparent with team and with stakeholders. This always cannot go the way as we think, sometimes management wants to share how much each member's capacity to hold tge work complete, and this can be in hours or points. This is what it is been shared to the stakeholders as well. Which doesn't seem good. When we talk about transparency, we always treat it as team transparency and not individual member transparency.

Good points, Dipali.

I'm not sure that fear over how some metrics may be misused is a sufficient reason to reduce transparency.

Surely, educating others about such metrics and what they represent is preferable to withholding such data?

That’s why none of the quadrants is labeled, “refuse to share.”

We've struggled with this as a custom software as a service shop. We show our clients all the same data we track internally in order to be fully transparent. Sometimes they misinterpret that data and it causes friction. Sometimes they try to use that data against to gain leverage in negotiations. Those are hard situations but they are the exception rather than the rule. We find our company values around integrity and "doing the right thing even if it hurts" compels us to share this information even when it might cause an uncomfortable situation we have to deal with. The trust it brings to our relationships with our clients is worth it.

Now, of course they are internal things that have no business being related to a client, I am speaking to team metrics like cycle time, throughput, bug density, reworks, etc.

Excellent examples on both sides, Tommy. I’ve lived the world you describe as that was our business for a long time. If it got to the point where a client abused the data we’d share, we’d generally opt to not work with that client on subsequent projects.

Exactly! It is a nice luxury to be able to just simply stop working with an organization that does not fit your values and principles.

Sharing metrics based on Story Points can backfire. Managers want numbers to predict when done and they treat SP as a valid metric for productivity, this is likely to lead to game-playing. However sharing metrics based on COSMIC function points is appropriate as they are universal.