Scaledance of Team Healthcheck

To keep the body in good health is a duty,
otherwise we shall not be able to keep our mind strong and clear.
–Buddha

Every self-organized team requires periodic “healthchecks”. With this idea I have started to surf web in search of the best tooling that could help me with the agenda for my team’s Teambuilding retrospective….

 

At the same time team was “storming” and needed help to get into Solution-centric thinking …

My search resulted in making mix of two techniques and I would like to offer ready retrospective script to Scrum Masters. So, “retrospective-cocktail” I am coming up with here “mixes” “Team Barometer” & “Scaledance of an Aspect” techniques serving team to imprive key aspects of Teamwork.

Team Barometer

This is survey-workshop format excerscize adressing 16 team characteristics, packaged as a deck of cards. Download the cards, print them, and cut them out. You want one deck for each participant. Click here to download the cards.

You also need voting cards. Original script reccomends one green, one yellow and one red card but I have used 3,2,1 and 0 planning poker cards (yes, I’ve intentionally modified and introduced the 4th state not to result into “let us take golden middle everywhere”).

Each card has a headline naming a characteristic of a team, and a green and a red statement. Excerscize is to read them out loud one by one, give people a couple of seconds to think and ask them to “poker” this aspect, collecting sum of all votes and NOT discussing estimates like in classical planning poker. Attached you can find list of aspects with an example estimates Team_Healthcheck_Aspects

Scaledance of an Aspect Approach

Idea is as simple as 0-to-10 scale with 10 representing the desired goal and 0 representing its opposite. It provides three focal states for the conversation:

1. NOW: Where we are now? (value=N, current state) – an account of all that is currently contributing to that future, including past successes
2. GOAL: Where we want to be in the end? (value=10) – description of a best possible future
3. STEP: Where we would like to move to? (value = N + 1) – exploration of possible progress in the immediate future

Example:

Powerful questions and methaphors for those 3 states are:

NOW (methaphor: let us look back):

• Where do we stand at this moment?
• What works already so that you are already at N rather than lower?
• And how it is now?
• What is happening now?
• How did we manage to be at N?
• What was our contribution?

GOAL (methaphor: let us look back from the future position):

• What will be different, when we reached 10?
• How will others notice that we reached it?
• Suppose we reachedit, what will we do differently?
• How does the “bright” future looks now?

STEP (methaphor: imagine we are already at N+1):

• On this scale, where do we want to be, for example, in 1 month?
• Imagine we are at N+1 now. What is different?
• And what else our collegues, management, etc. might notice?
• ….

Key here to first talk about states (and not immedeately jump to actions). In Scaledance exscerscize states seen as “goal setting” tool.

Retrospective Script

1. Introduction & Agenda – 5 min
2. Checkin / Warmup – 5 min
3. Healthcheck: aspects estimation – 15 min
   • Write aspects on the board / wiki/confluence page and record sum of estimates
   • Make sure you do not record individual estimates, rather how many 3,2,1 and 0s we have
   • Make sure you do NOT ask “whys?” to the estimates
   • All that counts is the sum of estimates of all team members
4. Healthcheck: prioritisation – 5 min
   • Here you can ask each team member to come up with the “backlog” of their desired top 3-5 aspects they would think team would benefit most discussing
   • Then you can ask team to collaboratevly produce joint backlog of top 3-5 aspects
   • This is important step as lowest estimate of an aspect does not mean this is the most important one, some of them are in realtion to one another and this relation totally unique for each team, so only team members can choose what would they benefit from the best.
     
5. Scaledance of an aspect – 30 min per topic
   • Running Scaledance for desired aspect: Now, Step
   • As aspect – card already represents 0-state and 10-Goal-state you do not have to specify them
   • Ask team to Describe NOW, e.g. by giving them 3 minutes for producing sticky notes
   • Brainstorm together to define how N+1 looks like
   • Derive Actions to make N+1 happen
     
6. Proceed with the next Aspect
7. Closure & Feedback – 5 min

Resources / Techniques / Copyrights / Thanks:

