Pair-Agile Coaching: Work smarter in pairs

Six months ago, the team of Agile Coaches at my company decided to experiment with working in pairs. Previously, we had been working in pairs as a way to onboard new team members, inspired by how our developers do pair-programming. We discovered that it wasn’t just the new team members that benefited from working in pairs. The learning went both ways, and we felt stronger and better at agile coaching. Our hypothesis was that we would create more value in the organization working in pairs than alone.

My agile coaching partner became Annette, and together Marianne and Annette became Marionette. Hopefully, our agile coaching pair would become more empowered and less of a puppet than our name implied.

Marionette decided on a goal for the next six months:

To create a work environment that we don’t need a vacation from.

For us this means establishing a healthy balance between reflection and work load, reasonable working hours, autonomy and motivating tasks. Our workday should give us more energy than it takes, and be sustainable over time. We believe that no matter what your role in the organization is, you create more value when you have energy and space to reflect and learn and to focus on what really matters. Work smarter, not harder. It’s a win both personally and for the organization.

One precondition for this experiment is that we are in control of our own priorities and the way we work. We are lucky to have a high degree of trust from the organization, and are more or less self-managed.

How we did it

Marionette kicked off the collaboration by establishing new routines for continuous goal settings and learning. Our most important routines were weekly recurring meetings called Monday commitments and Friday wins, after inspiration from Christina Wodtke’s Radical focus. Other tools and methods we used for building a strong pair were the Wheel of anything, feedback and retrospectives.

We will now take a closer look at our meetings and the Wheel of anything.

Monday commitments and Friday wins

We start every week with a Monday commitments meeting, where we decide on our goals for the week. Planning in weekly intervals helps us split larger missions in to manageable chunks and achievable steps. We also use these sessions to plan our schedule and to reserve time for preparations and follow-ups on our deliveries in our calendars. Based on our experience, if we facilitate a workshop, we use three times as much time as the workshop itself on preparations, plus the same duration as the workshop for follow-up tasks. That’s five hours in total for a one-hour workshop. Estimating and timeboxing all of our known tasks might sound rigid, but it allows us to visualize how much flexibility and slack we actually have in our calendars. As agile coaches, we want to leave some space for unforeseen tasks and opportunities as well.

Every Friday, we revisit our goals in a Friday wins meeting, where we also look at what we learned. Together we mark each goal as completed or fail. The goals we fail at reaching are dead and buried, so we don’t have a growing backlog of tasks we drag along. Next Monday, we start with a clean sheet. We trust that if the failed goals are important enough, they will show up again. This leaves us more mental space to focus on the tasks with the highest impact each week. For more inspiration on why and how to kill your own backlog, I highly recommend Oliver Burkeman’s Four Thousand Weeks: Time Management for Mortals.

Photo by Mike B on

Wheel of anything

Another useful tool for Marionette has been the Wheel of anything. This cake diagram allows us to portion out our capacity in an honest and realistic way. It keeps our capacity limit on 100%, since it’s impossible to expand the circle. If you try to fit in a new priority, something else needs to go. Now and then, we take a look at our own personal wheels to see if we need to change the slices or reprioritize our tasks.

Wheel of anything, to map out how we prioritize our capasity.
A snapshot of Marianne’s Wheel of anything.

Benefits of working in pairs

After six months of investing in stronger relationships and structure, we now experience several benefits, both individually and in how Agile Coaching is done in our organization. To fully utilize these benefits, we have decided to continue for another six months, even if the experiment now has formally ended. Then we plan on switching pairs. We believe that the benefits we see outweigh the cost of investment and the potential downsides and risks. Maybe our next post will be about the flip side of par-agile coaching? For now, we would like to share what we proudly have gained.


With weekly sessions for goal settings and learning, it becomes easier to have fewer priorities, stay focused and hold each other accountable. We now do more of the high impact tasks, and say no to the less important ones. We also do less multitasking.

Working closely together also calls for more transparency and honesty regarding our capacity. Visualizations and realistic planning gives us the overview and mental picture we need in order to evaluate if we have the capacity to take on a new task.


One plus one equals more than two. The quality of our work is way better when we challenge and build on each other’s ideas and utilize both of our differences and strengths.


Working closely together with someone who knows what you’re dealing with, both professionally and private, is of great support. We care about each other on a personal level and lift each other up. Having fun is also an important part of learning and thriving in our role. Laughter boost our creativity and makes us more confident to play and take on reasonable risk.


