Are you, as many others looking, for advice and tips for remote working and meetings?

You’re not alone. At KRY / LIVI, me and Anders Ivarsson, compiled a list of tips and advice on how to make the most of remote collaboration and working from home. We suspect many are looking for similar advice and guidelines, that’s why we’re sharing this with a wider audience. We hope you find some of it useful!

The presentation (14 slides) covers the following topics:

• Working from home
• Maintaining focus
• Teamwork
• The Daily Stand-up
• Being a good video meeting participant
• Being a good video host/facilitator
• Hosting bigger meetings
• Have your tech in order
• Selecting your channel
• Online collaboration tools
• Continue to be social

Click here to download the pdf-presentation.

Click here for Spanish translation (by Carlos Marín Pascual)

Click here for Ukranian translation (by Andrii Shevchenko)

The presentation is creative commons by-nc-sa. This license lets you remix, tweak, and build upon the original work non-commercially, as long as you credit the original work and license your new creations under the identical terms.

Rigid detailed long-term plans, where progress is tracked based on consumed budgets, are in agile organizations quickly becoming a fading nostalgic memory of the past. They are replaced by forecasts and non-static roadmaps. Gather regularly in front of these visualizations and you will enable learning, sharing and trigger important conversations, resolve dependencies and invite to acts of servant leadership. Make your OKRs and Forecasts come alive!

In this blog I want to give examples of visualizations with accompanying recurring ceremonies. The visualization and accompanying ceremony enable sharing of progress and ensure that impediments and dependencies continuously are addressed and mitigated. It also turns the forecast into a conversation (as opposed to a fixed estimate captured in a project plan that is treated as a promise).

The core question the involved teams answer is:

“How confident do you feel that you will accomplish the Key Result before the end of this quarter?”

If you are unfamiliar with the concept of OKRs, Objectives and Key Results, you can think of an Objective as “Let’s double down on this area/problem/need” and Key Results as “Let’s accomplish this specific impact/result/goal/deliverable which will drive us towards our Objective”. For every given quarter the number of Objectives is usually limited to 3-5. Each Objective in turn has 3-5 Key Results. A common guideline is also that on average you are expected to succeed with 70% of your Key Results, i.e. fail with 30%, and that is normal and accepted. This guideline ensures that we set bold goals and avoid playing it safe. Why? Well, if we punish anything less than a 100% success rate, we will eventually optimize for mediocracy.

The OKR Board Stand-up meeting

I was working as an agile coach at Spotify when OKRs were reintroduced 2017. The tribe (think semi-autonomous department) I was working in didn’t want the OKRs to be a static slide in a PowerPoint that is soon forgotten – but a living “plan” we could gather around to figure out how to help each other.

Instead of summarizing the collectively collaborated OKRs of the Tribe in a digital presentation we instead wrote them down on a big whiteboard positioned highly visible in the hallway next to all the teams. Once every second week we had our OKR Board Stand-up. Everyone who wanted to join was welcome, but we requested that at least two representatives from each of the eight teams attended.

The routine of the meeting was simple. We walked the board, one objective at a time. For each objective we read the wording of the Key Result out loud. The teams doing the work, providing to that Key Result, briefly shared progress and announced their confidence level. The meeting lasted 15 to 25 minutes.

Confidence Level

For each Key Result, the teams involved answered the question:

“Do you feel confident that you will accomplish the Key Result before the end of this quarter?”

Below each Key Result there were 6-7 boxes (depending on how many two-week cycles occurred in the quarter), one box for each OKR Board Standup. When we had the third standup, we filled in the third box, and so on. This approach gave us with an historical perspective to our confidence level.

If several teams were providing to the same Key Result they each shared their progress and confidence level. However, the most pessimistic confidence level was the one being noted in the box.

The name of the team (or teams) providing to a Key Result, was written in small text below the boxes.

We actually had a sixth symbol – ?. A question mark meant that “We don’t know yet”. Sometimes that turned out to be the reality, they really didn’t know. But for me that was weird. How can a team allow themselves to “commit” to a Key Result if they aren’t confident that they have a shot at achieving it within the OKR cycle? But it turned out to be useful, so we used it.

Crucial Conversation Triggers

The important thing was however not the confidence smiley update itself – the important event was when the colour of the smiley changed colour from last OKR Board Stand-up.

Those changes were crucial triggers for important conversations. When a green smiley turned into an orange or red smiley, we paused the round to discuss and didn’t proceed until we collectively figured out how to act. Who in the room could help out? Who in the room could connect the team in need with someone that can help? Do we need to alert stakeholders? Who alerts stakeholders? What needs to change for the confidence level to go up? Etc.

Only once at least one strong action had been decided upon (that had the potential to propel us forward), we moved on to the next Key Result.

Even though each team tried their best to mitigate impediments and resolve dependencies daily on their own, the OKR Board Stand-up provided a recurring opportunity to escalate the problem or need to a wider supportive organization of friends and leaders.

Celebrating DONE

When someone announce they were “done” with a Key Result, drawing a check in the box, we obviously celebrated with a thunderous applause.

Opportunity for Servant Leadership

Initially the OKR Board Stand-up was facilitated by one the agile coaches. For the first few stand-ups, none of the three Tribe Leads succeeded to find time to participate. But on the fourth stand-up one of them joined in.

Within a few minutes I believe he realised that this was a golden and precious opportunity to read the pulse of all the teams, to get an aggregated view of the progress and to provide helpful acts of servant leadership. He could provide advice (when asked), suggest paths forward when teams were faced with tough choices, and offer help to connect teams in need with stakeholders and other parts of the organization thanks to his or her wider network.

The next OKR Board Stand-up, all three Tribe Leads joined as observers, ready to provide help and support when asked. And soon they even took turns to facilitate the ceremony itself.

OKR Board Review meeting

Once the quarter had ended, we gathered for an OKR Board Review meeting. We reviewed the Key Results we had accomplished and discussed the ones we hadn’t. What could we learn? What could we take with us to the next OKR Cycle. How could we improve the visualization and OKR Board Stand-up?

% Done Work

The second quarter we run our OKR Board Stand-up we added an aspect to try to make the progress update more complete. For each Key Result, the teams involved didn’t only answer how confident they felt, but they also guesstimated how much work they had completed so far.

Why did we do this? Well, we felt we lacked a part of the story. We learned that sometimes there were teams that felt super confident even though they only guessed they had completed 10% of the work. And sometimes the teams felt very pessimistic even though 90% of the work was done. In some situations, this turned out to be very useful information. The estimate was a cut feeling guess rounded to the nearest tenth.

It went viral

When it was time for the next OKR cycle, the way we did our OKR Board follow-ups had spread internally. To our pleasant surprise, several tribes had copied our approach.

When something spreads and goes internally wired – that’s the best “proof” that the tool/technique/method is useful and valuable.

Possible Variations

If this approach inspires you, but you don’t use OKRs in your team or department, there are many variations to this that still transforms a static forecast into continuous conversation that trigger important dialogs.

Forecast Poker Planning

If we assume that we are working on something that we can’t ship or deliver until a specific set of problems have been solved or features completed, then we can ask the members of the team to individually guess “How many more weeks/sprints do we need to achieve X?” by writing their guess on a post-it.