• Crisp’s Blog: Team barometer (self-evaluation tool)
• sinnvollFÜHREN: Leading Solution-Focused Retrospectives

6 Team Building Retrospectives for steel-strong teams

I always wanted to come up with the collection of my favorite” Teaming Up” Retrospectives, those that allow to build up steel-strong teams, increase connection bandwidth between team members and increase motivation on teamwork. So here is it…

Check in before you start…

To start building up a team you need to cultivate Trust among team members. This is foundation you have to establish, otherwise open talk is impossible. One of the best way to check in for Teaming up retrospectives is to offer one of those statements to the team and ask each team member to reflect on Teamwork clearly with the statement like “What is in that for us?” or “How do you understand that?” or “Why you think this is important for us as a team?”

Here are some examples of statements you can use to ask these questions:

1. 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.

2. At the end of an iteration everyone knows so much more. Naturally we will discover decisions and actions we wish we could do over. This is wisdom to be celebrated, not judgement used to embarrass or de-motivate.

3. Team is a partnership of unique people who bring out the very best in each other, and who know that even though they are wonderful as individuals, they are even better together.

• Coming together is a beginning;
• Keeping together is progress;
• Working together is success.

Then I would suggest to move to one of the following exercises …

Exercise 1: My Personal Poster (shorten the distance between us)!

When: with new team / getting to know each other, helping to build up personal connections.

Heads up: may be touchy-feely to some team members (especially shy ones). Make sure people do not feel uncomfortable “revealing” their personal.

Script: We are going to get to know ourselves better! Opening yourself creates relationships!

Please fill in the following template and prepare poster of your life and share it with the colleagues 🙂

• My Name
• 3-4 facts on my personal
• Decisive (crucial) events in my life up to know that influenced who I am most:
• (Could draw timeline of your life with some important data you are willing to share)
• What do I do in my spare time (hobbies, activities)
• What are my personal strengths?
• What are my personal weaknesses (might be tough one)?
• What has been a source of pleasure for me today?
• What kind of secret about myself am I willing to reveal to you?

As soon as poster is ready team members take turn to tell their “Stories” followed by team questions. Aim is to learn as much as possible about team member to understand his/her past and what makes him/her acting in a certain way.

Exercise 2: Cool/Uncool Team member (to share what we want / want to avoid)

When: when you sense team starts having some issues with the “norms” or unspoken “rules” (with the aim to have

this earlier).

Heads up: Make sure it is not turned into personal “blaming” session.

Script: We are going to develop ongoing guide for desired and undesired team behavior .

Please imagine two hypothetical team members (no real persons and names are allowed):

1. Cool guy, team member of my dream 🙂
2. Uncool guy, team member I would not like to work with 😦

Describe what each of those hypothetical characters does, how behaves one treat/behavior pattern per sticky note that are important for you. Mark positive ones with (+) and negative ones with (-). Prepare to share and discuss with colleagues. Perhaps clustering similar topics and prioritizing would help. I did this excerscize for many teams, – some were discrubing their team without names, others – went quite abstract.
If discussion is held too abstract ask team: “Do we have similar issues?”, “Which ones?”

Exercise 3: Team Matrix (to share openly how do we feel and want to change)

When: there is need to share how does each team member feels him/herself in a team and about teamwork.

Heads up: create safe environment! Make sure no accusation happen.

Script: Please prepare your answers for the following questions (one per sticky note):

1. How do I feel myself in the team?
2. How I would like to change it?
3. How I would like that person X changes certain behavior (how do I feel)?
4. If X changes that what do I offer in return?
5. How I am ready to help my team?

RULE: no accusations expressed as wishes!

Write those questions on the whiteboard on the left while put team members names on the top, to form matrix. Offer each team member to fill his column, explaining his position followed up by an open discussion.

Exercise 4: Brilliant moments (to learn from our positive past)

When: when there is need for a team to appreciate their positive past and learn from their great moments.

Heads up: n/a

Script: We are going to examine what moments of the past we would like to repeat and how make them influence our team positively and stronger!

Split team in pairs and ask them to interview each other. Prepare interview template and hand over (see below). Ask interviewer to fill it during Interview. First ask to execute only part 1:

Part 1:

• Your brilliant moment: ask to describe certain situation when something really worked in recent past, that team member considers as achievement.
• Why was this moment so brilliant? What was so special on this brilliant moment for her/him?
• What else?

Then ask pairs to switch roles and redo Part 1 for other team member.

Afterwards ask each of interviewers to write down what they have learned about their pair also filling Part 2:

Part 2:

• Because of what you have just said, it appears to me that you are someone who is / has / can….
• 1.
• 2.

Then again ask to share findings with pair and think together to answer part 3:

Part 3:

• If these strengths would play a larger role in your work life, what would you notice?
• What else?
• What little things could their colleagues might notice?
• Some small actions that she/he might try in the next days?

Then let everyone tell the story of team member they have interviewed to entire group. Then let open discussion, sharing findings and decisions.

Exercise 5: Our Personal Communication Style (to learn how we are communicating)

When: with new team / getting to know each other, helping to learn their similarities / differences in communication style.

Heads up: n/a

Script: We are going to experience how we like to communicate and in what way it is better to approach certain team

member.

Brainwriting exercise: My communication style (underline what is more relevant to you)

1. Do I prefer read or listen?
2. Am I fan of short statements or do I prefer long reports?
3. Do I want long meetings every month or prefer short meetings more often?
4. Do I like to know entire story, every single bit, or do I want to know just the headline (big picture)?
5. Is it sufficient someone says something to me once or do I have to be reminded several times until I notice?

Brainwriting exercise: colleagues communication style (underline what is more relevant to your colleague)

NOTE: split in pairs or consider colleague sitting left/right to you

1. Does my colleague prefer read or listen?
2. Is she/he I fan of short statements or prefers long reports?
3. Does he/she want long meetings every month or prefers short meetings more often?
4. Does she/he like to know entire story, every single bit, or wants to know just the headline (big picture)?
5. Is it sufficient someone says something to me once or do I have to be reminded several times until I notice?
6. Is my colleague totally focused on his work and therefore unapproachable or he is someone who is more team oriented and more pleasant and social?

The exercise is to guess which team member prefers what and learn from those diverse preferences.

Exercise 6: appreciation game (to flourish energy of team members)

When: to help team show appreciation to each other and provide constructive feedback

Script: We are going to thank each other for certain things.

Create half circle of chairs. Place another chair on the other side facing the rest. Ask team for trust and respect, honesty and attention.

To start, ask one person to volunteer to be in the ‘Main Chair’. Other members take turns, to say things they liked about the ‘Main Chair’ person help to the team. Following statement might be used:

• “You really helped team when.. and when..” ( 2 statements) followed by
• “What would be great to have
 more is….”( 1 statement)

See also:

• Teamleads, “Storming”, Self-organization and Entropy
• Team DNA: how to Brand up your team
• TEAM: 7 indispensable ingredients for “Together Everyone Accomplishes More”

Inducting Quality In with Quality Retrospectives

As in Mathematics, so in Natural Philosophy, the Investigation of difficult Things by the Method of Analysis, ought ever to precede the Method of Composition. This Analysis consists in making Experiments and Observations, and in drawing general Conclusions from them by Induction, and admitting of no Objections against the Conclusions, but such as are taken from Experiments, or other certain Truths.
For Hypotheses are not to be regarded in experimental Philosophy.
— Sir Isaac Newton

Quality is by far the most crucial aspect of software development.

I would like to bring  life tested approach of retrospective practice focused on Quality – ceremony to focus on elimination of defects by understanding core issues and addressing required preventive actions, leading to less time spent on fixing those and gaining more time spent building features. Let us call them bugs (negative features that make software functioning not as expected).

As any Retrospective…

it has it’s 5 steps and here is how those are mapped to practical actions:

• Set the stage – focus on reviewing bugs resolved during period (e.g. past iteration);
• Gather data – prepare in advance extract of bugs;
• Generate insights – gathered during retrospective as soon as team passes bugs one by one;
• Decide what to do – preventive action agreed and written, having assignee (es);
• Close – short summary of the reviewed bugs;

