The Agile Coach's Guide To The Galaxy

Over the summer I will publish several blogposts containing some of my interview questions that I ask people who apply for the Agile coach positions at Spotify. In each post I’ll also go through what I’m looking for with each question i.e. why I ask those specific questions. “Tell me about a time you failed and what you learned.” This question helps me understand a candidates: ability to admit to and learn from failure ability to connect the environment they exist in with their needs, and also their ability to see how this affects their behaviour comfort with failing ability to connect with me around a difficult topic level of (self) awareness Some candidates bring up “comitting untested code” as their failure and…

The Product Owner Framework is a tool for Product Owners that allows them to evaluate their skills and identify areas for growth. Originally created by Daisy Pilbrow and Javier Ubillos, and later developed and expanded by Daisy and myself. The framework is in no way perfect. It’s a work in progress. We created it to help new Product Owners develop their toolbox fast and despite the holes and the eventual inconsistencies here and there we still felt that we wanted to share this with the world. Hopefully it can help others too. Read more about the background here and if you are a PO, take the evaluation here.

In late 2014 Daisy Pilbrow and I sent out a survey to the agile community. The survey asked agile coaches what they wish they’d known before they started coaching, what was challenging about the role, and what they’ve learned about themselves and others. With the replies Daisy and I hoped to create a short and inspiring recommendation that we could give to interns and new coaches at Spotify. The survey received 30 replies. We analysed the responses and were able to identify a few patterns that we’d like to share with you. You can find all the responses in their full format here, but we have removed peoples names to…

(The purpose with this blogpost is to share data about the agile coaches at Spotify.) Slightly more than a year ago the majority of the agile coaches at Spotify took an MBTI test (most of us took it online). Back then all coaches were distributed among 5 different types. I found that really interesting and wondered why that was. Were we biased towards certain type? Or were certain types actually better at coaching agile to teams? Since then we’ve recruited 10 new agile coaches and I’ve been curious about what our current MBTI distribution looks like. Are we still heavy on only a few types? And what about our DISC…

A common question that I receive from the agile community is “What does an agile coach at Spotify actually do?” and about 2 years ago Joakim Sundén answered this question in his blogpost The agile coach role at Spotify. This blogpost is about my current focus and how it has evolved over the past months. While I won’t go into specifics about the challenges we have had and still have, I will illustrate what reality can look like for an agile coach at Spotify. Four months ago I left the IO-tribe (Infrastructure Operations) to join the six month old BITS-tribe (Business Information Technology Systems). I was the first agile coach to join (btw we’re hiring) 🙂 and the…

Are group development courses such as IMGD silver bullets when it comes to helping teams mature? That’s what Martin Wasielewski (also an agile coach at Spotify) and I wanted to find out. In order to find the answer we defined an experiment, and identified a 3 day group development course called S360 encounter that we would send a (willing) development team to. Our hypothesis was that: By increasing people’s self awareness, improving their self esteem, teaching them how to communicate effectively, and raising their understanding of other people’s needs, teams will become high performing. How we would evaluate this experiment Three and six months after our dev team had taken the course we would evaluate the experiment on the following:…

Lately I’ve been exploring tools that can help teams more successfully solve problems. This article is about how you can use experiments to help you solve problems more effectively. Your convictions are more likely assumptions In product development we are finally starting to acknowledge that the convictions we have about our product actually are assumptions (that often also turn out to be wrong). The realisation of this is one of the reasons to why we adopt lean startup or create impact maps. We want to find out if our convictions are wrong early because we want to discover what our users or customers actually want faster i.e. profit faster. That’s…

I am fascinated by how teams make decisions. Some teams I’ve worked with have wanted all decisions to be made by consensus. Others preferred to have a team lead or unofficial leader have the final say in making their decisions. I’ve also worked with teams that resist any and all decisions coming top-down. This often translates to an inverted top-down decision-making process. In a team like this, managers aren’t allowed to make any decisions or tell anyone what to do. One of the responsibilities that you as a leader have is to create an environment in which all individuals can contribute to solving problems and making decisions. To do so,…

That’s what a team that I have been coaching for 1 year and I wanted to answer. We were curious about the answer because I was leaving to coach another team. We thought that the answer to this question would allow the team to improve more effectively. Call it waste reduction in improving if you will. While we weren’t able to identify “one magic ingredient” that made improvements successful we did gain some insights that we think are valuable to others. The format of our retrospective We drew a timeline ranging from July 2013 to October 2014 and we filled it with two different types of data: “Non product related” events, and “Product related” events. Examples of…

At some point in time most development teams run out of potential epics to do next for a variety of reasons. Alternatively they can find themselves at a road crossing uncertain about which Epic to implement next. If you ever find yourself in either of these situations here’s a 2-hour workshop that you can run with your team. The workshop can also help create alignment in the team which can be useful in case your your team is having difficulties agreeing over what to do next. The questions and examples in this article come from when I facilitated this workshop with one of the teams that I coach, the Network…

Some love variation, some love routines. Some love having a lot going on at the same time, others don’t. Some love starting projects, others love finishing projects. Some feel free when there are rules, others feel limited and constrained by rules. If you value routines and work in an environment that changes rapidly it’s likely that you will be exhausted a huge part of your time at work. If you appreciate working on many different projects but can only work on one at a time you could find yourself being demotivated and exhausted. The combination is important, not the style. Which is better? Neither of course! Below are 5 questions that you can ask yourself to discover…

Whether you are new to 1-on-1s or have been running them for a while, at certain times you and your directs will become misaligned and the topics they bring up might come as a surprise to you. The better understanding you have of your directs context, the better prepared you are, or at least can be, for supporting them. Your support can of course come in many different forms e.g. through feedback, by challenging, partnering, mentoring, and coaching, etc., but understanding their context is the first step. With that said, you are aiming for a delicate balance. While knowing everything and never being surprised might mean that you are spending too much…

Stakeholders, users, and customers are three distinct roles. Many workplaces that I have been to have used the words stakeholder, user, and customer as if they had the same meaning. I get confused when someone uses the three words interchangeably because they are very different, and for a reason. The purpose of this article is to share my view of the differences between the three roles. To do this, let’s meet Mark, Lloyd, Roger, and Phil from Healthstudio, a private healthcare company that is well known for its outstanding customer service. Meet Mark, the manager for Healthstudio’s call center. At Healthstudio Mark leads the call center that handles everything from…

User stories and Use cases have the same intention. Many years ago I was at a restaurant in Bombay together with two colleagues, Anup and Rama. We were seated outside and waiting for our food. It was windy and on our table was a stack of napkins that almost blew away. Anup flipped the stack hoping that the napkins would not blow away but as the wind kept on blowing the napkins kept on almost blowing away. Over the next couple of minutes Anup would turn the stack of napkins over from one side to the other several times. Finally Rama took a glass and put it on top of…

A few days ago Martin Wasielewski, an Agile coach at Spotify, and I presented our perspective of how agile we, Spotify, actually are. We interviewed each others on stage at “Agila Sverige 2014” and the questions we answered were “What surprised you when you first joined Spotify?”, “How agile do you think we are?”, and “What is it like in reality having autonomous teams?”. Unfortunately the interview is in Swedish since the conference is an annual swedish conference. If there is interest we will caption the video to English.