Remove the most pessimistic and most optimistic vote and write down what remains as a range on the whiteboard. If the estimated range doesn’t decrease with one week every week, that’s your opportunity to talk about possible actions or mitigations.

Deadline Confidence

Sometimes we need to cope with a fixed deadline. Perhaps we have a limited window of opportunity or perhaps we must fulfil a legal requirement by a specific date (for example GDRP). Then we can ask the team “How confident are we that we will accomplish X before date Z?”

This vote could be done with a fist of five. One finger representing super pessimistic and five fingers super optimistic. Three fingers could mean nervous. If the confidence doesn’t increase week over week, we talk about what needs to be done or which options we see before us.

Release Guesstimation

Some teams ship continuously but still have the need to communicate progress and expectations to stakeholders and customers. They have a backlog which they pull from intro their Sprints.

On way to visualize forecasts is to add two lines (for example with adhesive tape) into the Backlog.

Each Sprint Review the members of the team ask themselves two questions:

“How much of the backlog are we super confident to have delivered within the next four sprints?”

“How much more is it possible that we might deliver, within the next four sprints?”

A green line is drawn to visualize how far down the backlog we feel confident we will complete. The red line is drawn to visualize the optimistic scope.

If the team estimates their User Stories with Story Points and keep historic log of ther Velocity, this is of course great input to the team’s guesstimation exercise.

The timeframe “four sprints” can of course be replaced with “next two months” or something else that feels appropriate for the team.

To Conclude

Don’t make your estimates, plans and forecasts into a static digital document, residing deep in cloud folder. Visualize it. Make it accessible. Frequently gather in front of the visualization and share progress, update the forecasts and discuss how you can help out to mitigate obstacles and resolve dependencies. Make it into a living dialog.

It’s no rocket science. It’s a simple healthy habit.

I hereby proclaim that; there are ONLY 10 different ways a decision can be made!

At least in a meeting with several participants.

Sorry for starting with this click baity statement. On the other hand – I haven’t been disproven so far. Regardless of if this is true or not, I believe that the art and skill of decision-making is an increasingly important topic. Why do I believe that?

In many organizations, I often encounter the assumption that a decision is either made by one person, or by a group that has discussed a proposal until everyone agrees. If this is actually true, your ability to conduct effective, efficient and inclusive decision-making is sadly limited. A rapidly increasing number of companies go agile, organizing people into a network of autonomous teams, supported by teams of managers and leaders.

Decision-making and ownership are decentralized to those closest to the problems and opportunities. Leadership is no longer manifested in hierarchies of individual accountability, but in interconnected layers of supportive leadership teams. Just as agile teams collaborate to delivering value to users and customers, so must the leadership collaborate when working, meeting and making decisions. A leadership team’s ability to reach a shared understanding through debates and discussions, explore options and then together decide on the best path forward – is crucial. The speed to decision and time to review and evaluate the impact will dictate your whole organization’s ability to quickly respond, learn, adapt and improve.

With this blog I hope to expand your toolbox and inspire you to experiment with a more varied approach to decision-making.

Book: Decision-Making Principles & Practices

If you and your management team want to become better at having efficient meetings with effective decision-making, you might want to read more about decision-making principles and practices in my new book.

The title of the book is “Toolbox for the agile leadership team – 27 Decision-Making Principles & Practices (How to reach strong inclusive agreements with consent)”.

The digital version is available on LeanPub and you can buy a physical copy on Amazon.

Video (in Swedish)

I recently gave a 10-minute lightning talk on this very subject at Agila Sverige 2019. If you don’t speak Swedish, perhaps skip the video and continue reading my summary of the talk below.

The 10 different ways a decision can be made

I argue that when a decision has been made by a group, it can be derived from one of the following categories:

1) Vote

People or subgroups present different proposals. The participants then Vote. The most popular proposal “wins”. If there is a tie, you can choose to decide with the toss of a coin. This approach ensures that a decision is actually made.

However, the approach comes with some drawbacks. What usually happens is that the advocates for the different proposals dig opinion trenches. They spend energy arguing the benefits of their own proposals and convincing the group of the problems/risks with the other proposals. Instead, that energy could be invested in understanding each other, which might lead to a shared “reality” and a joint path forward. Furthermore, the “losers” might not be committed to the outcome. They might even work against it, undermining its success or impact.

2) Consensus

The group collaborates on a proposal until everyone agrees that this is the best path forward. If successful, this creates a very strong outcome. Everyone feels included in the dialog that shaped the proposal and feel committed to executing on the decision or honouring the new policy. However, this might consume a lot of energy. Arguing, listening, explaining, debating and reaching a shared understanding and collaboratively design a proposal everyone approves – can take a lot of time.

3) Consent

Someone (or a subgroup) presents a proposal. Unless there is a qualified objection, the proposal is accepted and decided upon. If there are objections, these are valued since they are used to collaboratively further improve the proposal.

When deciding through Consensus, you can block a proposal if it doesn’t feel right. When using Consent, this isn’t good enough. For an objection to be qualified you need to be able to explain why it would be bad for the team, project or the company, and be able to present an idea on how to improve the proposal itself.

4) Power

The decision is made by a single person who believes they have a mandate to do so. The authority to decide can be derived from a formal title, seniority or role. The person making the decision might ask for advice or feedback and then base the decision on data and research – but the decision is ultimately done by him/her. Agreeing with oneself is fast, and it’s usually very easy to invent a rationale behind the decision in hindsight.

Delegate – Appoint

One way to delegate to a person or a smaller group, is to appoint them. But for one person to feel that they have the mandate to appoint someone else, that person needs to believe that he or she has enough authority to do so. That’s why I don’t regard appoint as a decision-making technique in itself but categorize it in under Power. The pros of appointing someone is that you ensure someone will do it. The obvious con is that the person might feel forced, thus reducing commitment and ambition to do a good job.

5) Random

Some decisions we actually allow chance to make for us, especially if they are safe and risk free. We might decide who starts presenting by spinning a pen. Choose teams for the charade championship by pulling names from a hat. But sometimes we also use chance for more serious situations, such as when we have a tie when voting and we need to have a “winning” option.

6) Algorithm

Some decisions aren’t made by people but by an agreed upon algorithm. Deciding who is responsible for facilitating the next retrospective could rotated in the team with a list of names guiding the rotation. The backlog could be strictly ordered using cost of delay weighted against work effort (or story points). I even know of companies who have eliminated negotiation from the salary review process. Instead your salary is dictated by a set of input parameters (years at the company, graduation degree, etc) and an algorithm.

Once we have an algorithm, the decision can be made super fast. But how do we define the algorithm? By consensus, consent or voting? Or is it dictated by someone with power?

7) Delegate – Volunteer

Another approach to delegate work and decision power is to ask for volunteers. Whoever raises their hand gets to carry out the responsibility.

As all approaches, this comes this pros and cons. Let’s start with pros. The volunteer is probably passionate about the task and will make sure to do a great job since he/she took it on voluntarily. On the other hand, the person might “take one for the team”, not really wanting to carry out the task. If this happens repeatedly, i.e. the same person always volunteers, you might risk having martyrdom behaviors. Another risk is that the volunteer, although he/she has the passion, doesn’t actually have the skills to do the task sufficiently. But then again, what is most important? Drive and motivation or skills? Do we value growth over skill optimization?

And then we have another question; what do we do if we have too many volunteers? Or none at all?

