Gather Data
In this article, I’ll try to give some insights into the boundaries of collection and sharing data.
Gather data is the second of the five phases of a typical retrospective as being described by Esther Derby and Diana Larsen in their book Agile Retrospectives. For methods to do this, you could get some insights from retromat.org. Two other boundaries in place in my and many other retrospectives are the Prime directive by Norman L. Kerth as being described in his 2001 book Project Retrospectives: A handbook for team reviews, and the Vegas Rule.
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” — Prime Directive by Norm Kerth, Project Retrospectives: A Handbook for Team Review
“What happens in vegas, stays in vegas.” — Vegas Rule
When a Scrum Master facilitates a retrospective, “Gather data” has a promise to it:
“We’ll share relevant data with the whole group. Make it the best you can and want. We can and will help and/or support you within our accountabilities inside the organization. We’ll still ask before taking action and will only make proposals for the next steps for you to decide on.”
Should that sound strange, this article might be for you.
Some definitions first: We’re not really aiming at data but information and actions based on the information. Information will be generated in Phase 3 — Generate Insights. The difference between data and information would be, that data is unorganized and without context, but the information is structured, and context-relevant.
Information equals power in all known organizational forms
Wolf Pack: How strong/weak is the enemy, where can I find food…
Mafia: Who killed whom, who slept with whom, who took something which they had no right to, who has the godfather a soft sport for, which policemen are corrupt,…
Military: How strong is the enemy, where are their hidden bases,…
Enterprise (Classic): When is the position to be filled, what are my colleagues earning,…
Enterprise (Value Stream): How to improve, how to generate more ROI (Return on Invest), how to please the customer…
Enterprise (Knowledge Work): Even in a modern sharing culture the employee sharing the information has the final say on when, how, and in what format. This also equals power in my opinion.
You don’t hand over power without wanting “something“ in return. You don’t hand power to someone you don’t trust unless being forced. You don’t ask for power, without showing competence as well as intent to act accordingly on behalf of the sharing party.
Let’s have a look at the information shared in a typical retrospective:
* Team Health information
* Business value delivered
* Metrics like Cycle Time, Lead Time, CFDs, Ability to innovate
* Team Conflicts
* Information on how productive the collaboration within the team and with other teams has been
* Process, Team, Team member improvement proposals
* What worked, what was missing, what would the team desire
* Niko-Niko (Japanese: Smiley Smiley) Metrics — basically how the team members are feeling
I’d say, this is a lot — and in some cases rather private information. Should this data be flawed, gamed, or gossiped about, this could have severe negative consequences — even for careers or employment status. Team members share this to improve at a sustainable pace, as a team and personally.
As Scrum Master — when facilitating retrospectives — I ask for power/data/information (leader) and by that limit the scope of action for the single team member. The team member who shared information can’t act with this previously hidden information completely without coordinating with others after sharing. So the team will decide afterward.
I also make sure, this power is handed back to the team instantly (servant). The team member is limited by handing over data, but the team is empowered. In the next two phases of the retrospective, what needs to happen with this power is also made crystal clear and decided on in collaboration.
What if the team decides only what is only beneficial for the team and not for the organization? This sounds like a lot of effort — could this be standardized? To have all this data of all teams in one place and derive decisions from there with the help of someone smarter or more empowered sounds like a good thing.
Those are frequent questions and fears. Below is my proposal to tackle those problems. To increase alignment between organizational goals, team goals, and individual goals would be my preferred solution.
Just gathering data and aiming at the middle of the three circles with the decisions isn’t enough. I just stated “beneficial” and not how beneficial in the above diagram. Let’s do a drill-down with six examples still placed in the intersection of the three circles in medium alignment (and forget, that there might be some rather high benefits placed outside of the intersection).
Should the team member decide on their own, they’d probably go for the action shown in bar no.2. Should the team decide, it’ll be one of bars 1,2,3 — probably 1.
Should someone outside decide it’ll be no.4 (maybe bar 1), because, in the aggregated data needed here, the Team member benefit is not really shown. Someone omnipotent knowing all (so not a single employee) would go for bar 1 with the highest benefit in total. Regardless of the decision — if you don’t sell it accordingly to the team member or the team, and it’s not 1–3, expect flawed data in the long run.
I hope I’ve conveyed, why gathering team health or employee health data should mostly be done in a safe space or a completely aligned organization. Hence even in an aligned organization information needs to be shared as to where the decision needs to be done or the action needs to be taken. Would you say it’s easier to share the “data” company mission, vision, and purpose accompanied with business metrics to the employees and let them make their decisions, or would you say, it’s easier to let the employees share their “data” state of mind, health, and well-being to the organization frequently and decide for them? Probably the solution is a mix of top-down and bottom-up, based on the category of the data provided.
Do you want to write for Serious Scrum or seriously discuss Scrum?
