Do you want to learn more about The Product Model? Read more about my course on Crisp’s website!

Joakim’s Note:

Spotify is an exceptional company, the best I’ve ever worked for. When I left the company after more than six years, I wanted to help other companies become more like Spotify. However, I didn’t believe companies could merely copy the organizational structures of tribes, chapters, and squads that have come to be known as “the Spotify model”, but I wanted to explain what really set Spotify apart. With this objective in mind the course “Agile at Scale, Inspired by Spotify” was born (in collaboration with Crisp colleague Jimmy Janlén). The central theme of the course revolved around the concept of the Autonomous Squad and described how Spotify and its leaders foster and support this autonomy.

The practices in Marty Cagan’s book, “Inspired”, had significantly influenced Spotify’s operating model. So, when he began discussing Empowered Product Teams, it echoed precisely what we meant with “autonomous squad”. I soon began incorporating that terminology and drew heavily from Marty’s and SVPG’s insightful explanations of the idea. When the book “Empowered” came out, I was astounded by how closely it articulated my experiences at Spotify. And now they’ve given me even better concepts to explain the real Spotify model through the definition of “product operating model” and how that model is different from what most companies are doing.

When Marty visited Stockholm and Crisp to run his new “Transformed” workshop, where he explained the model and its concepts, it became evident to me that Spotify’s model is a product operating model — or more accurately, is a variant of it. Marty proposed that we co-author an article to illustrate this parallel. To fully grasp the insights we’ll be sharing, it’s beneficial to have at least a high-level understanding of the product operating model, as this article will be comparing the Spotify model to the product model. If you’re not familiar with the foundational concepts, I recommend starting with this series of four articles.

Background

By the late 2000s, Spotify had transformed the music industry by winning major record labels over to the idea that streaming is the future. 

By 2014, the service had amassed 60 million active users, and the fight had now shifted to another battleground.  Many new competitors, including Google, Amazon, and Apple were getting ready to enter the fight with their own subscription streaming services. 

Easy access to music through streaming – which Spotify had fought so hard to achieve – was now table-stakes, rather than a differentiator.  Spotify needed to continue to innovate to maintain their market leadership.

The Product Operating Model

When we discuss the product operating model, at the high level we are looking at three major dimensions:

The first is how the company decides the most important problems to solve – the product strategy. The second is how they solve those problems and discover solutions worth building – product discovery. And the third is how they build, test and deliver those solutions to their customers – product delivery.

This article will try to highlight how Spotify embraces and embodies the principles behind each of these three dimensions.

How You Decide Which Problems To Solve – Product Strategy

Spotify’s CEO and co-founder Daniel Ek described the situation as being up against the “end-boss” in a video game.  “We are in the big leagues now, and [some of the world’s biggest companies] are gunning for us…. We believe the most important thing we can do to maximize our potential is to increase our differentiation compared to other services.”

Spotify’s product strategy was shaped by insights on how their audience segmented. Spotify knew that they essentially had two main types of users. Those that knew the music they wanted to listen to, which they referred to as “lean-forward” listeners.  And those that didn’t really know the artists or the albums and they just wanted the service to help them discover music that they would love, which they referred to as “lean-back” listeners.

For a long time Spotify had thought that the service was already pretty good for discovering music. All you needed was a good search bar and a playlisting tool. How hard can it be? 

Pretty hard, it turned out, for the many mainstream “lean-back” users who didn’t have the time, or the knowledge, that the early adopters and Spotify-employed music nerds had.

Another strategic insight was that more and more users were discovering music through what Spotify called Moments, such as “studying”, “running”, or “dinner-party”, rather than by seeking out specific genres or artists.

Spotify had already started a shift from the model where the user does the work by following people and playlists to build their music library, to a recommendations-based model, where the service does the work based on what the user has listened to in the past. 

Realizing that recommendations needed to become a core part of the product strategy, Spotify had recently acquired Massachusetts-based start-up The Echo Nest. The former Echo Nest engineers were now working together with Spotify’s machine learning engineers to help improve recommendations-based music discovery.

So Spotify leadership gathered up their product teams and explained that they needed to focus on understanding why the service was not performing as well as it should in the lean-back use case, and try to solve this.

This focus meant saying no to many other potential opportunities, and postponing or discontinuing others.  For example, they shut down a big initiative around video streaming, and the people and resources were reallocated to focus instead on the lean-back listener problem.

This holistic view of the business and the resulting focus allows the product teams to dedicate their energy to the most critical problems to solve, giving it a higher likelihood of success.

How You Solve Problems – Product Discovery

Initially Spotify had a recommendations approach called Discover which presented album suggestions in a Netflix-style layout, based on the user’s personal listening history, but this seemed to demand too much interaction from the users, who expressed the desire to “get me going quick without putting in effort.”

At the same time, Spotify’s new Browse feature, which became the app’s new starting view and showcased hand-curated playlists like Your Favorite Coffeehouse by Spotify’s editorial team, was experiencing significantly higher user engagement compared to the Discover feature.

On top of that, certain industry pundits argued that lean-back users simply weren’t interested in exploring new music.

However, a couple of the machine learning engineers that were working on recommendations didn’t believe this to be true. They believed there must be a way to reduce the friction for users, and help them sift through the 30 million songs to find great recommendations. 

Their optimism was bolstered by a recent hack week project, called Play It Forward, that was an add on to Spotify’s popular Year In Music (now known as Wrapped), a feature that provided a summary of the user’s year on Spotify.

Play It Forward analyzed the users’ listening history, using the same algorithm as Discover, to create a playlist of music you had not yet listened to on Spotify, but that you probably would like.

The playlist was presented to users at the conclusion of their Year In Music review. Months later, the engineers were astonished to find that millions of users remained engaged with it. 

This sparked a thought: what if we could create a playlist like this, and just update it more frequently? This was the seed of the idea that would become known as Discover Weekly.

The concept was fairly straightforward, and could potentially leverage existing technology. The feature categorized your listening history into micro-genres. It then used collaborative filtering on billions of user-created playlists, identifying those users who, just like you, listened to x also listened to y—a track you’ve yet to discover on Spotify.

The engineers pitched the idea to the product manager and product designer and they began the cross-functional collaboration between product, design, and engineering to evaluate the potential product risks.

First up was value risk: would users choose to use it? And most importantly, if they did use it, would they find enough value to continue to use it? 

Next up was usability risk: could users figure out how to use it? Would they be able to easily find the feature and understand its benefits? Realize that Spotify had never before made a playlist for users, and just dumped it in their library before – how would people respond to this?

Next was feasibility risk: could the engineers leverage existing systems for this, or would they need to build new systems, likely at high cost? Senior engineers at Spotify had already warned the team that what they were planning likely wouldn’t scale, as the playlist system wasn’t built to handle that kind of usage.

Finally, would this be viable for Spotify’s business? It had only been a few months since Apple Music placed U2’s new album, “Songs of Innocence,” in every user’s library without their consent, leading to significant backlash, and forcing Apple to create a specialized tool for its removal. Concerns loomed about a similar overstep, and Spotify’s co-founder CEO, Daniel Ek, explicitly pointed out to the team that this idea could backfire.

After considering all the risks, the product team decided this idea had the potential to meaningfully address the problem of the lean-back users, so they decided it was worth running a series of experiments and collecting some concrete data. The team had clear metrics to steer them toward tangible business outcomes: enhancing reach, depth, and retention. 

The team began quietly experimenting with a live-data prototype, which they subtly rolled out to all employees without any formal announcement. Monitoring the metrics, they observed the feature’s viral spread among their colleagues. This initial response served as an early indication that, at the very least, experienced users would be able to find and use Discover Weekly. 

This gave the team enough confidence to do a proper employee release (affectionately known as “dogfooding” in many product companies), announcing it via email, and other internal communications channels, along with an appeal to try it out, and give qualitative feedback.

Spotify employees loved the new feature. “It’s as if my secret music twin put it together! everything in it is good!” 

While encouraging, the product team understood that Spotify’s employees were not a predictive test, especially for the lean-back case.  But now they had the confidence to try to answer the question of whether actual users would feel the same? 

As with other product model companies, at Spotify, any empowered product team can roll out experiments to up to 5% of users without needing permission. The team decided to roll it out to 1.5% (1,000,000 users), watching closely as data began to trickle in.

The primary metrics were performing extremely well, and the qualitative results were equally impressive. The feature invited users to rate the new capability, and offer open-ended feedback. Over 1500 survey responses poured in, with more than 85% rating it 4 or 5 on a 5-point scale, and only a scant few raised the consent issue that had been a prior concern because of the Apple Music U2 reaction.

Remarkably, 65% of respondents discovered “a new favorite song” in their personalized weekly playlist. Users also took to Twitter to praise their new favorite feature, with comments like, “It’s scary how well Spotify’s Discover Weekly playlists know me.”

The product discovery experiments thus far successfully mitigated the risks related to viability, usability, and value.  But feasibility was still a question.

The team wanted to expand Discover Weekly to a broader user base. However, as the user count swelled, it became clear that the existing playlist system would not scale, just as the senior Spotify engineers had predicted.  The playlist system was simply not equipped to handle simultaneous updates for 75 million users’ playlists. 

But now Spotify had the evidence they needed to show that reconstructing the playlist system to accommodate the requisite scale would be worth the investment (this is what we refer to as a high-integrity business case).

How You Build – Product Delivery

In 2006, at the dawn of Spotify, the standard Waterfall approach for software product development involved months of coding, predominantly guided by internal stakeholders, before releasing your product to the world.

An obvious drawback of this approach was the scant user feedback until the end of the project, resulting in a product reflective more of the internal stakeholder’s preferences, with the optimistic hope that it would also resonate with potential customers. 

Recognizing these limitations, Spotify’s leaders and product teams understood early in the journey that a better approach to discovering and delivering product was necessary. 

Consequently, substantial investments were made to support the necessary experimentation and provide the product teams access to crucial user behavior data.  This included the infrastructure for instrumentation, telemetry, monitoring and reporting.  The company also invested heavily in deployment infrastructure, especially for A/B testing, with a dedicated platform product team focused on enabling these live-data tests.

Spotify was also an early advocate of small, frequent, uncoupled releases, and invested in the tools and techniques of continuous delivery.  

Since Spotify’s skills in product delivery are fairly well known in the industry, we won’t spend much time on that here.  However, it is critical to realize that these investments are what enable Spotify’s empowered product teams to deliver outcomes, and not just output.  

This delivery infrastructure paved the way for Discover Weekly and countless other Spotify innovations, large and small.