8) Delegate – Nominate

A third way of delegating work and decision power is through nomination. First you discuss the expectations on a person taking on the task and the extent of included decision power. Then the group nominates someone they believe would be a great fit for responsibility.

The details of how people are nominated and who is chosen can vary and need to be established before the nomination process starts. One benefit of this approach is that the person elected has the trust and support of the whole group.

One drawback could be that the nominated person feels “forced” to take on something he/she doesn’t want to do. It might not be easy to turn down a nomination (even though it’s indeed allowed) when the whole group tries to convince you that you will do great.

Another risk is that the person isn’t “qualified”. But I’m not so concerned about this one. I’ve seen people risen to the occasion when given the opportunity to accept responsibility, especially when encouraged and supported by their peers.

9) Emergent

Sometimes we can’t back trace a policy or rule to a specific decision. Imagine this: Stephanie makes an impulsive decision (without consulting anyone) to do X in the midst of an urgent stressful situation. It works out. Some time later Stefan encounters a similar situation, remembers that someone did something, and does the same. It works out this time as well. Slowly this seeps into the library of “this is how we do things around here”, maybe even sneaking it’s way into the intranet or wiki. No conscious decision was ever made by a group, but still it somehow developed into a rule or policy. When asked why, people have a hard time to retrace the reason or for how long this has been a rule.

There are no pros and cons about this, it’s just the way habits and culture evolve at a workplace. Without this collective behaviour we wouldn’t survive. Each micro decision would take forever. But, of course we should be allowed to scrutinize and criticize these unconsciously emergent decisions, talk about them, and maybe establish new, more thoroughly thought through decisions. “This is the way we do things around here” should never be a valid argument to fence off certain topics from discussions.

10) Status Quo

Actively deciding not to change things, to accept the Status Quo, is a perfectly valid discussion outcome. However, to clarify what Status Quo means often helps the group muster up the energy needed to discuss things through to a point where a decision can be made, thus introducing a change for the better.

Speed and Strength of decisions

As you’ve probably already realised when reading the list above, some ways to decide are fast, while others take a lot of time and energy. Some ways result in strong outcomes (people feel included, committed, that the decision is a win-win, etc.), some in weak outcomes (some people feel excluded, like “losers”, or not committed).

In the graph below I’ve plotted how I believe the different decision-making approaches relate to each other.

Some comments:

Algorithm – Once the algorithm is in place, it’s instantaneous. But it can take a long time to decide on the algorithm, especially if decided with Consensus.

Volunteer/Nominate – If the delegated work and responsibility is given to a group, that group in turn need to figure out how they want to make decisions. This is why these aren’t included in the graph above.

Emergent – Not sure where to put this. Maybe slow and strong…

Summary

Being aware of the different ways decisions can be made will hopefully make you more conscious when deciding upon decision making principles. Giving this set of questions, do we want to optimize for speed or inclusiveness, making any decision over making the right decision, etc. Naively assuming you have to choose between “the boss decides” or “everyone has to agree” severely limits your options.

Some critical situations require fast decisions made by a single person. But when you understand the potential risk and cost you might consider another path for some situations. The energy “saved” from debates might have to be repaid afterwards when you need to defend or justify the decision, sell it to sceptics and create buy-in, monitor and follow up that the decision is honored.

But most often that’s not the situation. The topic is important, but nothing is on fire. By allowing time for debates, discussions, alignment of values, etc, the decision (once it’s made) will be far stronger. People involved will be committed, understand why the decision was made and be motivated to make it work.

Do you agree with the list? Have I missed a decision-making practice? Which is the most common ways to make decisions in your team and company?

In this blog post I want to share a powerful tool, the Leadership Health Check. It will help you become stronger as a management team and reveal improvement opportunities for how you, as a team of active servant leaders, better can enable the agile teams you support.

But first, let’s take it from the beginning.

One of my favourite exercises in my toolbox as an agile coach is something I learned during my years at Spotify; the Squad Health Check. It’s a retrospectives format, a self-evaluation workshop, in which the teams express how they feel they’re doing on wide variety of topics such as collaboration, value of what is delivered, ability to influence, received organizational support, etc. The result generates insights and commitment to actions of improvement for both the team and the supporting leadership. I love it because I believe it’s a great tool for strengthening autonomy, culture and continuous learning.

More than a year ago, a colleague at Spotify Georgiana Laura Levinta and I created a health check for the leadership of our Tribe (Tribe is a semi-autonomous department at Spotify encapsulating 4-8 teams and with a dedicated set of leaders and managers). Geo and I were inspired by the Squad Health Check, but the goal with this adoptation was to help the Tribe’s managers perform a self-evaluation of their ability to provide active supportive leadership to the squads within the tribe, and to generate a discussion on how they can improve as a team to be able to provide even better support.

Since then, I have together with my current client Casumo, adopted this for their context, culture and beliefs. We’ve run it several times with great success and value, both with the company’s leadership team but also on cluster level (semi-autonomous department). I believe the Team Health Check and the Leadership Health Check both are tremendously powerful; hence I want to unleash them to the wider agile community, hoping that more organizations will find them valuable and useful. Or at least be inspired by them, and then try something totally different.

If you don’t want to read about the origin and thinking behind the team and leadership health checks, and only came here to download the workshop material, scroll down to the very end of this blog.

Team Health Check

The origin

The first version of the Squad Health Check at Spotify looked very different from today’s versions. It posed questions like “Do you have a present Product Owner?”, “Do you have the support of an Agile Coach?” and “Is it easy to release?”. As these organizational pain points (for example not all teams having a product owner) gradually diminished, the survey evolved to focus more around autonomy, team work, sustainable process and mission clarity (see example to the right).

The format quickly went viral internally at Spotify, with more and more teams and tribes using it. Today it is an ingrained habit in many parts of the organization. Teams do it two to four times a year. As each tribe adopt it for their context and needs and shares their versions with each, the tool keeps evolving.

The Team Health Check

The Team Health Check I share in this blog post is inspired by Spotify’s Squad Health Check. Through my work with other clients I have evolved it and made it more generic. The current phrasing of topics and statements tries to embed ideas and research presented in books such as Teamwork is an Individual Skill by Christopher Avery, Leading Teams by J. Richard Hackman) Drive by Daniel H. Pink, Team of Teams by Stanley McChrystal, Google’s Aristotle Project, The Five Dysfunctions of a Team by Patrick Lencioni, and many more books and agile thought leaders.

The health check itself consists of roughly 12 topics. For each topic, there is a green and red statement. The green statement describes observable healthy or positive examples. The red, unhealthy or bad examples. Here follow two examples;

Team Autonomy
Green: I feel we influence and shape our plans and destiny. We decide together how we want to work.
Red: Someone else is always calling the shots. It’s unclear to me what we are allowed to decide, and what we’re not.

Feedback
Green: We give positive appraisals, but also provide constructive feedback on each other’s unproductive behaviours.
Red: We rarely praise each other, or give feedback to each other for acting irresponsibly or breaking our Working Agreement.

Adopting the Team Health Check

If you want to run the Team Health Check with teams in your organization, I strongly encourage you to revise and adopt it for your culture and your context and to make conscious decisions of what to keep from the templates you can download below. I believe this is a great leadership exercise. The challenge of defining the topics and statements forces you as leaders to agree on what culture you aspire to build, which behaviours you want to see and what members of a team should be able to expect from the leadership and the org.

