How to successfully drive initiatives, objectives or opportunities that require several squads (or teams) to succeed? How to do this in a way that respects the agile mindset without falling into the command-and-control trap? Today, this problem is more complex than it seems. We’ve designed and built our squads for self-organization and autonomy in the

Here are my slides from today’s talk “Scaling Agile @ LEGO and Spotify” at EA träff in Stockholm (EA = enterprise architecture). Fun to hang out with enterprise architects and learn what that’s all about 🙂

Some sample slides from my talk:

Continue reading

Here are the slides from my Agile Africa keynote Alignment at Scale (or How to Not become Totally Unagile when you have Lots of Teams). Thanks for a great conference!

And thanks everyone for the Emma greeting, that sure made an 8 year girl very happy 🙂

(Emma was supposed to join me on this trip, but couldn’t make it because I had missed some required paperwork for travelling with minors to South Africa).

Continue reading

The Spotify ‘model’ was presented in 2012 and has stired a lot of interest in the agile community and the software industry in general. In May I was asked to talk about this a the Bay Area Agile Leadership Network meetup in San Francisco (where I at that time was working as an agile coach

Help your team improve by visualizing their way working with the fluent@agile game. With the game you can help a team find out where it is on its agile journey and help it find new ways of both fine tuning and make leaps in their daily agile practices.

Me and Christian Vikström made the game together at Spotify during the spring 2014 when we were coaching and helping team to improve their agile skill sets and processes.

At Spotify the teams owns their own way of working. A team is basically only accountable to itself. We therefore needed an coaching tool that could help team take ownership of their self image and improvement strategy.

We also wanted the tool to be opinionated. It should be normative, tell what’s good and not, what kind of practices and behaviour that’s expected and not. But at the same time it should be open to new ideas, new practices and the teams local conditions.

Continue reading

You know the saying “don’t shoot the messenger”? Well, that goes both ways – “don’t praise the messenger”. Well, OK, you can shoot or praise the messenger for the quality of the delivery – but not for the message content!

I’ve spent a few years working with Spotify and published a few things that have gained a surprizing amount of attention – especially the scaling agile article and spotify engineering culture video. This has come to be known as the “Spotify Model” in the agile world, although it wasn’t actually intended to be a generic framework or “model” at all. it’s just an example of how one company works. The reason why I shared this material is because my Spotify colleagues encouraged me to, and because, well, that’s what I do – help companies improve, by learning stuff and spreading knowledge.

Continue reading

Here’s part 2 of the short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog). Check out part 1 first if you haven’t already seen it! This is a journey in progress, not a journey completed, so the video is somewhere between “How Things Are Today” and “How We Want Things To Be”. Here’s the whole drawing:

One of my biggest surprises when I first met the squads I where going to work with at Spotify was that none of them were using User Stories. At first I observed to see their alternative. Unfortunately there was none. Instead most of the work got done as big chunks of work (what I would tend to call Epics) that was sliced into a todo-list of tasks (named that way by the developers) and also divided according different platforms.

Squad focus on technical tasks

A typical board contained one or more business cases and lanes for each developer/platform with tasks that were executed upon. These big “busses” where on the board blocking other works for weeks, which of course meant there needed to exist one or more emergency lanes for all expedite work (in the long run, most work).

This is a setup that does not foster collaboration, focus on value and art-of-the-possible. From an agile fluence point of view I would say it is a way of working that does not even reach fluence level 1 (Christian and I will describe agile fluence in more depth in a follow up blog post). From my experience focusing on User Stories is a great way of fostering the above values, and reach fluence level 1.

Continue reading

(Download the cards & instructions as PDF or PPTX) At Spotify we’ve been experimenting a lot with various ways of visualizing the “health” of a squad, in order to help them improve and find systemic patterns across a tribe. Since a lot of people have been asking me about this, I wrote up an article

As so many others I’m inspired by the book Lean Startup. The idea of experimenting with your business model and deliver just the bare stuff needed to validate (or actually try to refute) your business hypothesis is so enticing. But how do you do that when you are one of 50 or 100 teams? How do you do that when the teams are not even using User Stories? How do you do that when daily work is done on a Kanban board only showing tasks?