The Results

Only a few months later, Discover Weekly was ready for its global debut, rolling out to all Spotify users.

The launch was a resounding success, with 1 billion tracks streamed within the initial 10 weeks. Remarkably, 71% of listeners added at least one song to their personal playlists, and 60% of those who tried Discover Weekly proceeded to stream five or more tracks. 

The online buzz was equally enthusiastic, with users sharing emotional reactions like, “got really excited and started crying a little because I realized tomorrow is Monday, and Spotify is making me a new Discover Weekly.”

Product Teams and Product Culture

Hopefully this slice through product work at Spotify helps make clear the power of strong product teams, led by strong product leaders, working in the product model.

While Spotify is well known for its empowered product teams, this example shows what that concept really means in practice.  It requires strong product leaders that provide the strategic context – especially the hard product strategy decisions – and know how to set up the environment necessary for product teams to do good work.

The co-founder Daniel believed in a structure where responsibility for business outcomes, aligned with a clear understanding of product strategy, using data-informed experimentation, would produce the best results—even if the ideas weren’t his own.

One of the reasons that this Discover Weekly example is so illustrative is because Daniel was openly skeptical about the product idea, and shared his concerns with the product team.  But to his credit, he gave the team a problem to solve, and then allowed that work to proceed.  

And to the credit of the product team, they saw the potential of the enabling technology, and they proceeded to tackle the product risks responsibly and effectively. This is what’s behind so many tech-powered innovations, and this is what is truly meant by empowered product teams.

Like other product model companies, Spotify recognizes that the most innovative ideas—those that truly resonate with customers—often originate from those who engage with the enabling technology daily – the engineers. They are uniquely positioned to identify emerging possibilities. 

Great leaders understand the necessity of creating an environment where empowered product teams can exercise their creativity, discovering and delivering innovative solutions that not only customers love, but also drive business success.

Learning More

Last year, at the invitation of Crisp, Marty did a related talk aimed mainly at product and Agile coaches, trying to explain the different approaches to scaling, and why Spotify thrived while so many others failed, and you can view that talk here.

And of course I have spoken at length about Spotify and their culture.  Here’s one of my most popular talks, and I also teach a course on the topic.

The collaboration to “Essentialize” (render using the Essence Kernel and Language) this thinking will help people better understand, communicate, and adopt the Spotify Model Essentials. The result of the collaboration will be added to the ever-growing Essentialized practice eco-system, however the basic Spotify element cards can be downloaded here. The article: ‘The “Spotify Model” Demystified and Made Applicable through Essence’ is a great read if you want to know a little more. Essence brings a paradigm shift to the world of software and the potential for its adopters to reap huge benefits in productivity and performance. Essence enables a number of key use cases to help both organizations and teams make a step-change in their development capability. Ivar’s recent LinkedIn article “Essence, the Standard Common Ground, in a Nutshell” brings these use cases to life.

Collaborating with IJI and working with the Essence language to crystallize the core principles of the Spotify model has been really valuable” said Joakim Sundén, (Crisp AB Partner). “This synergy aims to demystify the model’s application, enhancing its accessibility and user-friendliness. Leveraging the robust foundation of the Essence Kernel and Language, we’re primed to weave these principles and practices with invaluable insights from industry leaders. Given the growing traction of Essence across both hands-on applications and academia, it underscores the immense potential of the Essence ecosystem as a platform for disseminating knowledge in such domains.

I am delighted to see the thinking around the Spotify model codified into an Essence based practice so it can be added to the rapidly expanding eco-system of practices available.”, said Ivar Jacobson, CEO and Founder of Ivar Jacobson International. “Essence helps teams and organizations use the practices that are right for them, it is an enabler first and foremost. So to see the popular Spotify thinking join the list of practices that teams can mix and match with others is extremely exciting. It is great to have Joakim, with all his practical experience from his Spotify days involved with the initiative. I can’t wait to see the practice in use more and more.

About Ivar Jacobson: Dr. Ivar Jacobson received his Ph.D. in computer science from KTH Royal Institute of Technology, was rewarded the Gustaf Dalén medal from Chalmers University in 2003 and got an honorary doctor at San Martin de Porres University, Peru, in 2009. His contributions in software engineering span over 50 years starting from components and component architecture in 1968 to the essentials of modern software engineering (Essence) in 2019. In between he created Use Cases and what became the Unified Process in 1986 and he was the co-creator of UML in 1997.

Ivar is the principal author of eight books and co-author of another three.

For more information on Ivar, visit https://en.wikipedia.org/wiki/Ivar_Jacobson.

Initial Chaos and Scaling Challenges at Spotify

According to old Spotify lore, as the company grew, the ad hoc collaboration that had been good enough for a small startup no longer worked when scaling up. It was no longer clear who was doing what, who to talk to when help was needed, how things were depending on each other, and so on. It was a bit chaotic at times and some people got really stressed out, crying out for help: “If we don’t do something about this, I’ll quit!” To address these challenges, Spotify brought in a Scrum trainer and introduced a pretty rigid Scrum prescription for all teams. Too rigid and bureaucratic for some apparently, who now said: “If we don’t do something about this, I’ll quit!”. It was clear that Spotify required a solution to grapple with the challenges of scaling and introducing Scrum by the book wasn’t the right way.

Balancing Chaos and Bureaucracy 

This would become the constant balancing act as Spotify grew in the coming years; how can Spotify have some kind of process that helps teams and people to avoid chaos but at the same time doesn’t constrain them too much? The expression “Minimum Viable Bureaucracy” was introduced and already in the first Squad Health Check back in 2011 one of the six categories for the teams’ self-assessment was “a process that fits the team”. The aspiration (indicated by a green light in the health check) was described as “the team has actively optimized the process for their use and are continuously improving their way of working” and the failure (indicated by a red light) as “the team doesn’t follow any process”. If a team felt they were somewhere in between (indicated by an amber light), the option was described as “the team follows our process but haven’t put much effort into optimizing it for their use”.

Describing the Way of Working 

It was clear within the Spotify organization that teams need to take ownership of their way of working as it needs to be adapted to fit their specific context and needs. It also has to be continuously adapted and improved as the team learns and their context changes. Values, principles, culture, training, coaching and management support would guide the teams on this never-ending journey.

One thing that was missing however, was a more structured way of describing which practices the teams were using. It is difficult to agree on what is working or not and what to do differently, if you don’t have a shared understanding of what you are currently doing. A good description and visualization of your way of working makes it possible to have constructive conversations about what to change to continuously improve. Capturing improvements, experiments, and lessons learned also facilitates sharing of knowledge and ideas so teams can learn and take inspiration from their colleagues. Unfortunately many of the teams at Spotify did not capture their way of working and those who were doing it often did it in an ad hoc way that wasn’t easy to share.

Enter Essence

When Joakim was introduced to Essence by Ivar Jacobson, it was immediately apparent that Essence could be a way to help address some of these challenges. Essence isn’t a new practice or method. It is an OMG standard that defines a common ground for describing, adopting and improving software engineering practices and methods.

The descriptions based on Essence establish a common vocabulary and body of knowledge which among other things helps practitioners compare practices/methods and make better decisions about their way of working. Thus, Essence empowers teams to learn and continuously adapt their way of working. In addition, it supports continuous performance improvements on various levels (e.g., organization, project, product, team). Furthermore, the Essence language allows organizations to create new or bespoke practices that can live alongside established practices in a Practice Library or ecosystem.

These key features of Essence match very well with Spotify’s approach to design and evolve organizational structures and way of working to fit the context of specific teams. And Spotify is of course not alone to have encountered these challenges. According to industry surveys there are many enterprises that are using some kind of customized version of agile frameworks, some even claim to use the “Spotify model”, even though it doesn’t really have a formal description. This got us thinking, could Essence actually be used to describe the “Spotify model” and support those who are adopting it or looking to it for inspiration?

Sidebar: Using Essence to Describe a Way of Working

The common ground defined by Essence includes the essential elements that are always prevalent in every software engineering endeavor (so-called Alphas, like requirements, software system, team, and way of working). These elements have states representing progress and health, so as the software endeavor moves forward the states associated with these elements progress. Moreover, the elements can be applied on different levels to assess the progress and health on each level. Essence supports scalability including from one product to many, from one team to many, and from one practice/method to many. On the level of teams the elements can be used by an individual team to guide their work and way forward based on the element’s states and practice descriptions.

Furthermore, Essence supports agility and autonomy on the level of teams because practices and methods can be refined and modified by an individual team to reflect its experiences, lessons learned, and changing needs.
Essence provides a common vocabulary for talking about solution development and a framework on which practices and methods are described. It tears down the language barrier that exists in many teams and software endeavors by enabling practices to be described using a single vocabulary—the so-called Essence kernel. In addition, Essence provides a visual form for each of its elements. Particularly, it defines a visual view based on cards which contain a mix of symbols and text that are related to an element. These cards can be used as physical, printed cards or as digital images on slides, virtual whiteboards, etc. They represent hands-on guidance for project teams supporting the definition, composition and communication of their way of working.

Is There Really a “Spotify Model” Though?

The Spotify model is a very loosely defined “framework” for agile at scale. The canonical “documentation” consists mainly of an outdated white paper from 2012 – that clearly states it’s “only a snapshot of our current way of working” – and two “engineering culture videos” from 2014 captured by a consultant who, in his own words, was “just the messenger”. If you want to learn more than that you’ll have to wade through a vast amount of presentations and articles, many of them published by Spotify employees saying things like “there is no Spotify model”, “don’t copy the Spotify model” and “you can do better than the Spotify model”.

In spite of the lack of a formal definition, the scarcity of semi-official descriptions and many cautionary tales, the “Spotify model” continues to appeal to many organizations. We believe it’s a conservative estimate to say it has been adopted in one way or another by hundreds of organizations by now. It is even being used by the big consulting firms as an agile transformation approach. So, no matter what people tell you, there is de facto a Spotify Model out there. Let’s stop kidding ourselves and instead actually help people better understand what the Spotify Model is and to evolve our collective understanding of how it can be of value. We believe Essence can be an enabler to better understand, communicate and adopt the Spotify Model.

Towards a Spotify Model Essentials

We have in collaboration put together a first draft of what we believe are the essential building blocks of the Spotify Model described with Essence. It is based not only on the aforementioned white paper and videos, but draws on Joakim’s experience from co-developing the model during his employment at Spotify from 2011-2017. Joakim has since also co-developed (with Jimmy Janlén, who consulted at Spotify for several years) the course “Agile at Scale, Inspired by Spotify”, pouring hundreds of hours of research into understanding it even better; incorporating perspectives and feedback from other current and former Spotify employees, as well as some of the experience from the hundreds of people who have attended the course over the last five years. He has also worked with several organizations that have used many of the Spotify Model essentials.