Since teams might conduct health checks several times a year it will, in a way, serve as an education of what you strive towards and in some sense become a bill of rights for the teams. If they every time get the question if they feel they’re able to influence and shape their plans and destiny, they are taught that that’s the way it should be. If asked if they have time to think ahead and experiment, it implies that they should be allowed to carve out enough slack to do so. And so on.

The value it provides

In my experience, running a Team Health Check with the teams two to four times per year will…

• Increased awareness of where the team is at, it’s state, challenges and opportunities
• Trigger qualitative discussions within each team with regards to their current state of health.
• Generate improvement actions within the team, as any good retrospective.
• Reveal to the leadership in which ways they need to improve as servant leaders or in which way the can provide additional support to enable the teams
• Communicates expectations of desired behaviours (such as collaboration, feedback, integrity) as well as what teams should be allowed to expect from the leadership of the organization (support, trust, involvement, connection to purpose and why).

It’s not a tool for comparison!

If you as a team fear, or notice, that the results from the self-evaluation is used by management to compare how “good” different teams are – don’t share your results outside the team! Use it like any other retrospective format, as a tool for generating insights, discussions and actions. Share actions, the output, but not the discussions themselves.

If you as a manager is tempted to use the tool to evaluate a team’s “agile maturity”, effectiveness or for comparison between teams – DON’T! The answers will be very subjective, reflecting each team’s very specific context and challenges. If anything, the results from the exercise reveals how good you are at providing support to your teams. It’s not a measure of how they are doing, it’s a measure of how you as a leader is doing.

Leadership Health Check

The purpose of the Leadership Health Check is the same as for the Team Health Check, to self-survey how well we feel we are doing as a team on a wide variety of areas, and reveal how we can improve collaboration and the value we deliver. The team in this case is the group of managers and leaders for a set agile teams. The value we deliver is the support we provide our teams, and the things we do to help the teams deliver value to their users and stakeholders.

The origin of the Leadership Health Check

As I mentioned in the beginning of this article, the first version of the Leadership Health Check was co-developed with Georgiana Laura Levinta  a colleague at Spotify. Georgiana also wrote a Spotify internal blog post about the creation of the tool. Hopefully it will someday be published on Spotify’s official blog.

The version I’m sharing here is the one I’ve been running with my current client, Casumo. It has triggered great discussions about leadership in agile environments. It has gelled teams of leaders and inspired actions and changes to further improve the way they support their teams.

It has proven to work well both for the company’s leadership team (consisting of the CEO, CTO, CFO, etc), and for department level leadership. The workshop has generated insights and guided the leadership team on where focus their efforts next.

It’s designed for the management/leadership team

The Leadership Health Check acknowledges that a team of leaders/managers differs from a team working closely together to ship a product or that offers a service. They might not collaborate towards short-term goals, instead what unites them is the service they offer – providing support, guidance, direction and an environment within which teams can flourish and excel. To do this effectively, they need to treat themselves as a team and align on values and long-term strategies, agree upon how decisions are made and what constitutes good leadership.

Some of the topics are the same as for the Team Health Check, such as Trust & Safety, Dependability, Continuous Improvement and Feedback. Others are specific for the Leadership Health Check, such as Culture & Values, Vision & Direction, Servant Leadership and Transparency.

Adopting the Leadership Health Check

My advice is the same as for the Team Health Check, if you want to run the Leadership Health Check in your department or company, I strongly advice that you adopt it to your culture and your believes on what great leadership looks like.

Agreeing on the set of topics and statements is a great exercise and will most likely trigger plenty of tough but healthy discussions that forces you to align and decide on what is important for you. For example, do you regard youself as a team or a loosely coupled group? Do you believe in inclusive decision-making or clear roles with clear mandate? Your stance on these questions should be reflected in your health check.

Community of Practice Health Check

And here comes a surprise bonus. When working with my current client I was approached by the Front-End Talent. A talent in their organization is a grouping of people with similar disciple or competence, sometimes called a Community of Practice. At Spotify this would be a Chapter. We developed a Health Check with topics tuned for the needs that members of a Community of Practice have on each other. They don’t typically worked towards a common goal the way a team does, but they do share other needs such as knowledge sharing, helping out, aligning on certain long-term strategies and so on.

The topics and statements are unpolished and haven’t gone through many iterations of improvements, if any. But, if you want to you can download it below. Maybe you can use it as a source of inspiration.

Facilitation

I facilitate the Team and Leadership Checks in more or less exactly the same way. I usually plan for a 90-minute session, and facilitate the workshop as follows:

1) Welcome – 5 min

Explanation of the purpose of the workshop and its structure. I emphasize that this is an exercise in self-evaluation, an alternative retrospective format, not a method to measure how good or bad we are as a team from any objective perspective.

2) Self-evaluation – 15 min

For each topic, I ask someone to read the topic and the green statement and red statement out loud. Then each person votes. If you think the green statement best exemplifies how things are, you vote green. If you think the red statement best exemplifies how things are, you vote red. If you’ve seen both green and red examples, or believe things are neither green nor red, you vote yellow. Votes are collected, and then I move on to the next topic and ask the next person to read it out loud, and so on.

Note: When doing this together in one room, I ask people to vote by pulling off a green, yellow or red Post-its. I then collect the Post-its and put them on the whiteboard. When facilitating the workshop with remote members, I prepare a Google Spreadsheet, and then ask the participants to vote in the document. In the screenshot below you can see both the voting of the team members as well as comments captured from the discussion that followed i step 4.

3) Reflection – 5 min

I ask everyone to briefly comment and reflect on the overall result. – 5 min

4) Search for improvement actions – 45 min

Go through and discuss the most interesting results. It could be the topics with majority of votes being red, or topics with the widest range of greens, yellows and red signalling that we perceive the topic very differently. I try to facilitate the discussion so that actions and improvements are suggested and decided upon.

5) Summary – 5 min

Repetition of agreed upon action points, and who will do what.
Ensure that someone is assigned to document and share the result.

6) Check-out – 5 min

A check-out round. I usually ask each person to briefly comment on “Which discussion or action do you believe was the most important one for us as a team?”

Common Questions

Q: For the answers to be thruthful, does this exercise require trust between team members 
Yes. But I also believe doing exercises like this build trust. As team members learn that this is not a tool for evaluating them, but a tool for helping them become a stronger team themselves, the answers will be more honest. As a result, the discussions that follow generate deeper insights and more impactful actions and changes.

Q: Isn’t there value for a department in aggregating the results of several team’s Team Health Check?
Of course. If you as leaders want to see patterns and trends in order to learn where you should focus your efforts, this can be very valuable. The image to the right shows a real example from Spotify. For example, this helped the leaders and teams prioritize work to make it easier to release. Squad 4 had been formed just two weeks earlier, so their self-awareness is probably really low since everything looks green.  Squad 2 seems like they are struggling a lot. So these two squads were given extra support and care.

Q: But I really want to use it to compare how well different squads are performing. Why can’t I?
No you can’t! For several reasons. It’s a self-assessment so the results will reveal of the team percieves itself from their personal perspective. One squad might feel that they are moving at great speed and another very slowly, even though they both release on a weekly cadence. And the context and challenges for each team varies greatly. One team might ship daily updates to a website, another struggling with many external dependencies. One team might be large, another small. And so on.