What helps to make it efficient:

• Agreement on scope: what bugs are to be reviewed (production, staging, development, what severities, etc…)?
• Right people in: depending on scope and nature you may need to have not only development team members but also release coordinating operations engineers, product managers, etc.;
• In multi-team environment you may need to involve only some team members of every participant team, given who had participated and/or who is best addressing, lead engineers, etc.;
• Prepare in advance (e.g. take iteration, release, etc.. extract of all bug resolved, pre-sorted/pre-groupped by severity, …);
• Have mandatory field when resolving bug with your bug-tracker (e.g. Jira) that must contain technical reason for the bug + projected preventive action to be reviewed further by retrospective. Having this is very valuable as decreases time spent on “gather data” and provides more “space” for “generate insights”;
• Keep it short:  60 minutes is usually enough/sufficient if everything is properly prepared in advance and practice is regular;

Inductive approach (during retrospective):

As team is passing from most to less severe production bugs, they review each and make sure technical reasons are understood and proper preventive action(s) agreed. Then team decides who will own the preventive actions (given team setup this may be teams or individuals). In obvious cases like: bug was not detected by automated and/or unit tests when it should have been, bug is simply stays opened until action is in place (as it is best practice to have those as bug “definition of fixed”).

As soon as bug is discussed team analyses possible patterns for the reasons of the bug by writing down short summary of the bug’s origin.

And moves on with the next bug, etc…

Since approach is inductive: moving from the specific to the general here interesting findings emerge from reality and most “aha-s” and bigger problems become visible.

Here are real-life examples of bugs “patterns”:

• “release misconfigs”
• “old legacy codes”
• “hardware issues”
• “story misunderstandings”
• “quick = dirty fixes”
• “3rd party misconfigs”
• “localization issues”
• etc…

Of course it is good to prevent same bugs popping up again by addressing required preventive action(s) but is not just enough if you want to address the core issue.

The inductive approach here will allow team to focus on systematic problems and start effectively eliminating bugs by coming from particular life-cases, reality (reasons) to more “patternized” reasons and risks of having future bugs of the same nature/origin.

As an example Quality Retrospective may have also outcomes / actions like those:

• 3 compatibility issues / define list of supported browsers (+agree not to support the others, thus do not file bugs;
• 3 old legacy code issues / address with your architect (team), consider reworking;
• 3 misunderstandings / address with your product team how those occurred and refine story writing, grooming to avoid/reduce possible misunderstandings in the future.
• 2 design issues / agree to address design issues incrementally (stop demanding their fixes as bugs, …);
• 2 release miscofigurations / review release notes collection and approval mechanisms, reduce human factor;
• 2 translation issues / address with your product team how those shall be handled;
• etc…

Team may decide to address them from having biggest impact or from more severe issues or more systematic, but at this level they will be fixing the root cause rather than just a symptom (particular bug).

Advice to facilitators: manage time in the way to avoid burning all of it reviewing all bugs (you may not be able and/or it may be not even needed), rather focus on most important ones + detect “patterns” as early as you can.

How to address preventive actions and follow up

As in any retrospective, I’ve seen two approaches working here depending on the efforts:

• in next sprint task approach – action owner plans a task (or time, depending on action nature) in the next sprint. Usually works when effort is quite small;
• “top story” approach – for “bigger actions” plan a story of top priority in the subsequent sprint;

Consequently follow up is done either at the sprint review or on the next retrospective.

Some “Side findings”:

• You will figure out that some bugs are not actually mistakes as from the coding perspective rather than “logical gaps” in user flows;
• Some bugs are unavoidable and you may not need to prevent them (e.g. the risk of having them is acceptable from business perspective or preventive actions are too expensive compared to the consequences, …);
• Some “Invalids”, “Cannot reproduces”, “Duplicates”, “Won’t fix-es” and “Works for me-s” causing development team distraction and eating up time – at some extent this is still unavoidable but keep an eye on if you have increasing numbers of those;
• Some do not fit into any pattern (just exceptions);

Good luck inducting quality in 🙂