One part of a possible solution is to find a way of visualizing the business case. A popular approach has become setting up a business board, often called a Lean Canvas. I wanted to try something like that. But going trough all the different variants I could find, no one was good enough in itself. I wanted to get the same feeling as with User Stories: a simple formula that everyone can understand and use as soon as the formula is presented.

Continue reading

Last week i quit my assignment at Spotify. I was there to help and act as a stand-in for Joakim Sundén while he was on paternity leave. He’s now back in the saddle as Agile Coach in the More Than Music Tribe.  I had the pleasure to work closely with the Agile Coach Christian Vikström on Spotify and together we have been coaching the Browse, Growth and Customer Support squads. A was also a member of the tribe management team, and together we did some new interesting stuff.

It’s has been fascinating and fantastic to work with such dedicated people and a product that has such a traction. Spotify is also really trying to build an awesome and agile organization and culture that can win and sustain in the long run. What is there to do at such a fantastic company? That’s a reasonable question. A lot I discovered. Spotify is shock full of super smart people, but many of them has not worked there for long, many of them has not worked long at all, teams have been newly formed and are under constant change. Simply put: even Spotify needs a lot of basic agile coaching.

When I now look back at what we did during these last 8 month I see a lot of tools and experiences that I think others also can find useful. During the next couple of month I will share them through this blog. Hope you will find them useful. Here’s the planned list:

Continue reading

Here’s a short animated video describing Spotify’s engineering culture (also posted on Spotify’s blog). See also Part 2. This is a journey in progress, not a journey completed, and there’s a lot of variation from squad to squad. So the stuff in the video isn’t all true for all squads all the time, but it appears

Here are the slides for my Passion for Projects keynote Spotify – the unproject culture (+ failure story “How to burn €1 billion”).

So, now I’ve spent 2 days with 600 projects managers at a PMI conference. Totally different from the usual crowds I hang out with. Fascinating to hear stories about project management successes and failures in all kinds of industries – from warzone reconstruction projects to eurovision song contest.

Continue reading

Here are the slides for my keynote “Culture > Process” at the Paris Scrum Gathering. Amazing level of enthusiasm in the room, seems like this kind of stuff was exacty what people were looking for. Happy to see the ideas take such strong hold!

• Video recording part 1 (starts at 0:30)
• Video recording part 2

Continue reading

At Spotify we recently did full-day retrospective with 65 people. The goal was to capture learnings from a large coordinated effort involving dozens of teams for over half a year. The teams had been doing sprint retrospectives during the project, but we also felt the need to get a larger group together and look at

Product development isn’t easy. In fact, most product development efforts fail, and the most common reason for failure is building the wrong product.

Spotify is a Swedish lean startup with an awesome track record of product delivery. The products are designed to be easy, personal, and fun. Even Metallica, long known as die-hard opponents to music streaming services, now say that Spotify is “by far the best streaming service” and are “stunned by the ease of it”.

Here’s the paradox though: Successful companies like Spotify only want to deliver products that people love. But they don’t know if people love it until they’ve delivered it. So how do they do it?

Check out the article “How Spotify Builds Products”

Continue reading

(UPDATE: see Spotify Engineering Culture, two short animated videos showing how we work)

Dealing with multiple teams in a product development organization is always a challenge!

One of the most impressive examples I’ve seen so far is Spotify. I’ve had the pleasure of working with Spotify on and off ever since the company was founded, and it’s one of the few companies I’ve seen with a truly agile culture. Spotify has grown a lot lately and now has hundreds of developers divided into 30 agile teams spread over 4 cities in 3 timezones. So how is this managed?

Check out the article: Scaling Agile @ Spotify with Tribes, Squads, Chapters and Guilds. I wrote it together with Anders Ivarsson, one of the agile coaches that I’m working with (Spotify has a truly awesome group of coaches!).

Continue reading