If you use it for comparison, and maybe even for deciding which team to reward, the teams will figure this out and start to game the results with dishonest answers just to “look good”.

Q: Should the results be shared?
I am a strong believer in transparency, so if you ask me – yes. My advice though is to only share the results and agreed upon actions, not who voted what on each topic. Being transparent and sharing the results builds trusts, enables cross-team learning and fosters a sense of accountability.

Q: I feel some questions are too vague and too open for interpretation. What about dividing it up into more questions with narrower focus?
Sure, you can do that. If the questions don’t trigger good discussions and generate useful insights, please experiment with different questions. But my suggestion is to have no more than twelve to fourteen questions. If you add one, maybe you should remove another.

Q: Should I send out the questions and ask people to vote before the workshop in order to save time?
Maybe if it’s a big group, i.e. larger than 10-ish people. Otherwise I find it more engaging and fun to do it together in the workshop.

Download links

And finally, below you’ll find the download links. Don’t hesitate to copy and adopt them for your context and then run with your teams.

Enjoy!

---

---

---

I suspect that running a session with a team to help them bootstrap a Working Agreement, is the single most common workshop I’ve been facilitating the last couple of years. And I’ve learned a lot of what works for me (and what doesn’t work). In my experience, this approach works equally well for the agile team, the department management group and the steering board team. This blog is me documenting how I ended up facilitating these sessions.

For me, a Working Agreement captures the expectations we have on each other within the team when we collaborate and communicate. I’ve seen teams call it “Code of Conduct” or “Ways of Working”. I call it Working Agreement. You call it whatever makes sense for you.

Running a Working Agreement workshop as early as possible is crucial for setting the team up for success. Preferably it’s done during the team’s two-day kick-off offsite, or at least within the first few weeks as a planned structured workshop.

Preparations

If possible, I try to be a few minutes early into the meeting room to be able to prepare the whiteboard (as in the illustration above), and to make sure there are enough Post-its and Sharpies to go around.

Proposal under discussion is put in the bubble. Agreements are then then moved to the “Working Agreement” area. Parked proposals are moved to “Maybe later…”

Summary

I’ve found that a 90 min session is lengthy enough to create a good first version of a Working Agreement, and not too long for people to lose interest and energy. I usually structure it like this:

• Check-in (5 min) – A check-in round to get people talking and engaged
• Opening (5 min) – Welcome and presentation of why and how
• Write proposals (10 min) – Individual writing of proposal statements for the working agreement on Post-its
• Agreeing on the Working Agreement (60 min) – Presentation of proposed statements, voting and discussion
• Summary (5 min) – Summary of the Working Agreement
• Check-out (5min) – A check-out round to create closure and reinforce the agreement

Check-in

I usually open the workshop with just welcoming everyone to the meeting and then jump straight into a Check-in round. I do this to get everyone a chance to say something as early as possible and to create a relaxed atmosphere.

You can ask any question you want to, and feel is appropriate, but I tend to default to “What is your personal expectations on this upcoming workshop” or “What state of mind were you in as you came into the room and sat down on that chair?”

Once I’ve posed the question, I ask someone to start, and then continue clockwise around the room until everyone has shared. (If someone goes on for too long, I tend to say something like “Thank you for sharing, but could we try to keep the check-in answers shorter moving on?”)

Opening

I then continue to explain that we now will create our first version of our Working Agreement together. It will establish a baseline of what behaviours we want to see, captures our expectations on each other and defines what we should be able to hold one another accountable for. By creating a working agreement, we create an understanding of what is important for us in order to be able to work well together as a team.

I then explain that we soon will get 10 minutes to write down bullets we would like to see in the Working Agreement. These will be proposals that you get a chance to explain and that we will vote on together. I then give them a few pointers and guidelines:

• When writing, think of situations when you communicate, interact and collaborate, both directly face to face such as in planning meetings, daily stand-ups and retrospectives, but also indirectly through tools such as Jira or a chat.
• You may write down things that you think are working well today and you want to clearly anchor in the agreement, or things that you would like to see more of or addresses aspects you don’t feel work that well today.
• On the Post-it, write down an OBSERVABLE POSITIVE BEHAVIOUR you want to see.
  • Good example: We’re on time to meetings. If late, we alert the team in our chat.
  • Bad example: We shouldn’t come late to meetings
• Think of the statement as a proposal for a principle. Some principles are specific (like the example above), others are more general – but still useful.
  • Good example: We celebrate our achievements (Doesn’t specify how and when, but clearly states an ambition)
  • Bad example: We have fun (Too vague. Fun means different things for different people)
• What you write should be self-explanatory and don’t need further explanation. You don’t have to write why you think it should be in the Working Agreement, you will get a chance to explain that verbally. A keyword is probably never enough so try to write a comprehensible but short sentence. Use a sharpie and write nice and readable.
• I as a facilitator might reject proposals in the form of “We treat each other with respect” or “We have fun” since the words respect, and fun can mean vastly different things for different people. Instead try to capture what’s important for you. For example: We give everyone a chance to participate in the dialog. We listen and don’t interrupt.
• Write as many proposals as you want, but please be mindful that we probably only will have time to cover two to three of each person’s proposals today due to time restrictions. The ones we don’t have time to discuss today we’ll save for a future session.

These seem like a lot of things to explain, but I don’t say much more than what’s written above. I’ve learned that being clear on the instructions is crucial for helping the team successfully bootstrapping a Working Agreement and helping the team have valuable, useful and concrete discussions around the proposals.

Write Proposals

Then I shut up for ten minutes to give people time to formulate their proposals for the Working Agreement. If everyone seems to finish early, I ask if they feel happy with what they’ve got and want to continue, or if someone would like a few more minutes. I’ve noticed that some people only manage to write one or two Post-its, while others have a stack of twelve in front of them. That’s totally ok. It’s can be tricky to formulate observable positive behaviours, especially if this is the first time doing it.

Agreeing on the Working Agreement

And then it’s time to go through the proposals and vote on them. I choose a person by random, usually by spinning a pen on the table. I ask that person to start by picking ONE of his/her proposals, stand up, and bring that one proposal and put in inside the thought bubble I’ve drawn on the whiteboard.

Present the proposal

First, I ask the person to read out what the Post-it reads – load and clear. Then I ask him/her to briefly explain why this is important to him/her. And then I turn to the rest of the group asking them if they have any questions of clarification, if there’s something in the proposal they don’t understand. I ask them to not reveal their opinion about the proposal just yet, we will do that through the voting, but to make sure they understand the expectation or behaviour formulated on the Post-it by asking questions.

If no one has any questions I usually inject some of the following questions, giving the person standing up by the whiteboard a chance to answer them one at a time.

• If we vote for this and honour it, can you give me examples of what that would look like? What would I be able to see with my eyes?
• If we fail to honour this, what would that look like?
• If we evaluate our ability to honour this working agreement two months from now, would we be able to evaluate whether we are respecting this bullet? How would we do that?

I ask these questions to ensure that everyone gets a better and deeper understanding of what it would mean to have the bullet as part of the working agreement.

Once I feel the group understands the proposal I continue to the voting. Sometimes no follow up questions are needed at all, the proposal is super clear and obvious.