The Spotify Model Essentials fundamentally consists of organizational patterns, activities, and core beliefs.

The organizational patterns are the ones most people familiar with the Spotify model probably will recognize. Organizational structures consist of teams, such as Squad, Chapter, Guild, and Tribe; and roles, such as Chapter Lead, Agile Coach, and Product Manager. However, there are also some that you won’t find in most common Spotify Model material, for example POTLAC, the Tribe Lead Trio, and different types of Tribe Leads (Technology, Product, and Design).

For activities, a lot of practices used both at Spotify and in other organizations adopting the Spotify Model are already described in Essence as they are commonly used agile practices. For example retrospectives, team stand-up, iteration planning, product backlog, blameless post-mortems, and user stories. In our Spotify Model Essentials we chose to describe a few specific practices that we believe are useful for many contexts: Squad and Tribe Kick-Starts, Squad Health Check, and Tribe Gathering. 

A really important part of the Spotify Model, that too often is overlooked, is the core beliefs. This is partly because people tend to focus on the more tangible structural elements and partly because what these beliefs are has not been as clearly communicated. Spotify Model Essentials is trying to change that by describing what we mean are the guiding principles for the entire model. For now, we have divided them into the categories of supporting the belief of “autonomy” and of supporting the belief “alignment” – both parts of the overarching belief in “Aligned Autonomy”.

“Empower and Trust”, “Developing products is about developing people”, and “Strong teams always beat rock stars”, are mainly about supporting empowered autonomous people and teams.

“We’re all in this together” and “Be autonomous, but don’t suboptimize” emphasize the need for alignment in service of the collective outcome.

These core beliefs are the real litmus test for whether you are just copying Spotify Model structures or if you are capturing the essence of the Spotify Model: deliberately experimenting with different patterns and practices to achieve aligned autonomy. If your implementation of the Chapter Lead role is not helping you develop people who are empowered and trusted, that might work for you, but it’s not the Spotify Model. If you call your component delivery teams “Squads” and your backlog administrator “Product Manager”, go for it, but it’s not the Spotify Model.

Benefits of Describing the Spotify Model Essentials

In addition to being an enabler, Essence provides specific benefits to the Spotify model. The model defines a foundation to design and implement organizational structures and the way of working. Particularly related to the latter, the Spotify model leverages many other practices like product management, DevOps, and daily stand-ups. However, the Spotify model doesn’t define how a team like a Squad can combine those practices in everyday’s work to compose a distinct way of working. The Spotify Model Essentials supports composition with other practices that are also described using Essence. 

In addition to the definition of a common ground, Essence also defines the essential elements that are always prevalent in every software engineering endeavor (like the so-called Alphas). Those essential elements also enabled us to identify the essential building blocks of the Spotify Model by mapping the Spotify Model to the essential elements. Moreover, the mapping supported us putting the Spotify Model into perspective and describing its scope. This resulted in the fundamental structure of the Spotify model practice into core beliefs, organizational patterns, and activities.

Moreover, the Spotify Model is centered around the principle of autonomy and the organizational pattern of the Squad. A Squad is like a mini-startup that is autonomous and self-organizing. Particularly, this means that a Squad defines and evolves its own way of working. In practice each Squad could have its own way of working at any point in time. Essence supports this autonomy by providing hands-on guidance for Squads to define, compose and communicate their way of working. A Squad can for example leverage the games we’ve provided as part of the Spotify Essentials Gameboard based on Mural template.

Using the Spotify Model Essentials

There are many use cases for the Spotify Model Essentials. Altogether they help to understand, adopt, optimize, and improve the individual use of the model. Accompanying the release of the Spotify Model Essentials, we’ve made available additional materials for leveraging this new practice.

First, we’ve developed a classification that guides the adoption of the Spotify model.

This classification distinguishes between the elements which should be embraced when adopting the Spotify model and elements which could be considered to complement and support it, depending on context and needs. Particularly, the classification lists and groups other practices which are self-contained and typically used when the Spotify model is adopted.

Second, in collaboration with Simon Girvan we have released a virtual whiteboard based on Mural that demonstrates how the cards of the Spotify Essentials practice can be leveraged  to play so-called serious games. These games do not have entertainment, enjoyment, or fun as their primary purpose. They are played in person and address business problems in creative, engaging and, most importantly, effective ways (see the book and website on gamestorming). The Spotify Essentials Gameboard contains five games that will help to understand, adopt, optimize, and improve the individual use of the new Spotify Model Essentials practice. Furthermore, Simon developed another game which we’d like to play openly with you: How well do you Spotify? We’d like to invite you to analyze the elements of the Spotify Model Essentials practice and assess them by using simple sticky notes. This gameboard is shared by all players and thus we’ll get an idea of how the Spotify Model is used in practice.

We Want Your Feedback And Contribution!

The Spotify Model Essentials and additional materials demystify and make the model more easily applicable. However, we still feel that there is a lot we don’t know about how people out there are using the Spotify Model, in actual practice, and what they believe is core to the model. That is why we want to release this early draft, even though it’s missing a lot of pieces of the full Spotify Model puzzle, because we are eager to involve a wider community of Spotify Model practitioners to help capture a shared understanding of what it is to all of you. We’d love to get your feedback, comments, ideas, and of course also criticism. We suggest leveraging the LinkedIn group Essence for Agility for following and participating in the discussion about Essence in general and also the Spotify Model Essentials practice.

– Joakim & Stefan

About the article authors

Joakim Sundén

Joakim Sundén is a consultant with Crisp, a small Swedish consultancy with world-renowned Agile experts who help develop sustainable organizations. From 2011 to 2017 he worked as an Agile Coach at Spotify where he was part of a group of people working together with the CTO to develop a new approach to Agile at scale, aka “The Spotify Model” with Tribes, Squads, Chapters and Guilds.

https://www.joakimsunden.com/

LinkedIn

Stefan Malich

Stefan Malich empowers people and organizations to reduce the complexity and risk inherent in the development of software-intensive systems by improving the way they design, evaluate and implement software architectures. This encompasses the enhancement of architecture-related methods and processes, the adoption of technologies and application of innovative architectural patterns and designs.

https://stefanmalich.com/

LinkedIn

Simon Girvan

Simon is a principal consultant and agile coach at Ivar Jacobson International where he has a particular focus on developing Essence products and practices and in helping organizations use Essence to help power up their development practices. He is an experienced agile coach and co-author of the book ‘Agile From First Principles’.

https://www.ivarjacobson.com/

LinkedIn

One of the companies that really caught my interested, in part because they are quite similar to Spotify in many ways, was Riot Games. I was so inspired by my visit in their Los Angeles office that I ended up writing an internal report for Spotify, later published (in a modified version) as an appendix in the full 2016 SDLC report. I also presented parts of it at Drucker Forum together with SDLC board members Steve Denning and Vanessa Adams, “New Developments in Entrepreneurship and Innovation at Scale” (full video).

However, I know some people won’t make it through the full report all the way to the 6th appendix, so I wanted to share my report about Customer Obsession and Agile Mindset at Riot Games in this blog too. I hope you enjoy it at least fraction as much as I enjoyed my visit at Riot!

Customer Obsession and Agile Mindset at Riot Games

Riot Games aspires to be the most player focused game company in the world. They currently have one game in production, League of Legends, a team-oriented action and strategy game or MOBA (Multiplayer Online Battle Arena). League of Legends has dominated the online market since at least 2012 and is the biggest online PC game in the world with more than 67 million monthly active users, 27 million per day, and over 7.5 million concurrently during peak hours.