If one of us is absent, or a new opportunity arises, we can split and still deliver on our commitments. We are flexible to grab new opportunities that are in line with our mission.

Did we meet our goal?

Did we meet our goal of creating a work environment that we don’t need a vacation from? Now that Christmas is near, Marionette feel less of a rush to finish our tasks before the holidays. We already are in control and on track with our work, which is more manageable in size and focus. Both of us even plan on clocking in some hours during the holiday, because our work gives us energy. However, we still believe leisure time to be a healthy win also for our day job, since we can seek other hobbies and get new perspectives and inspiration. But our holidays are no longer just a means to recharge and recover before a new sprint at the office. We enter the holidays with energy to spend on our leisure time as well.

What is your experience working in pairs? What role do you have in your organization, and how do you think you could benefit from working in a pair? What preconditions and pitfalls do you see? Feel free to leave your thoughts and feedback in the comments below.

Pair-Agile Coaching: Work smarter in pairs

Lessons Learned From a First Time Design Sprint Facilitator

Last week I co-facilitated a Google Design Sprint for my colleagues, a process for solving big problems and testing new ideas in just one week. We did the Design Sprint version 2.0, which is the 4-day process instead of 5.

The main activities each day of the Design Sprint v2.0

Top 8 key learnings

The problem we were trying to solve was related to risk assessment in the public sector, so I learned a lot about the domain. I also learned a lot about the Design Sprint process.

One of the advantages of facilitating a Design Sprint is that you can get insight into new and exciting problem domains. But keep your focus on facilititating and don’t be tempted to participate.

These learnings are based on only one time as a facilitator (I have previously been a participant). However, I do find it useful to jot down my own key takeaways while they are still fresh from a beginner’s mind. I also think most of these lessons can be valuable when facilitating other processes.

1. Trust the process

If your domain is complicated or complex (as the public sector can be), parts of the sprint (e.g. the map and the story board) can feel hard and frustrating, and you might dubt that you are on the right track. The timeboxed activities and voting activities are designed to help you progress in a meaningful way.

2. Work together alone

Brainstorming doesn’t work. That’s why we let the participants think and be creative alone in silence. We then mix, match and build on each other’s (anonymous) ideas.

3. Block your calendar and turn off your phone

Blocking everyone’s calendar for a week allows for full focus, efficiency and effectiveness. No multitasking, no context switching and no digital devices (exept when building the prototype).

4. Collaborate with a designer

Design thinking, UX and UI competence is crucial, both in a Design Sprint and in product- and service design in general. The designer(s) should participate throughout the entire sprint.

5. Prepare and adjust

Define the challenge and desired deliverables in the beginning and be open for adjustments as new insight is unveiled during the sprint. Chosing the target customer and target event defines the rest of the sprint and is imporatant to get right. If your organization is large or your domain is complicated or complex, do some research, like system mapping, in advance. Try to get an idea on where the root cause or main problems might be. It might also affect who should participate in the sprint.

6. Choose the participants and experts carefully

The end result depends on the group composition. Make sure you have a cross-functional team with a broad mix of skills that represents the different expertices and interests needed to solve the problem. Make sure some of the participants also have ownership and resources to take the result further. You also have to put some effort into who you invite for the Ask the Experts activity on Monday.

7. Facilitating is hard and rewarding

A Design Sprint requires a lot of planning, organizing and preconditions to be met. The facilitator needs to be well prepared and organized around the activities and the schedule, while at the same time keeping energy and mood high throughout the days.

8. Know when design sprint is not the solution

Design Sprint is not the solution to everything.

As with all new and shiny processes, you need to know when a Design Sprint is not the solution.

Walking through the solution sketches.


These are some of the questions I still have:

  • How and when do you detect whether your solution should be bought or build? How do you avoid making a prototype of a product that already exists in the marked and is not part of your core domain?
  • If the sprint team is cross-functional, autonomous and self-organized, do you need the Decider role? (The Decider is the person making the last call on all decisions.)


Other than working together with an experienced Design Sprint facilitator, these were my main sources of information and inspiration when preparing for the sprint:

What is your experience with Design Sprints?

Regardless if you have more or less experience with design sprints, I would love to hear from you in the comments.

Lessons Learned From a First Time Design Sprint Facilitator