Voting

I explain that we will vote with our thumbs. “On a count to three, you reveal your vote. Not earlier. We don’t want to prime each other.”

Once I’ve explained the voting, I count down from three “Three, Two, One, Vote”.

No thumbs down

If there are now thumbs down, I proclaim “Great! We have added our first bullet to our Working Agreement. Let’s applaud this decision with a one-clap-applaud!”

Doing a synchronized one-clap-applaud is tricky, but always gives raise to a few laughs and giggles. Groups usually gets better at this after some practice.

I then move the Post-it to the Working Agreement section of the whiteboard. If there are thumbs sideways or closed fist, I now ask them to share why they voted sideways or had their fist closed. I clarify that the bullet has been decided but that it would be valuable if they would share why they voted the way they did. I ask them to keep it short and that this is not the moment to reopen a debate. If you don’t want it in the Working Agreement, you vote thumbs down.

Then I ask the next person to pick one of his/her proposals and approach the whiteboard, repeating the process.

Thumbs down

If there are one or more thumbs down the proposal didn’t go through. I ask the people to share their perspective on why this would be a bad thing for the team to have in the Working Agreement. This usually trigger some great discussions and many times the team reaches a shared understanding, finding a way to reformulate the proposal so that everyone is happy with the formulation. However, if the group fails to decide on a new phrasing within 4-5 minutes, I do a time-out, stopping the discussion. I state something in the lines of “Even though several members in this team want this bullet in the Working Agreement, we also have some friends who don’t want it there. I don’t see us being able to agree upon this one within the next few minutes. I propose that we park this one for a future discussion and continue with the next proposal. The game for today is to find as many bullets that we agree upon as possible in order to have a stable ground to build further discussions on.” And then I move the Post-it to the “Maybe later…” section of the whiteboard.

Repeat

This continues until the timebox is up. I try to close this part of the exercise so that I have 10 minutes left for the last two topics of the agenda. I make sure that the group is aware of the time that is left so that the ending doesn’t come as a surprise. I might even try to estimate how many more proposals we’ll have time to cover when being halfway through the timebox.

Summary

First, I ask the group to applaud their own effort of bootstrapping their first Working Agreement with a proper applaud. Then I read the agreed upon bullets out loud, high and clear. I do this to reinforce the decisions made and to remind the group of what they’ve decided upon.

Before moving on to the Check-out I ask the team how they will capture and document their Working Agreement. Will they move the Post-its to their Team Room? Document in Google Docs? Who will do it?

Check-out

And to wrap up the meeting and the exercise I do a Check-out round, asking the team to take turns answering the question “Which bullet in the Working Agreement do you think will make the biggest difference? Which one is your personal favourite?”

Follow up

A Working Agreement is a living document and deserves continuous attention, love and care. Make it visible in the team area. Make sure to share it to new team members. Bring it to the Retrospective so that you can extend upon it. A retrospective is a great time to bring up proposals that didn’t make it, or that we didn’t have time to cover. You could also dedicate a whole retrospective to discuss and evaluate how good you are at honouring the different bullets. Perhaps some deserve to be rephrased. Some might even feel obsolete and maybe should be removed.

Good luck! Hope you found this lengthy blog inspirational or useful 🙂

I’ve now published a new YouTube video where I present 4+3+2+1 Team Success Factors, a model that captures and describes what you can do to help make your team become strong and successful.

• These 10 factors are split into four groups.
• The first group describes four dialogs we need to have as a team.
• Next we have three aspects of hard work.
• Then there are two dialogs I need to have with myself.
• The final one is about how we communicate with the organisation around us.

To download a printable version click here, or the image below.

And here is the actual video 🙂

I love visualization and I collect visualizations. Why? Well, I love drawing and have a very visual way of thinking. But more importantly, I’ve been amazed time and time again, how great an impact a valuable and useful visualization can have on a team’s ability to focus, collaborate, and adopt new behaviour.

This passion for post-its and whiteboards finally manifested itself in the form of a book; “Toolbox for the Agile Coach: Visualization Examples – How great teams visualize their work”. Not only am I proud and happy of the final result, I’m also very excited about the way it came about. This blog is about how I wrote a book, publicly and collaboratively online, with frequent increments and tight feedback loops.

Warning, this is a pretty long article. Not necessarily because it’s a long story or contains great wisdom, but because I obviously had a lot of things I wanted to share. Continue reading on your own risk.

How I got started

I can’t remember the exact moment when the idea to write a book came about, probably because the idea has been lingering in the back of my head for so long. I however know what the trigger was. My friend and colleague Henrik Kniberg stepped out of our 3 hour flight from our Crisp conference in Iceland. While getting our luggage he enthusiastically shared that he spent that flight writing the whole second version of Scrum & XP from the Trenches. I had been watching a Marvel movie, can’t remember which. I enjoyed the movie, but that was it. No more procrastination!   

That same evening I wrote a first sample page. The structure of the book was obvious for me; each page depicted a visualization example. A big nice picture, and some descriptive text explaining just enough to trigger some ideas or inspiration. I decided very early to focus on concrete examples and to avoid complicating things by getting lost in theory, discussions, storytelling or abstract concepts. I wanted it to be a fun book to read, and a fun book to write.

How I selected a tool

I tried using LeanPub. Deliver early and often, right? However, LeanPub’s format couldn’t match what I wanted in terms of layout and pictures, so I quickly abandoned it and opened MS Word.

During the next few days I wrote some more pages and drew the illustrations. I converted the document to pdf and asked my peers at Crisp for feedback. I got some, but not much.

I tried out some different front page designs and printed it to get a feel for how it could look.

My colleague and friend Hans Brattberg claimed he had a lot of feedback but would not give it to me unless I converted the book to a Google Drive document (or similar) which would make it easier for him to share his comments. I thought – “Which serious writer-wannabe writes a book in Google Drive?” And besides, I was already up to 12 pages.

So I wrote some more pages.

But since I also desperately wanted feedback I eventually decided to copy what I had so far into Google Drive Slides. I shared that document with my colleagues and some more friends, and received great feedback! Providing feedback and suggestions in Google Drive is frictionless. It’s designed for collaboration! I happily abandoned my MS Word document.

Wait a sec! Some of you might say. Why Google Slides and not Google Docs? The simple answer is that I master MS PowerPoint/Google Slides, not MS Word/Google Docs. And the book is highly visual. Lots of colors and illustrations. That’s why! Moving on.

Why I decided to write it online

Then it hit me; I could leverage the online collaborative powers of Google Drive. What if I made the book public while I wrote it, making it possible for anyone who wanted to provide feedback, suggestions and help out with spelling and grammar? I could deliver iteratively and incrementally, getting fast feedback from readers and maybe generate a buzz around the book at the same time.

I rejected my doubts, and ignored the advice some people gave me that you shouldn’t give away the book for free, wait to publish it until it’s finished. Why would anyone pay for a book they’ve already read the alpha or beta version of?

From this point on – for every new page I wrote I tweeted about it (and posted on Facebook and LinkedIn). I invited people to read it and give feedback. I even allowed people to download the book as a pdf for free! If you were unlucky (or lucky) you could even catch me writing new pages.

How I collaborated with others online