Riot was founded in 2006 and has 2,500 staff with 15 offices all over the world, from their biggest main office in Santa Monica in the West to Tokyo in the East. Riot Games is a popular employer (e.g. #13 on Fortune’s list of 100 “Best Companies To Work For”), they were Agile from the start and have a trusting culture and decentralized way of operating.

The Riot culture

Culture is one of the most important factors why people work at Riot Games. One Rioter explained that Riot culture comes from the experience of being burned by a different culture where managers would say, “You just have to do this”. “Here at Riot, you can’t tell anyone here to do anything. That’s not a joke!” Autonomy and trust seem strong at Riot Games. One example is that they don’t do budgeting, only forecasting exercises. If you need to hire people you just make a business case for that. If you’ve done your homework, and answer all questions, you’re fine, even if you have “used” all your forecast headcount. Another example of this trust and autonomy is how the development manager coordinator we met had produced a video explaining the Development Manager role by internally recruiting people and procuring what she needed without having to seek approval.

Mission and player focus

Another important aspect of the Riot Games culture is the laser-sharp focus on their number one target user. “We are defined by our audience: core gamers.” That is also expressed in the company mission statement, “To be the most player focused game company in the world”. You can wake up any Rioter in their sleep and they can repeat it. People typically mention it 10-15 times a day in conversations. It’s actually so important that it’s a requirement when hiring for almost all roles to be a hardcore gamer, although exceptions are made for those with a particular expertise.

People we met at Riot Games often referred to the mission and the players:

• “This is part of our player promise, so we need to…”
• “If you put something in front of players, you should…”
• “We got to get it into players’ hands before pre-season!”
• “If it doesn’t have a consequence for the player we shouldn’t do it!”
• “How player focused is she?” (Asked in Performance review)

When Rioters are asked to do something, even follow new policies or guidelines, they will ask themselves if it’s going to help them deliver value to the player. If you can convince them that it is, they will probably do what you say, otherwise not so much.

Here is the way one Engineering Director puts this: “Your good idea must survive the crucible of socialization to become great. What this means in many cases is that we take a Product Management stance for organizational development: we must understand who is the arbiter of value and how to realize that value.”

To really get to know the players in one of their biggest markets, Riot has installed Korean style Internet cafés, complete with vending machines with Korean snacks, where they encourage everyone to play. Through this they discovered early on that some features they thought were important didn’t make sense, (e.g., online chat), or proved difficult to use in that environment, (e.g., because they’re using a shared computer.)

A Senior Development Manager emphasized the importance of a clearly outlined mission and vision on all levels of the organization: “If you have the same goal as the person sitting next to you, you level up three steps immediately.”

Teams are very KPI focused. Almost every team defines its own mission and vision and KPIs on all levels, which are reviewed monthly.

The Riot Games culture is also expressed through the Riot Manifesto:

1. Player Experience First
2. Challenge Convention
3. Focus on Talent and Team
4. Take Play Seriously
5. Stay Hungry, Stay Humble

Another cultural expression we often heard was that of having a “Founder’s Mentality”. Always wear your “Riot Hat” and think like a founder of the whole company: it’s always your responsibility, you’re here to solve the problem, even if it’s “not your role”.

At Riot Games they say they’re not scaling Agile, since they don’t worry about practices at all. They focus instead on culture and principles. The culture provides a system that will revolt if, for example, someone tries to introduce micro-management.

Overall, the mission clarity and customer focus at Riot is compelling. It gets people to rally around. The user empathy and customer focus is remarkable.

Team roles

Every Rioter is part of a Discipline (e.g. Engineering, Art, Talent) and a Product (e.g., League of Legends, E-Sports), typically working in a cross-functional agile product team. Who is responsible for the result of the agile team? Who is leading the team? Riot believes in collective responsibility, but individual accountability. All teams at all levels (Agile Team, Project, Product, and Initiative) at Riot have four roles (not titles, one person can theoretically fulfill all):

• Team Captain (TC). Leading the overall effort, lead of leads.
• Product Lead (PL). Leading product strategies and resonance with audience.
• Delivery Lead (DL). Leading delivery and execution.
• Craft Lead(s) (CL). Can be Design, Art, Talent, Engineering, Publishing, etc. Leading on technical direction in a specific craft area.

Clarifying responsibilities

In response to a request for help from the teams themselves, Riot has developed an inventory of 35 responsibilities that a typical team might have. Ten of them are attached to the TC, PL, and DL roles, the rest are up to the team to assign. To support the approach, Riot have actual hats in different colors and printed cards with the different responsibilities the team can use to facilitate decisions. A new team is often started by someone (or a group of people) becoming a TC and he/she then wear all the hats until they are assigned to others.

The 35 responsibilities constitute a kit for the team to start with. In some cases, some don’t apply; in other cases, new ones are created that are more relevant. Teams can also create new roles that apply as needed.

The TC is usually a Product Manager or a Development Manager (similar to Agile Coach) sometimes someone from Art or Design, but it can be anyone. A common pattern is to groom junior people for roles by assigning responsibilities, e.g., add a “Junior Product Lead” role and assign some responsibilities to that person previously held by the PL.

A Development Manager at Riot Games is very similar to an Agile Coach and they often have a background as an Agile Coach, but it could also have been e.g., Producer, Project Manager, or Engineering Manager. The main difference from a Coach is that a Development Manager, typically fulfilling the Delivery Lead role, is accountable for the delivery and result of the team, while they perceive an Agile Coach to be more of a coach from the sidelines role with no skin in the game.

Managing a large program

With LCU (League Client Update), a large program to build an extensible client framework and deliver a dramatically improved client UX for all players, Riot Games is experimenting with a new way to achieve collaboration at scale. The program is executed by a team of several hundred people who plan together, identify dependencies between around fifty smaller work “pods” and then meet at a daily standup to load balance so that pods with excess capacity help others who are falling behind.

All pods are of similar size and composition (2-3 JavaScript, 1 C++, 1 Visual Designer, 1 QA), which enables load balancing. They are called pods because Riot wants people to identify LCU A report of the SD Learning Consortium: www.sdlearningconsortium.org Page 57 as their team. That’s where most rituals live (e.g., shared planning for synchronized 2 week sprints), as well as working agreements and culture, and the definition of “done.” All LCU Team members share common goals. Retrospectives are run in pods.

There are about 7-8 formal leaders who spend most of their time on the ground, moving around between pods, help where needed, clarify goals, and help understand technical direction and what is good and bad.

This way of working has been well received, engineers understood the value and accepted what could have been perceived as unnecessary overhead in terms of planning and coordination. By organizing this way, the leaders didn’t have to “pull teeth.” The team health survey, which Riot runs every six months, showed that people are very positive about the setup.

Another interesting practice related to collaboration is that if you know how to fix an issue that occurs, find someone who doesn’t and teach them. As a thank you the person you taught writes up documentation for it.

The “Request For Comment” process

Riot Games has a well-defined “Request For Comment” (RFC) process. Anyone can make a proposal for a change. It could be a technical/architectural change, but also an organizational/process change. An RFC is submitted to a central repository. There is an open comment period. Depending on the type of decision, it can either automatically pass, if there are no objections, or it will go to a small group of people who would make a final decision informed by the process. The decision is then communicated across all development teams.

The RFC process is a way to leverage wisdom of the crowd while at the same time socializing change and empowering all. The actual structure / governance depends on the type of interaction you desire and the mechanism for formalizing the decision. In a well crafted system, the best ideas will survive regardless of whose brain they emerged in. Yet, for org governance, there may be a small group that harvests these ideas for operations as final approvers.

All recently approved and ongoing RFCs are published in their Engineering Weekly newsletter. These newsletters were also put up in all bathroom stalls.

The socialization philosophy of change is pervasive throughout the organization.

Physical space

Riot Games takes collaborative and creative environments seriously and put a lot of thought into designing their new office, a campus they moved to in 2015.

Using an open floor layout with big spaces and everything on wheels, including many walls, allows them to constantly evaluate what’s working and what’s not, patching as needed. The height adjustable desks even have batteries so you can move your desk without interrupting the power supply. This made it possible for the LCU Team (see Scaling Collaboration above) to move together 100 people overnight when they kicked off the project.

A small detail that I really liked was the name tag on everyone’s desk so you could easily see who’s sitting where. Like several other companies I’ve visited lately they also had screens outside meeting rooms clearly indicating if the meeting room is free or not and what meetings it’s booked for. Another nice touch was that the screens in the interviewing rooms had a big personalized welcome screen for candidates.

The prioritization pyramid

A tool commonly used at Riot Games is the “prioritization pyramid”. The pyramid is used to quickly prioritize, making sure to agree on one top priority but deferring prioritizing between individual items of secondary, tertiary, and so on, importance; the two second row items (2,3) are considered equal importance for now, the three third row items (4,5,6) are equally important, and so on. They sometimes also use prioritization diamonds and prioritization Christmas trees.

Last week Ratheesh presented me with a new exercise that I started today. For 47 days I will do one day of fasting (drinking only water) every week and the rest of the time follow a diet similar to the detox one I tried:

• Only vegan food: no meat, no fish, no lactose/egg/dairy
• No gluten: no bread, rice or pasta
• No alcohol, coffee or tea
• No potatoes
• No citrus fruits
• No preservatives
• No fried food
• No vinegar
• No soy or soy based products
• No nuts, except for cashew nut soaked in water for a day
• No seeds, except for pumpkin seeds

So what will I eat? During the two weeks of detox when I first tried this diet I had a lot of sallad, vegetables and fruit. I am also allowed to eat black and red rice, quinoa and millet (“hirs” in Swedish) and quorn (made of mushroom). Coconut milk is ok too so I expect to eat a lot of thai-ish food, like spicy curries with coconut milk and black rice. The biggest challenges will be eating in restaurants and dinner with friends and relatives. It will be interesting to see how my body reacts, I’ll probably loose a couple of pounds…

sddasd

Yoga class

It has been years since I last did yoga, but the Spotify Mind Awareness Program and the fact that Spotify offers a free yoga class every Thursday morning just across the road, made me want to pick it up again. It was really tricky and exhausting at times, but really fun too. I have only tried simple positions in beginner classes at the local gym before and had no idea that I would be able to go from sitting position to standing on my head without support (well, the hands of course). And standing like that on top of another guys knees and thighs while he was in a bridge position none the less! I will definitely do this again.

MTMS Management standup

Every Thursday (and Monday in the longer management meeting) the management team gathers around a Jira board to coordinate our work, follow up on its progress and share information. Today we talked briefly about the progress of determining different OKRs for Q2: for chapters, squads and the tribe. I also got to move the last squad’s “Definition of Awesome” work to done.

Catching up on e-mails

I decided to use the time before lunch to catch up on e-mails. I read and answered threads discussing our tribe OKRs (see the Monday post), the agile coach recruitment process and a request for agile coaches for the Spotify Bootcamp. The bootcamp is a chance for new hires to start their first week at Spotify working together as a squad, with a product owner and an agile coach, and experience a mini-sprint of work. They are provided with something useful, interesting and fun to work on that often forces them to learn a lot of our systems and to talk to people in different departments.

I also handled some more practical stuff preparing for our intern next week, sorted out the agenda for Friday’s workshops with the product owner and exchanged some ideas for my upcoming trip to San Francisco. In the beginning of May, my New York agile coach colleague George McMonigle and I are going to the San Francisco office to help them with some agile coaching.

Agile Coach lunch

Thursday is agile coach lunch day in Stockholm. It’s a good chance to catch up with other agile coaches although you never know exactly who shows up. This week’s turn-out was good, probably because our dear colleague Karin is back from a long period of parental leave.

Preparing team work workshop

After lunch I worked on preparing the team work part of Friday’s workshop. The first half of the day will have a focus on what it means to be an awesome team and how to get there. I finally caught up with Jimmy to go through his team work course slides together with him. As I’ve already mentioned there were a lot of golden nuggets in there and I decided to steal quite a few after having bounced ideas back and forth. The result will be presented in tomorrow’s blog as I will have to put in some more work tonight…

Prepare Lean Kanban North America talk

Time for a quick “brainstorming” about how to change our talk at Lean Kanban North America. We came up with a few good ideas on what to add, but it was a bit harder to know what to drop. In earlier talks about Spotify’s organization we have used autonomy, mastery and purpose as structure of the presentation. This time we will have 40 minutes instead of 55-60 and we have a slightly different focus. We decided to come up with a new structure first and that will hopefully help us understand what we can remove. We will think individually about this and meet again next week.

Growth team weekly

All product development people, and a few others (like me), in the Growth organization gather weekly to share information and coordinate. I’ve only been to two of those so far, in the first we reviewed the Q1 OKRs and in this one the next quarter’s OKRs were presented and discussed. Is this or that key result (KR) challenging enough? Can we really measure that KR? Can we change this KR to a quantitive one? Is that KR aligned with the objective? (Does it matter?) And so on. One thing I really like about this meeting is the “wins & highlights” where we go around the table and have everyone report at least one “win” the last week, for example something you or your team shipped or a new hire that was signed.

Lean Coffee

Three years ago I visited my first Lean SSC conference (what is now Lean Kanban North America), in Atlanta 2010. Fellow travelers Peter Evjan and Johan Söderström and I were met with a very warm welcome because we were the only Europeans who had managed to avoid the volcano ash clouds that stopped everyone else’s flights. In Atlanta we got to know Jim Benson, one of the originators of Personal Kanban and Lean Coffee, and he inspired us to start our very own Lean Coffee in Stockholm (or Sundbyberg, Sumpan, where all of us happened to be working at the time). Lean Coffee Sumpan/Stockholm has now been going strong every Wednesday for three years, only pausing for summer and Christmas. If you haven’t tried it yet and live in (or pass by) Stockholm you should really come by. Wednesdays 08:00-09:30, come when you can, leave when you have to. Le Café, Klarabergsviadukten 61.

Today we were so many participants that we divided into two groups. The one I joined discussed if evolutionary change without management and lean operational strategy is possible and how to leverage organizational feedback loops to manage complexity. The other group discussed how to manage flow and portfolio kanban.

For a brief example of how we use Lean Coffee for meetings at Spotify, see my Monday post.

Retention standup

We have only been running standup meetings for a few weeks so today I asked the team members to reflect for a while after the meeting. Is the meeting useful to you? Affirmative, but someone thought it was a bit too long. What, if anything, could we remove from today’s meeting without reducing the value of it? A suggestion was to take some of the problem solving discussions after the meeting, only involving the ones it concerned.

We ended by briefly considering if we were achieving the five goals we had established for the meeting:

• Does it give your day a good start?
• Are we identifying improvements?
• Does it supply us with a focus on the right things?
• Is it increasing our sense of team?
• Do we now how the work is progressing after the meeting?

Some modifications to the board were suggested when answering the last questions.

Impromptu meeting with Paid Acquisition

I was lucky enough to find three quarters of the Paid Acquisition team available for a short impromptu meeting. I wanted to know if they considered themselves a team or not, or possibly two teams. They swiftly concluded that they wanted to work as a team, but they needed a better way to handle the fact they had multiple stakeholders. A short discussion later we decided to do a lunch & learn about Kanban.

When I stopped by later in the afternoon they had already change their board and decided do have a standup every other day.

Planning a workshop with the PO

As I mentioned in the Monday post we’re planning an off-site workshop with the Retention squad to work on our team skills, review last quarter and plan the next one. I got together with the Product Owner, who is preparing the review and planning parts, to create a plan for the day, and decide how to run the different parts of the workshop. I will write more about the workshop in the Friday post.

“A canceled gig is also a gig”

This legendary quote is the words of a world famous (in Sweden that is) Swedish artist who then added that “the canceled concerts is the only thing people are talking about, so they have to mean something”. So I guess it means something that Mumford & Sons had a gig at the office today that was canceled last minute. Bummer, I would have loved to see them, but instead got to see, and catch up with, some folks from other floors and departments that I had not seen in a while.

Agile Coach intern

Together with colleague Matthew Green I have decided to take on an intern from an “agile project manager” education here in Stockholm. She starts next week and there were some practical things, like getting user accounts and a computer, that needed taking care of.

SMAP individual coaching

Every other week I get individual coaching from our mind awareness teacher Ratheesh Mani (see the Tuesday post). Since I seemed “open to experimenting” he gave me quite a challenge: a three weeks “detox” program with two 36 hours fasting periods a week and no bread, gluten, potato, alcohol, lactose, and a bunch of other things, during the rest of the time. I’m going to start Monday next week…

Team work course

Colleague Jimmy Janlén has developed a team work course that he has taught a lot and is now going to try with a couple of Spotify squads. With my upcoming team workshop I was curious to exchange ideas with Jimmy. Unfortunately he had to postpone our meeting to tomorrow so I spent some time going through his slides to see if there was anything in there I could use. There sure was! I used the inspiration to start preparing my own workshop on Friday.

Writing

I have started to block off a few hours in my calendar every Tuesday morning dedicated to writing. Besides writing on this blog and on the internal and public Spotify blogs, I am currently writing internal articles about culture and autonomy (they will probably be published publicly later) and presentations/talks for conferences and internal use. Today I spent some time writing this series of blog posts about the agile coach role.

Retention squad standup

The retention squad is one of the squads I work with. Retention’s mission is to keep people coming back to Spotify, for example through reaching out to users with relevant e-mails and notifications. When I started working with Retention a few weeks back they didn’t have a standup but several of the team members wanted to have one. We decided to try it for a couple of weeks and kicked it off with me giving a fifteen minutes introduction on the purpose of a standup and some useful tips and tricks to make it as effective as possible. We now have them daily at 10 o’clock.

Long lunch with the Mrs

My wife had a doctor’s appointment in the city today so I met up with her downtown to take care of our four weeks old daughter. I had a wonderful walk in the spring sun and later we had a nice sushi lunch together. Spotify is a very flexible employer that trusts the employees to manage their own time. No one has to ask permission to come in late, to go on a long lunch or to play FIFA in the middle of the day.

Planning an agile coach camp

Together with one of my newest agile coach colleagues, Viktor Cessan, I’m planning a three nights and two days agile coach camp in early September. The idea is to invite people seriously interested in agile coaching, with an emphasis on coaching, and possibly one or two particularly skilled/well-known coaches, to an off-site in a secluded hotel or “mansion” outside of Stockholm, for learning and practicing coaching tools and techniques. It would be open to coaches outside of Spotify too, for a self cost price. We’re thinking that the first day would be coaching deep dive with a lot of practice and the second day would be more of an Open Space-ish thing, maybe with a twist. It’s still on the drawing board, but we made some real progress in today’s meeting. (Please let me know if you’re interested in participating in an event like this.)

Chatting with engineers

During the afternoon I continued to get to know the Growth organization better by chatting with some engineers, for example the chapter lead (hiring manager) for several of the web devs.

Spotify Mind Awareness Program

Three weeks ago Spotify started an eight weeks Mind Awareness Program (SMAP), organized by colleague Sofia von Celsing in People Operations, to teach mind awareness and how that can enhance your productivity, focus and general well-being. I’ve been dabbling with meditation and mindfulness in the past and saw this as an excellent opportunity for deeper learning and for creating a solid habit. The program gives us the opportunity to practice mindfulness, breathing and energy enhancing techniques.

Every Tuesday we meet with our teacher Ratheesh Mani for an hour and a half of theory and practice, every other week we have individual coaching sessions with personal training and consultation. Ratheesh suggests individually tailored exercises and this week mine was to get up six in the morning and meditate for half an hour and not eat any bread for a whole week. The bread part was the toughest (Me: “But I love bread!” Him: “I know”), but I managed to pull it off. :)

Catching up on e-mails, planning off-site, etc

The last part of my work day was spent on writing some meeting minutes, catching up on e-mail, sending out practical details about Friday’s off-site and making practical arrangements with the venue, and so on. In the end of the day I also review my plan for the day and look at the calendar to see what, if anything, has to be carried over to next day’s plan.

Planning the day

I usually try to start my day making some kind of selection on what I should do during the day, and in which order I should do it. At the moment I use index cards where I put today’s date and write down a short todo list. I start with going through the calendar to determine if there is anything I need to prepare and to assess how much time I will have for things not in the calendar. I try to not have too many things I must do so I have slack for unforeseen things, catching up with people and teams, and so on. I write down the calendar events on a post-it and stick it to the index card and carry the card with me through the day, adding notes and actions to it as things happen.

Meeting Mr Paid Acquisition

This Monday I had a meeting first thing in the morning, a pretty rare event since most spotifiers like to sleep in. I was meeting the guy in charge of Paid Acquisitions and he happens to live just around the corner from the office and, as father of a small child, happens to be really early arriving to work.

I recently started working with Spotify’s Growth organization. Growth focuses on driving monthly active users (MAU), daily active users (DAU) and engagement, increasing conversion rates and ensuring that we excel at retention as well. The first thing I did when starting to work with Growth was to sit down and have a chat with everyone working there. I want to learn what they are doing, why they are working here, what they like about it, if there is anything they would like to be different or that they are struggling with, and so on. Besides getting to know everyone better this will help me to assess how I should spend my time, what I should focus on in my work.

In today’s chat I learned a lot about how we work with paid acquisitions, but that’s a topic for another blog post and probably by another author.

Agile coach fika

Every Monday morning we have an informal fika meeting open to all agile coaches in the Stockholm office, and to anyone else that happens to stop by for that matter. We meet in the corner of our beautiful 11th floor cafeteria with a nice view of central Stockholm and have some breakfast. This morning there were about four or five of us and we talked about last week’s Product Days, a big offsite for everyone in our Product Development organization (and then some) where both strategic and tactical discussions are being held.

The informal meeting type we call “fika” is a more and more common meeting form here at Spotify. A fika, in our definition, means that most normal meeting guidelines are reversed: you don’t have to be on time or even show up, there is no agenda, no minutes, and so on. It’s basically just a scheduled time in a specific place with a certain group of people invited. If you’re lucky there will be sweets to the coffee. The purpose of a fika is often to offer a break where you can meet other people that shares a particular context with you, such as other agile coaches or the other members of your tribe (our name for department, kind of) to catch up and  keep some sense of togetherness or team.

Somewhere between fika and meetings the “Lean Coffee” format is also growing in popularity at Spotify, in my tribe we use it in our tribe management meetings, among other meetings.

More Than Music Stockholm tribe management meeting

I work in the More Than Music Stockholm tribe. Most of the Growth squads/teams (see above) are in this tribe and we also host the squads that are working with customer services, artist profiles and the new discover view launched recently. The tribe management team consists of the tribe lead (VP of Engineering), all the chapter leads and agile coaches in the tribe. Our purpose is to optimise our tribe to deliver value for Spotify and our mission is summarized as “challenge, support and focus”. We have a weekly meeting that starts with briefly going through the board before we use a Lean Coffe style approach for the rest of the meeting. Everyone can suggest topics that are written on the board, we vote (typically using three dots each) and go through the list starting with the one that got the most votes. We time box each topic to ten minutes after which we decide through “thumb voting” if we want to keep going (thumb up), go on to the next topic (thumb down) or let the others decide (thumb sideways). If we decide to keep going we use five minutes intervals between coming votes within the same topic. This format lets everyone influence the agenda and feel an ownership of the meeting and I have found that it often keeps the discussions focused and at times allows us to keep the meetings shorter than planned for.