This approach was awesome. I got instant feedback. I was truly motivating to experience how people engaged and helped. A small community emerged around the project with people who were excited about every new page and loved to contribute. Some comments spurred great discussions and literally flooded the comment fields.

For several months, at any given time, there were ten or more people reading and reviewing the book. Sometimes as many as forty. Many of the reviewers also provided suggestions on more visualization examples I should add to the book, some of which actually were included.

I can’t thank all of you who engaged enough! I’m really crappy at seeing things through so I’m not sure the book ever would have been completed without your help!

I tried to engage every day in the discussions. Approve or reject suggested changes. Reply to comments. I did my very best to show appreciation and acknowledge everyone’s contributions.

I also felt I wanted to be transparent. The last two pages of the online book contained a change log and a progress page. The progress page stated velocity, a burnup chart and a projection of when the final page would be written. I created an excel sheet where I logged how many examples I had written, and how many more I wanted to write. This fed the burnup graph. Based on my average velocity the last 40 days a forecast date was calculated. 

I also figured out that an easy way for me to visually show the progress of the book was to change the title. The title simply reflected how many examples I had written so far; “9 Visualization Examples”, “17 Visualization Examples”, “25 Visualization Examples” and so on.

If you work as an agile coach – you of course practice what you preach.

Why I choose not to go with a publisher

I have friends who have written books and got them published by highly regarded publishers. This comes with great many benefits, but also with a lot of additional work and loss of creative control.

The reason I choose to self-publish without help from professional editors boiled down to three things.

Reason one. If you go through an established publisher they will provide you a professional editor who won’t give up until every page and every wording is a great as it can be. My book would probably have benefited from that, but I simply did not have the patience for it. Most professional publishers don’t work iteratively with fast feedback loops.

Reason two. I know that some publishers won’t allow you to even choose a photo for your cover. I liked the way the book looked. Maintaining creative control was important to me.

Reason three. I suspect that a publisher wouldn’t allow me to write the book publicly online. I mean, it doesn’t sound like a smart move from a sales perspective to give it away for free while in production right? (Parts of me get that… For example, it’s hard to imagine a movie being made that way. First a 1 second trailer. Then a 10 second trailer. Then 1 minute. 10 minutes. And then it gradually grows into a complete 2 hour movie. Would anyone even be interested to pay for it when it goes up on the big screen?)

The journey up until the release party

I think the book took roughly 6 months to write. I wrote on average three to five pages a week. While writing the book I also travelled a lot. Some of the examples were written in places like these…

Eventually the book was finished in August 2015. I “camped” for three straight days in our sailing boat in the Stockholm archipelago. This is how happy you look when you’ve finished the final page.

I almost aimed for a total of 101 examples, but eventually decided to settle with 96. I converted the pages from Google Drive Docs to MS PowerPoint. Tweaked the layout. Polished the design. Did a couple of additional grammar and spelling feedback rounds with selected people. Converted to pdf. Got it printed.

Wait! What? Are you saying that the final layout and design is done in PowerPoint!?
The answer is yes. Get over it. Moving on.

Converted to pdf. Got it printed. Started selling the book in December 2015, both on Amazon and LeanPub. The first 100-ish physical books were actually shipped from New Zealand since we were living in Auckland at the time.

When we got back to Sweden in May 2016, I finally held a proper release party with friends and colleagues at the Crisp office in Stockholm. The signing queue wasn’t that long but rumor has it that there were some fighting going on in the queue. Win 🙂

What happens next?

The book has since the release been translated to several languages. First out was the Dutch translation. Yves wrote a great article about the way he and his network approached this. Very inspiring! Then came Japanese, Polish and Swedish. More translations are on their way.

When (if?) I write my next book, I will probably do it with the same inclusive collaborative approach (unless I, for some reason, decide to go through an established publisher). I loved it and I got to know a lot of new great people.

I occasionally update this site with news and additional visualization examples. More examples coming soon 🙂

If you are curios about the actual book you can buy it here or here.

If would like for me to come to your company to do an inspirational seminar followed by a team workshop, contact me me and let discuss how we can make that happen.

Thanks for reading this far 🙂 Hoped you enjoyed it!

If you have more questions on anything I failed to cover in this long article, don’t hesitate to post them in the comments below.

Bye for now
/Jimmy

Process is expensive. Bigger teams, working from a distance, part time team members, and many specialists are all factors that lead to a more elaborate process. This might be obvious, but the more companies we get to know, the more we experience that this is something being ignored.

This article is a collaboration between Nomad8 and Crisp. Click here to read the original Swedish version. It was written by Hans Brattberg (Agile Coach at Crisp, Stockholm) and Jimmy Janlén (Nomad8).

When we use some kind of agile process, such as Scrum, Kanban or Lean UX, we highly value collaboration between different people of different competences. A team consisting of complementary skills, that can bring an idea from start to finish, is known as a cross functional team.

A cross functional team is a team that can bring an idea all the way to a release

The simplest possible agile process for members of a cross-functional team might look like this:

• Gather a team of three to five people. Together they have broad experience and knowledge, and all necessary skills.
• Make sure the members work full time (100%) with sole focus on the team’s current project. 100%. Period. No other assignments or commitments to other teams or projects.
• Give the team one big nice room to enable maximum knowledge sharing and learning. Provide plenty of whiteboards for visualization and communication. Flexibility with furniture enables the team to self-reorganize depending on collaborative needs.
• Establish a direct dialog between the team and real users so that the team receives fast and regular feedback. Deliver in small increments.
• Convey clear expectations that they should regularly pause, reflect and together discuss and agree upon how they work better as a team.

A minimal process, where the whole team sits together, undisturbed and 100% focused. When seated together a lot of spontaneous knowledge sharing happens, something that otherwise requires formalized process and meetings.

Working remotely leads to more process

If you sit in the same room, communication happens without effort, naturally, all the time. You can easily raise your voice, or roll your chair over to a colleague to ask a question. You can spontaneously collaborate on a task. Knowledge and shared understanding spread throughout the whole team as through osmosis.

Sometimes, even the thought of getting up from the chair and venturing to another floor, is too big of a mental threshold

If you are sitting far apart, you end up needing to formulate and write an email or chat message, and then pause and wait until you get a response. It could get even worse, some communication might not happen at all since it is simply too cumbersome. Less communication increases the risk for misunderstanding. Sometimes, even the mere thought of getting up and climbing the stairs to another floor, poses too great of a mental hurdle. Your colleague might as well be sitting in another office, or be on another continent for that matter. Same mental threshold. There is no significant difference between seven stairs and seven time zones.

Working from home, or remotely from another continent is practically the same, even though the time and cultural differences increase between countries. It is always worth the effort to find local competence.

Part time work leads to more process

When someone is away, and then returns, that person needs to be brought back up to speed and be informed about what has happened while they were away. Best case scenario, you manage to extract the most important things. Worse case, no synchronization at all.

Part-time workers also make it difficult to find things to work on together, which of course has a negative impact on collaboration. Furthermore, meeting times need to be adjusted to fit their schedule so that everyone can participate. As a result, the person working part time probably experiences a vast increase in the number of meetings, and then he or she gets little work done. The meeting overhead for the part-time worker becomes relatively high. The more part-time workers in the team, the more meetings and less time for value added work.

Specialists lead to more process

The more specialists we have, the more people we need to be. More people means more synchronization meetings.