Example of topics discussed today was takeaways from the Product Days (see above), new budget, and an experiment one squad is running with transferring responsibility for monitoring alerts from SRE (Service Reliability Engineering) to the squad itself. We also reviewed our OKRs for the first quarter and talked briefly about our OKRs for this quarter. OKR stands for Objectives and Key Results and is a tool we use to to keep us focused on the right priorities, and help aligning everyone in the organization, when needed. An OKR is an objective, for example we used “Grow high performing teams” for om of our Q1 objectives, which is more of a vision or direction, and three to five key results to help move closer to or achieve the objective, e.g., “each team should have a Definition of Awesome”. OKRs can be a mix of product, technical and process goals.

E-mails, planning and blogging

Having some time between meetings I decided to check up on e-mails while listening in to one of the squads I work with discussing some scaling challenges. I am planning an offsite with this squad, the Retention squad, with team building, Q1 review and Q2 planning for this Friday, so I made sure everyone is still available Friday and went on to book venue, food, etc. There was also time for some blogging, soon to result in the introductory post in this series.

We have an awesome cafeteria on the 11th floor which makes it really easy to have lunch with colleagues you don’t always meet otherwise, but unfortunately also makes it easy to just get some sandwiches and snacks and sneak back down to your desk to work, which is exactly what I did this day.

Loops

Two times a year all employees participates in a 360-degree feedback program known internally as Loops. We write a self-evaluation, request feedback from a number of peers and book a meeting with our manager. Today it was time for me to sit down with my manager, tribe lead Geoff Wilson, to review my accomplishments the last six months and to start think about the future. As most of us have weekly one on ones with our managers and many of us get continuous feedback from our peers, this meeting rarely contains any big surprises, but is rather a chance to look at the bigger picture and the long-term perspective.

Chatting with a Paid Acquisition engineer

My exploration of Paid Acquisition continued in the afternoon when I got the chance to sit down with one of the engineers working in this area. Engineers usually don’t have that many meetings and many of them prefer to have longer time slots of uninterrupted work where they can focus on the task at hand. I try to avoid booking meetings that split up their days more than necessary and prefer to catch them by the coffee station and invite them for an informal chat on the spot. To be able to do this you to have plenty of slack in your calendar.

Interviewing our CPO

We did a big retrospective a while ago and I have been wanting to catch up on some things with our Chief Product Officer ever since, but our calendars haven’t aligned, mainly because he’s a busy guy but also because of my paternity leave and being busy organizing a hack week before that. Today we finally got the chance to sit down and I could interview him about a couple of the mysteries identified in the retrospective. Unfortunately I can’t blog about this, but now I have some information to communicate to other stakeholders and, more important, a few things to improve for our next big event or release. As so many other things around big projects it concerns communicating important things early and clearly to all interested parties, there’s always room for improvement there.

Coachmeet

If interviewing the CPO had not conflicted with this weekly meeting and made me miss the start I would probably have attended our coachmeet. My colleague Daisy Pilbrow initiated this weekly “helpdesk” session with this format (copied from the meeting invite):

1. 5 min (timeboxed) – Identify topics (could be a sharing or a question or something we should sync about)
2. We pick one randomly and discuss it (no dot voting)
3. The person who wrote the note chooses when we’re done (could be the whole hour or just five minutes)
4. If time allows, we pick another topic randomly and discuss it.

A nice opt-in meeting where you can get help, bounce ideas or raise awareness about what’s happening in your part of the company world.

Preparing our Chicago talk

My colleague Anders Ivarsson and I have been invited to speak at the Lean Kanban North America conference in Chicago, April 28th to May 3rd. We will talk about how Spotify is actively working on staying lean and agile while growing fast. We have done similar presentations in the past but we want to develop it further and tailor it for this particular conference. Since Anders just swapped places with one of our NYC coaches for about three months we have to meet over Skype in the afternoon. Running distributed meetings via video conferencing like this is a pretty common challenge at Spotify. A lot of meetings need to happen after 15:00 (3 pm) so that NYC is awake and can participate, but before 17:00 (5 pm) or sometimes sooner because of people in Sweden who need to pick up kids or get home to their families in time for dinner. Getting the tech to work is unfortunately, 2013, not yet trouble-free.

Luckily for us, one-on-one video conferencing over Skype is pretty smooth, so we manage to come up with a few ideas on how to improve the presentation. After the meeting I summarized our thoughts in an e-mail to the conference track chair before leaving the office to go home to my family.

What am I doing alerts

One more thing. During the day my iPhone has been beeping now and then, reminding me to fill out a Google spreadsheet answering the following questions.

• Where are you?
• Who are you with?
• Emotional mood?
• What are you doing?
• Are you having fun?
• Are you providing value?
• Are you proactive or reactive?

This is an initiative by my colleague Jimmy Janlén and several coaches are doing the same thing. It’s an adaptation of the “are you in flow” exercise suggested by Daniel Pink in his book Drive and the idea is to get data and reflect on what we are actually doing and if it is the same as we should, or want to, be doing.

• Agile Coach at Spotify – Monday
• Agile Coach at Spotify – Tuesday
• Agile Coach at Spotify – Wednesday
• Agile Coach at Spotify – Thursday
• Agile Coach at Spotify – Friday (not published yet)

From Scrum Master to Agile Coach

When I joined Spotify in August 2011, my position was called “Scrum Master”. The job ad was pretty similar, if not identical, to what we now have published on our web site for the agile coach position. Except for “Agile Coach” instead of “Scrum Master” of course.

The Agile Coach role at Spotify is all about coaching and enabling the Development Teams. We are building an environment where continuous improvement of the development process is in focus and where everyone’s common goal is to deliver outstanding software as fast as possible while having fun.

As an Agile Coach at Spotify you are passionate about communication, group dynamics and coaching and you are not afraid to raise issues and drive change to remove impediments from your team. You’ll be working with a world-class team of engineers who love what they do – and we expect no less from you.

You should have an insatiable appetite for learning new things and improving existing ones. If you’re the right one for us, you pay attention to details and take great pride in your work.

What attracted me with this description and with the actual work I’m doing now (yes, they match!), is the mix of coaching teams and driving organizational change, honing my coaching and people skills and working as a mentor and change agent. Also, having worked as an “lean-agile expert” consultant with several (although not exclusively) short-term engagements, I longed for the opportunity of a long-term approach backed by strong management support for agile, lean and continuous improvement.

I was hired as the third Scrum Master/Agile Coach and at the time we had about 15-20 teams or so. Several of the teams were screaming for help with working more effectively together and we tried our best to help them. After a not so successful every-team-should-work-with-Scrum-and-do-exactly-like-it-says-in-the-book approach, the CTO had spearheaded an organizational design where autonomy was a, if not the, key principle and where the teams were considered “mini-startups” and Spotify an incubator for these. An important part of this autonomy was for each team to come up with a process that fit their specific context and their current needs.

While the de facto standard still was Scrum, several teams made adjustments to the text book approach and some of them experimented with what could better be described as kanban style processes. Our work as agile coaches was to assist the teams, through coaching and mentoring, in discovering improved ways of collaborating and developing into gelled high performing teams.

At the same time we, the agile coaches, studied Lyssa Adkins’s brilliant “Coaching Agile Teams” in our book club and we liked her distinction between a Scrum Master and an Agile Coach. Lyssa describes a Scrum Master as someone who “gets a team up and running with Scrum practices and agile principles”. An agile coach is:

• Someone who appreciates the depths of agile practices and principles and can help teams appreciate them, too

• Someone who has faced the big dragons, organizational impediments, and has become a coach to managers and other outsiders in the course of addressing them

• Someone who can help management at all levels of the organization to understand the benefits of working agile

• Someone who has brought the ideas from professional facilitation, coaching, conflict management, meditation, theater, and more, to help the team become a high-performance team – the way you always imagined a high-performance team could be when you allowed yourself to dream

Adding this influence, that matched what we were actually doing, to the fact that we were no longer (if ever) a “Scrum shop”, we decided to change the title of our roles to Agile Coach.

Team focus

So we don’t have Scrum Masters at Spotify anymore, but as a rule of thumb an agile coach is considered member of two teams that he or she is working with indefinitely. If the teams are new to agile practices and principles the coach will typically teach and facilitate stand-ups, planning and estimation, retrospectives, and so on, but pretty soon a lot of this will be handed over to the team members. Much like a Scrum Master, although usually not through teaching (or “implementing”) text book Scrum, but rather through helping the team decide what they need to improve and which practices to try out.

It is common for the coach to have regular coaching sessions with the individual team members, including the Product Owner, to help them on their agile journey, something that often goes on for a long time. By spending a lot of time with the teams we hope to grow a continuous improvement culture and to act as catalysts to speed up the team’s development into a high performing team.

Other agile coaches that we meet, at conferences and community events or in our recruitment process, are sometimes surprised by the amount of time we spend with the same team. They are used to go from team to team, perhaps even from organization to organization, to train teams, managers, Scrum Masters and product owners (rarely team members, at least not individually, it seems), maybe drive a change initiative or two, and then move on.

There are many reasons for our strong focus on teams at Spotify, probably at least as many reasons as there are coaches, but here’s a few of the ones I think are most important:

• In a world of autonomous squads a lot more work and decisions are being done in the teams compared to companies with more hierarchy.
• We have hired agile coaches who have experienced the power of high-performing teams first hand and who knows how effective they can be. We’re not content with average performing teams, we want to be pushing the limits.
• Spotify’s management knows this too and understands the importance of agile and coaching, that is, we have management support and we are not under staffed. Well, if my managers read this – we could always use a few more agile coaches of course! :)
• We grow fast. Extremely fast at times. 10x in the last 3 years. This means that even if we try to keep stable teams, new members are coming in all the time, teams are splitting into new teams, the organization changes, and so on, so we need to put in a lot of work to keep the teams performing in this fast-changing environment.

What’s next?

As with everything else at Spotify, the agile coach role is constantly evolving and changing. Back when I joined Spotify and we were only three coaches in one site, we were a small team working closely together to define our role and to decide what to look for in a new recruit. Today we are 15-20 coaches, working in three different sites and in several different departments (or “tribes” as we call them). With our emphasis on autonomy and independence there’s no wonder that the agile coach role is starting to look more and more different from tribe to tribe and from coach to coach. We are constantly experimenting with different approaches, trying different things with different teams. To share our experience and get some alignment, or at least a shared understanding of what our job is all about, we meet regularly to discuss what is happening and capture and develop the different aspects of our role.

One such meeting, a full day off-site, took place a few weeks ago at Yasuragi in Stockholm. In one of the Open Space(-ish) sessions some of the coaches produced this description of the agile coach role, beautifully illustrated by colleague Jimmy Janlén (and vectorized by Martin Wasielewski), which I guess represents our most current understanding of the topic.

At the moment we are experimenting with rating ourselves in the different areas of this poster, to understand where we want to improve, who can help us improve, and how and where to apply ourselves to be most effective in improving Spotify. But that’s a topic for another blog post.

This post has just scratched the surface of what the agile coach role is and I hope to further elaborate in future blog posts, starting with a series of daily posts describing the day-to-day work of one agile coach at Spotify – yours truly. If there’s anything else you want to know about agile coaching at Spotify or if you have something to share on the topic of the agile coach role, feel free to use the comments below.

In a few years Spotify has grown from a small startup in Sweden to a pretty big company with more than 30 engineering teams in four different development offices on two different continents. And we have no intention of slowing down. Such rapid growth carries big challenges. How can we continue to improve our product at great speed, while growing the numbers of users, employees and supported platforms and devices? How do we stay agile when we grow from a small startup to a big corporation? In this talk we will present how Spotify is addressing these challenges. We will talk about autonomous squads, tribes, retrospective gatherings, hack weeks, system owner days, and a lot of other ideas we’re experimenting with.

http://labs.spotify.com/2013/03/20/agile-a-la-spotify/

http://labs.spotify.com/2013/02/15/organizing-a-hack-week/

Please let me know if you find them useful or if you have advice on effective meetings.

Effective meetings guidelines

A short summary of the most important things:

• Only meet if it is really necessary.
• Make sure the meeting has a clear objective. (“By the end of the meeting I want the group to…”)
• Prepare and create an agenda.
• Circulate the agenda, other meeting information and assigned preparations prior to the meeting.
• Start and end the meeting on time.
• Capture all the actions and decisions that come up.
• Plan to improve your next meeting.
• Take notes and distribute them as soon as possible.

For more information and advice on each point, keep on reading below.

Do you really need a meeting?

Avoid a meeting if the same information could be covered by a memo or an e-mail. Always ask your self if a meeting is the best way to handle the situation. If you cancel a meeting, please release the room so that others can use it.

Purpose and agenda

Be clear about what the purpose and expected outcome of the meeting is and what the plan to get there is. “By the end of the meeting I want the group to…” There is a number of templates available to help you with this, e.g., the “POAD” template:

Purpose, Objective(s), Agenda, Deliverables. Purpose can be skipped for some meetings.
Example:

• Purpose: Solve the technical challenges migrating X to Hermes
• Objectives: Identify all affected areas, Share understanding of impact within the team
• Agenda:

– Introduction
– Currently identified actions
– Discussion of issue X
– Summarize into stories
– Next steps – book next meeting if required

• Deliverables:

– Understanding in the team
– New stories for the next sprint

Allow for adjustment based on new information that surfaces in the meeting. Use a flip chart or a white board for the agenda to create a focus for the meeting.

Allow for time between meetings by keeping meetings short

For a meeting to start on time, people have to be able to get there in time. That is difficult if meetings are booked back to back. A simple solution to this is to book shorter meetings, e.g., 25 minutes instead of 30 and 50 minutes instead of an hour. There is a “Default meeting length” setting in Google Calendar settings, “Speedy meetings”, that changes the suggested meeting length to accommodate this. This also makes it easier for the next group using the meeting to prepare and start their meeting in time.

Invite the right people

Make sure all who needs to be at the meeting are invited, but also make sure you don’t waste peoples time by inviting them to a meeting they don’t have to be in. Consider if some stake holders would be happy with a summary of the meeting rather than participating. To increase attendance and the chance to get a room, please book well ahead. If you find that you are not learning or contributing to the meeting, feel free to leave the meeting.

Always start and end meetings on time

We should not punish punctual people by not starting meetings in time. Starting meetings on time even though everyone is not there makes it clear to everyone that it is important to be there in time. If calls/texts to latecomers have to be made someone other than the person starting the meeting should do that.

If you are still not able to start on time, don’t let the meeting drag on past its end time – it sends the signal that it is okay to be late but it also makes it difficult for people to get to their next meeting and for the next group using the meeting room.

Prepare the meeting

Distribute the purpose, agenda, and expected outcomes prior to the meeting. Allow people to suggest changes and allow them sufficient time to prepare if preparation is necessary for the meeting. If you are invited to a meeting, please respond in time so that the meeting organizer knows what attendance to expect. Don’t worry about them being spammed by accept/decline notifications – they can be turned off in Google Calendar.

Try to set up video conferencing and projector before meeting – if more people use the effective (shorter) meetings option in Google Calendar this will hopefully give us time to do this. If you find squatters in a room you have booked, don’t be afraid to ask them to leave – and squatters please be prepared to leave rooms you have not booked with short notice.

(We also published an internal step by step guide on how to run a distributed meeting after having run a lot of experiments daily in the agile coach group.)

Plan to improve

Use the last few minutes of recurring meetings as time to review these questions: What worked well in this meeting? What can we do to improve our next meeting? Answers to the second question should be phrased in the form of a suggested action.

Assign Meeting Preparation

If it is a meeting to exchange information, make sure people know what you expect them to bring to the meeting. If you have sent out background information, make sure people know that they have to read it before the meeting. And so on.

Focus on meeting

Show that you value other peoples time by focusing on the meeting. If you feel you have to bring your computer to work while in the meeting, it is often better to decline the invitation or excuse yourself from the meeting and read up on the minutes later.

Capture Actions

At the end of a meeting, go around and review the action steps each person has captured by letting them tell the rest of the group. This breeds accountability and gives you a chance to see that nothing has been forgotten.

Use meetings for multi-directional exchange of information

Do not do serial status reporting meetings where several people working on largely independent initiatives report status to a manager. Use one-on-ones for that.

Send out notes as soon as possible after the meeting

Try to distribute notes within a day of the meeting and keep them short and to the point. This will increase the chance that you get things right, that people actually read them and that they follow-up on captured actions. Send the notes to all participants and also to other interested parties.

[box] How big is “big”? Big projects at Spotify are still pretty small, maybe 25-50 engineers for 3-6 months depending on how you count. More on that in another blog post. You can also read more about our product development process here.[/box]

Background

December 2012 we launched a new web site and introduced a new way of discovering music.

Both these things, as well as a couple of others, were part of the project we now met to retrospect about. All in all it involved about six squads in three different locations (Stockholm, New York, Gothenburg) directly and a number of other squads and departments, such as Operations and PR, indirectly. My colleagues, agile coaches Henrik Kniberg, Martin Wasielewski & Daisy Pilbrow, and Petter Weiderholm from People Operations, all did an ambitious job preparing the retrospective; interviewing key people, collecting data, handling invitations, planning and preparations, organizing a dinner, etc. I have never before been at a big retrospective that felt this well prepared.

A total of about 65 people turned up at the retrospective; several people flew in from New York and engineers, ops people, agile coaches, management (e.g., CTO and VP Product) and product owners all had good representation. The retrospective was held at an off site, lasted a whole day and ended with a really nice dinner.

Opening the retrospective

When we arrived we were met by a greeter who handed out printed agendas and told us to get some breakfast and write our own name tags.

After a while we were ushered in to a big room with two rows of chairs in circles. One of the facilitators placed himself in the centre and opened the retrospective. He started with a short welcome and then he had us empty our minds by writing all the things preoccupying us on an index card and tucking it in a pocket for tomorrow: “today we need you to be 100% present”.

To raise the energy level and to celebrate that we made it through the project, Henrik the facilitator asked us to join together in a big, loud, uninhibited cheer, like if our favorite band was on stage. We did and we probably scared the crap out of the venue staff. Henrik even had to scrap his original plan on requesting an even louder cheer

After a quick round of brief presentations – name, role in project, two word summarizing how we feel being here today (the number one word turned out to be curious, followed by tired) – the agenda was presented:

The Agenda

Part I – The past
Visualize the project
Tell the story
How did the project feel
How successful was the project

Part II – The present
Generate discussion topics
Breakout discussions
Report back

Part III – The future
Output cleanup
Prioritize
Present the message

The last part of the opening was to read the suggested working agreement, item by item, and get agreement through a simple thumb vote.

Part I – The Past

Our Chief Product Officer started by giving his view on the expected project outcomes, everything from increased collaboration between different teams to actual deliverables, and project costs like frustrations, tech debt and alternative costs. He posted them on flip chart sheets and anyone could add their own ones during the day.

You could say that the project actually was four different smaller projects and during the next part of the retrospective we divided into four breakout groups based on these.

Visualize the project

We had all been given a home work assignment before the retrospective to gather artifacts related to the project. Things like important e-mails, early design print-outs and screen dumps of prototypes.We used these and our insights, memories of events, feelings, challenges, and so on, written on stickies to build a timeline on sheets prepared on the wall. After about half an hour we reconvened in the big room and put all the timelines on one wall, running parallel to each other.

Story telling

During the breakout sessions we had appointed storytellers for different periods and they now took turns summarizing and explaining the timelines in front of the whole group.

How did the project feel?

“How did you feel about this project?” These were the questions we were asked to answer through a drawing on a sticky, for example a smiley or a frowney of some kind. We put the stickies on our chests and mingled with the others, discussing our drawings, preferably with someone with a picture that was different from our own. I noticed a couple of drawings of stick figure heads with drops around them, especially from the New York colleagues – maybe they all got wet from Sandy? After the mingle we put the stickies on a matrix indicating our role (dev/qa/manager/product/other) and our project within the project.

How successful was the project?

Next we were asked how successful we felt the project was on a scale from 1 to 10. We put the number on a sticky and next to it wrote one positive thing that pushed the grade up and one negative thing that pushed the grade down. To get a feeling for how the grades were distributed we all lined up in the room with one side of it representing low and the other high. Our facilitators interviewed one of the low, one of the average and one of the high ones, to learn why they voted like they did. We wrapped up by putting the stickies oin order on a wall where we could later browse through them and see what others had written.

Before going to lunch we were encouraged to think about topics we wanted to discuss later and write them down on index cards. We were also handed a lot of “kudo cards” with graphics and titles such as “Awesome”, “Thank you” and “Congratulations” that we could fill out during lunch and hand out to people we wanted to show our appreciation to.

Part II – The Present

Generate discussion topics

The first part of the afternoon was dedicated to the present. We gathered in front of a schedule matrix with time slots and rooms to briefly present the topics prepared during lunch, merge similar ones and find a good slot on the schedule.

Breakout discussions