With only specialists in the team it becomes much harder to attain a balanced distribution of work. All skills or competences are rarely needed equally, and the competency need varies depending on what the team is building. A team with a few people with broad general skills, who can pitch in where required, is necessary to reduce inefficiency.

One strategy to reduce the number of individuals (per team) is to recruit more generalists with a broader skillset, as opposed to more recent graduates with a narrow speciality. For example: maybe a front-end developer with graphical skills. Maybe someone who can code both frontend and backend. Maybe a tester who also can write automated tests. And so on.

More people lead to more process

As soon as we are too many to be able to have ONE conversation, we split into subgroups and the need for synchronization meetings emerges. In our experience, a team seems to breach a magic limit when they grow beyond five members. (For example, imagine a dinner conversation. When does the dialog split up into two or more parallel conversations?)

More people means vastly more conversations

The room we sit in, and the way we have furnished it, also imposes limitations and might force us to split up in ways that undermine communication. Any division over multiple areas makes eavesdropping much harder, and you can no longer simply turn your chair around when you have a question. This introduces the need for more meetings.

The more people in a team, the trickier it is to achieve a configuration that fits within one room, we need to seek other solutions and divide ourselves into multiple rooms.

The more people we are, the more frequently team members will be leaving or arriving. Every change in team composition pushes the team back into storming and forming. New working agreements need to be established. Members need time to get to know each other, and adapt. This costs time and introduces more processes.

Frequently Asked Questions

Question: Is size more important than competence?

No.

If you can’t become cross-functional without being as many as nine people, you need to be a team of nine. But be prepared for more process.

Questions: How do I reduce the size of my team?

Make sure you get more experienced generalists/multi-skilled-people.

The more people with only one speciality, the more people are needed to create a cross-functional team.

The more generalists/multi-skilled-people you have, the fewer people you need overall.

Everything becomes easier.

Question: We are ten people in our team, how do we split?

Make sure that you are cross-functional in your groups as far as possible.

In the case where you only have one tester, assign him or her 100% to one of the teams, rather than 50% in both.

When the other team needs help, provide that through knowledge transfer.

Question: Several of us work part time in other projects, what should we do?

Try to coordinate the time when you are present and the time when you are away.

One way to accomplish this is to book team time in your calendars.

Another way is to agree upon which days you are gone so that everybody is away on the same day.

Question: I work in two or more teams, what should I do?

Try to make one of your teams the primary team. Instead of belonging 50% to both, you spend 60% of the time with one of the teams and 40% with the other. Adopt your primary plans to fit with the team you belong to the most. Instead of committing to tasks on your 40% team, transfer knowledge (help to self-help), in order to reduce their need for your help in the long term.

Question: I do some work remotely, and the synchronization consumes a lot of time?

One approach could be to formally leave the team, and instead provide a service to the team. As such, you don’t need to attend all synchronization meetings, your presence is asked for when the team feels it is needed.

CAUTION: This won’t work if you are a bottleneck.

CAUTION: This won’t work if you need to attend the joint meetings in order to understand the bigger picture.

Specialist outside the team. Only works when the specialist isn’t overloaded with work. If the specialist is a bottleneck, everyone’s priority will be the same as the specialist’s.

Another way to view service providers is to think of them as a fire station. Fire fighters need plenty of slack in their calendar. A fire station is not rewarded by how busy it is, they are measured on how fast they can respond and help people in need. When a fire fighter isn’t busy helping out, they spend time practicing, installing fire alarms, inspecting workplaces, and educating people on fire security.

Question: There are a lot of distributed teams that seem to work well. Is the best thing really five people, all in one room?

The short answer is yes if you have the competence locally. If you can find people with a better skill set located remotely, it could outweigh the cons even though they are spread out across the world. For a longer answer, read more here: http://martinfowler.com/articles/remote-or-co-located.html

Question: We use git and slack and other tools to enable working remotely, so why do we need to sit together?

These tools work excellently when seated together as well, so don’t hesitate to use them even then. A team chat is the perfect place to ask for non-urgent help that doesn’t require you to break someone’s focus. But certain kinds of discussions are difficult to conduct in a chat program. Especially when feelings get involved. The only thing that works then is to meet face to face.

Question: What kind of meetings are needed for teams of different sizes?

A team of five that is co-located might need the following meetings if they work in an agile fashion:

• Weekly planning, 30 minutes
• Bi-weekly retrospective, 60 minutes
• Backlog refinement, when needed
• Daily Stand-up meeting, on demand

If the team is bigger, around 8 people, with someone working part time or remotely, the following is a common setup (differences marked in bold):

• Weekly planning, 60 minutes
• Bi-weekly retrospective, 90 minutes
• Weekly Backlog refinement, 60-120 minutes
• Daily Stand-up meeting, every day with a conference call for the remote worker

Having trouble with curled Post-its that won’t stick to the wall? Well, it could be due to bad glue or that you peel them off wrong. I would guess it’s the latter. Might feel like a silly blog post to write, but I found myself teaching people the technique of peeling Post-its quite frequently.

It’s very simply. Grab the top Post-it with a firm grip, and pull it straight down.
Not to the side. Not up.
Straight down.

With practice comes mastery – someone probably said.

Side note: Some colleagues argue that it is easier to place the left-hand thumb in the middle of the pack (on the second Post-it) instead of on the side of the deck. I guess you need to try to see what works best for you 🙂

I’ve met very few teams that successfully found a valuable and useful way to update and use a Sprint Burndown. The Sprint Burndown can be tedious to update (if done manually), and doesn’t seem to trigger the discussions in the Scrum team it is designed for. Even to agree on a unit causes confusion (hours, tasks, finished User Stories?).

But don’t despair; let me introduce you to Confidence Smileys. Confidence Smileys provide a simple, honest, transparent and overview-friendly tool for the team to visualize how confident a team is that they will be able to finish each User Story by the end of the sprint. The can replace the need for a Sprint Brundown (or Sprint Burnup), or function as a complement.

The idea first presented itself when working with a team at Spotify. It immediately became appreciated and popular, both by the team and by the Product Owner. Since then I’ve pitched the idea to many more teams, both directly and indirectly through friends and colleagues, many are still using it today.

It’s very simple. At the end of every daily meeting the team asks themselves how confident they are that they will be able to finish each User Story by the end of the sprint. The answer is represented by a Confidence Smiley.

The team quickly goes through each lane/User Story and updates the color of the Confidence Smiley. When in disagreement, you could let the most pessimistic vote wins.

When a smiley shifts (from green to orange, or from orange to red) the team grabs the opportunity to discuss what they need to do, how they can help out, and if they need to alert Product Owners and Stakeholders on changes in the forecast.

A few examples of discussions that a change of a Confidence Smiley could trigger:

• What needs to happen for the Nervous (or Sad) smiley to become Confident? Can we make that happen?
• If we removed a User Story from the Sprint would that enable us to focus and finish the remaining?
• Can we slice the User Story and deliver a smaller increment?
• Which stakeholders do we need to alert on the change in the forecast?

Confidence Smileys offer an instant and simple overview of the sprint progress. Not only for the team but for anyone. It’s super easy to start using them and quicker and more informative than a Sprint Burndown.

Let go of the Sprint Burndown. Let it die.

Try something else.

Run an experiment with Confidence Smileys 🙂