The goal for each session was to generate insights and recommendations on what to keep doing and what to do differently in the future. The topic originators were encouraged to make sure these things were captured during the sessions. If we bumped into something important that couldn’t be solved here and now, we noted that as a mystery. In an Open Space inspired style we chose what we wanted to attend and were reminded of the law of the two feet: if you feel you’re not learning or contributing, move on. Among the topics were classic difficulties such as how to better overcome the challenges of coordination multiple squads in different time zones and locations, how to involve [insert role/department here] earlier/more frequently and how to improve branching/release management.

Report back

Two 45 minutes sessions later, the insights, recommendations and mysteries that had been captured were presented briefly, 2-3 minutes per session, in front of the whole group.

Part III – The Future

Output cleanup

During the break that followed, the topic presenters gathered and cleaned the output: removed duplicates, made sure notes had clear handwriting and full understandable sentences, and put each note on its own bigger paper to allow for space for dot voting and signing up. All insights were posted in one room, all recommendations in another, and the mysteries in a third room.

Prioritize

After the break we paired up with someone we didn’t know that well, grabbed two sheets of green and black dot stickers and walked through the rooms discussing the notes. If we believed a note to be very important and strongly agreed with the statement, we attached a green dot sticker to it, if we disagreed strongly we attached a black sticker. For the mysteries we could also sign our names for the ones we wanted to solve. Using the dot votes we chose the top five or so for each room and posted them to a flip chart paper.

Present the key messages

Everyone gathered in the big room again where a human billboard presented each flip chart while someone read the notes out loud from him or her. We also had a short discussion about the few notes that had several black dots and several green dots to better understand why people had such different views on these.

Closing

To finally close the retrospective we spent a couple of minutes writing down two things on a card, and then shared it with our neighbor: What is your main take-away from today? What will you do to help these messages stick? One of my main takeaways was the deep consensus on key issues like using real data as early as possible to drive decisions, perform user testing as early as possible, and involving as many different people/roles as possible in coming up with a solution (“how do we cross the water” vs “build a bridge”). A few people shared what they wrote with the entire group, we declared the retrospective done and applauded ourselves for the effort. On our way out we were told to add a mark on a feedback chart: from 1 to 5, how valuable was this day to you in return of time invested? Most of us stayed for a really nice dinner at restaurant Jonas where the discussions and the getting to know each other better continued into the night.

Future improvements

As I’ve already mentioned I was impressed with how well prepared and well executed this retrospective was. There is of course always room for improvement though. These are some of the things I would consider doing differently next time:

• We spent less than 30 minutes on creating the timelines and none, or only a very small amount, of that time was used to prepare the story telling in front of the whole group. The result was a somewhat disorganized and lengthy story telling at times. Next time we should set aside time for preparing, possibly also coaching the story tellers on what is expected and how much time is allotted for this.
• Allow for more space on the timeline to put up the artifacts people had brought.
• During the mingling with post-its during “how did the project feel” I felt that people weren’t really into it. Maybe a bit more structure is needed, such as prepared questions to ask the others or small groups that are changed after half the time.
• When people lined up from 1 to 10 in the “how successful was this project” exercise it was difficult to see the scale and, because of the big group around the average, unclear if people actually were in the right place or just standing where they could find a space. We should clear out the space in front of the wall, have numbers on the wall and have people stand in a long line from that wall. Kind of like a human histogram.
• I know time is a scarce commodity at these kind of events, but I still would have wanted more time for generating topics for the breakout sessions. Everyone should be participating rather than having people come up with topics during lunch and then only having the ones that did convene to build the schedule.
• The output cleanup and choosing the key messages could also benefit from some hands-on coaching. Now at least one of them was at the same time as a coffee break and the people who were “voluntold” to do it of course also wanted to take a break and get some coffee. Have someone bring the coffee and sweets to the cleanup rooms and have a facilitator in each room leading the work maybe?
• While I think really encouraging the law of the two feet to the point that you suggest people do whatever they want during the sessions is a really great idea in a real Open Space, I found that in this context it gave even more permission to “busy people” to choose “real work” like making phone calls, answering e-mails or talking to others about the business as usual. Given the difficulty to get all of these people together for a focused event like this I think it is better to demand focus on the task at hand.
• I was personally involved in the planning before the retrospective, gave feedback on the agenda, ran a pre-retrospective with one of my squads, and so on. I have also run retrospectives like this several times. I knew what to expect. Others did not and they were not sure how to prepare. I think we should share more about the agenda and the expectations before the next big retrospective.

All the good photographs in this blog post were taken by colleague Fredric Sannebro, the others by me.

If there is something you want to know more about, wether it’s about this retrospective or anything else, please add a comment to this post. The same goes if you have feedback on how to improve this post.

The question can of course not be answered categorically. You have to ask yourself what the purpose of your Kanban board is, how the small tasks fit into that and a lot of other questions specific to your own context. However, here are a few of my reasons to consider tracking them in some way.

• Even if the tasks are small, if there is a lot of them the context switching and thrashing will affect your ability to do other work.
• What starts out as a small task can often turn into a bigger task because of unexpected complexity or other problems. “Oh, that’s just a five minutes fix!” Yeah, right…
• Even if the amount of work you are doing is small, you might have to wait for someone else’s input or the task can become blocked for other reasons.
• In my experience, a lot of these small tasks are failure demand, i.e., they are tasks created because we have failed to deliver the actual value in some way. If we can collect data on this and analyze it we might be able to get rid of the root cause of the failure demand and remove it, freeing up resources that instead can be focused on delivering value.

But does this really mean we should track every little task in the same way we track the normal work items? Probably not. Inspired by the excellent TV series “Homicide: Life on the Street”, where a big whiteboard is used to assign ids of unsolved murder cases in one color and then changing them to another color when solved (see my other blog post about this), I came up with an idea that has since proven useful for other teams too.

When a small task enters the workflow, we write down the tracking-id of the task on the board. Some teams have individual columns for team members, others just one for the entire team, whatever makes sense in the context. Once we have finished the task we strike it out on the board. Towards the end of the day we go through the column to see if there are ids that have not been crossed out. If we find one that isn’t finished, then apparently it wasn’t such a small task after all, so we write it on a sticky and put it in the regular workflow annotated with the information needed (blocked, waiting for info etc). And we draw a line under the numbers to indicate that this day is over and the next begins below the line.

After a week or so, we look at the small tasks log and analyze it. What patterns can we see? Is there perhaps a spike in demand Mondays and less towards the end of the week? How could we adjust our capacity based on that knowledge? Could we try to even out the arrival of the tasks? How much of it is failure demand? The same type of failure demand? Could we easily get rid of that demand by changing anything in our process? How many of the presumed small tasks actually turn out to be bigger than anticipated? Is the amount of small tasks so big that it should affect the WIP limit for the team or for individual team members? Maybe we could put a sticky in the usual workflow with an avatar of the team member currently in charge of the small tasks to indicate that she shouldn’t take on so much other work on the week of her being in charge? And put a sticky in the ToDo-list for the person that performs this duty the next week, so that he remembers to finish stuff and don’t take on a new big task towards the end of the week? And so on and so forth, whatever makes sense to the team.

Did you ever watch the great TV series “Homicide: Life on the Street” (“Uppdrag mord” in Swedish)? It’s an American fictional police series about the Baltimore Homicide Unit based on the writing of my all time favorite writer/producer of TV series David Simon (Generation Kill, The Wire, Treme). One integral part of the show was a whiteboard used by the unit. “The Board” was divided into columns — one for each detective—and under each of the detectives’ names, a list of victims, either in red or black depending on the case’s open-or-closed status.

This is how David Simon described the Board:

“In the time that it takes the coffeepot to fill, shift commander Lieutenant Gary D’Addario (Al Giardello in the series) can approach the Board as a pagan priest might approach the temple of the sun god, scan the hieroglyphic scrawl of red and black below his name, and determine who among his [detectives] has kept his commandments and who has gone astray. The board reveals all: Upon its acetate is writ the story of past and present. Who has grown fat on domestic murders witnessed by half a dozen family members; who has starved on a drug assassination in a vacant rowhouse. Who has reaped the bountiful harvest of a murder-suicide complete with a posthumous note of confession; who has tasted the bitter fruit of an unidentified victim, bound and gagged in the trunk of an airport rental car.”

Source: http://thisrecording.com/today/2010/9/29/in-which-it-was-nothing-new-for-david-simon.html

UPDATE

I have invited Benjamin Mitchell to do a talk at Avega Group this Thursday, May 26 16:00 to 20:00, at our office in Sturegallerian. We have a couple of spare seats so if anyone out there wants to come please e-mail me at Gmail or leave a comment below.

Increasing effectiveness and communication with the Mutual Learning Model with Benjamin Mitchell

The Manifesto for Agile Software mentions that it values “individuals and interactions over processes and tools”. Most Agile approaches have very little to say about how to help individuals create interactions that produce effective results. For Agile teams to be effective they need to manage the challenge of learning and adopting new practices, working alongside other teams in organisations and managing stakeholder and customer demands. These situations can create tension as it is often necessary to reconcile groups with different views of the world.

This seminar will introduce a framework for helping individuals, working together in teams, realise their creative and problem-solving potential, especially in challenging delivery-focused situations. The framework is based on the sound theory and over 30 years of research on Organisational Learning from Harvard University Professor Chris Argyris and his associates. It provides a practical approach to helping teams improve the quality of their decisions, increase personal commitment to decisions, whilst reducing implementation time and increasing organizational learning. A central idea of the approach is that our beliefs, values and assumptions guide the behaviours that we choose to use to get effective results. In situations of embarrassment or threat most humans tend to act differently than they would tell others they do. At these moments people adopt the Unilateral Control Model, which leads to reduced effectiveness and is anti-learning. Argyris proposes a more effective set of values and beliefs and associated behaviours referred to as the Mutual Learning Model.

This seminar will use practical exercises to help participants reflect on their own mindsets, before introducing the work of Argyris with reference to the speaker’s experience leading teams as a Project Manager and Agile Coach.

About Benjamin Mitchell
I work with leading software product development organisations to assist them to become more effective at achieving their business goals. I do this through helping senior leaders and teams focus on building and validating what the right products are by understanding customer demand and using iterative development approaches. I accelerate learning in organisations by helping them develop productive communication skills that allow them to make better quality decisions. I have practical real-world experience delivering software projects with exceptional results based on practical, implementable advice. I am a highly-rated international speaker on applying innovative approaches, such as Kanban, to software development. Based in London, I work with clients as a speaker, executive coach or team consultant.