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:
In a world where the speed of change seems to accelerate almost exponentially, it is only natural that an organization’s way of working must be constantly challenged and improved – especially in the highly competitive media business.
This text, which was inspired by winning an award (we will return to that), is the outcome of a joint effort between Michael Göthe, Agile Coach at Crisp, and Jens Abrahamsson, Agile Coach at Telia Company’s TV & Media Backend department. In it, we describe parts of the always-ongoing journey towards a more lean and agile way of working at the Telia TV team.
As always when looking back at a complex change process it is not possible to copy what we did but our intention is to share useful learnings, practices, and tools that can inspire you on your change journey, in your context.
A common pitfall for large and medium size organizations who are adopting Agile is to organize teams based on software component boundaries instead of feature teams. Some of the aspects of long term code ownership are more straightforward this way, but the negative consequences in terms of business agility and costs of coordination are huge. A few years back I designed a simulation exercise that I call Team Shapes which illustrates some of the issues and now I would like to share this simulation with the community. read more
I recently published a video exploring how an agile team based organization could look like. How does it function under the hood? In the video I also discussed how you get there.
I got tons of great feedback so I decided to provide the contents of the video in the format of a blog. If you prefer to read instead of watching a 11-minute-long video, then this is for you 🙂
The past couple of years I’ve been travelling back and forth to LEGO’s HQ in Billund Denmark, helping out with their agile journey. Super interesting! Learned more than we could ever fit in an article, but here’s an attempt to capture at least some of it, written together with LEGO colleague and co-instigator Eik Thyrsted Brandsgård. Enjoy!
Planning as a social event – scaling agile @ LEGO
Translations:
For more than a year now, I’ve been working with clients that have agile scaling problems. But not the kind of scaling problem everybody is talking about – one product and lots of teams. No, I’ve been busy trying to sort out what to do when you have one team supporting a multitude of products with different architectures, stakeholders, technology stacks and whatnot. This is what I’ve learnt, so far.
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.
Here are the slides from my tech talk Agile @ Scale at Sony Mobile. Full house & very high level of engagement, I was impressed by this crowd! And thanks for the awesome recommendation on LinkedIn 🙂
Some sample pics below:
Crisp has the luxury of working with small, medium, big and very big companies. We help through providing education. We coach and mentor projects, teams and organizations adopt and master the agile way of working. Last week we at Crisp invited a couple of our clients to participate in a round table discussion regarding agile transformations. The unifying theme were the challenges surrounding large scale agile implementations.
We at Crisp offered a platform and forum to share and learn in a neutral and safe environment. Four companies attended. One to four participants from each company. The participants were directly involved, and in one way or the other, responsible for the agile transformation taking place in their respective company. The size of the department or company involved in the change varied from 300 – 1500 people.
A cross-functional team I was working with last year had three testers offshore in India. The rest of the team (about 15 people) was co-located here in Stockholm.
Some team members had a nagging feeling that they could go so much faster if the testers also moved to Stockholm so they went to their boss and asked. The reply was that testers are so much less expensive, by a factor 2.3, so it was not possible, unless they could settle with fewer testers.
So they decided to do an experiment for a few months. They moved one of the testers from India to Stockholm and dropped the other two testers (re-allocating the other two to other teams) to see how that would work.
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 the big picture. The key output was 3 lists:
Organizing this was a lot of work, probably one of the toughest gigs I’ve been involved in, due to the number of people involved and the complexity of the project. I’ve run full-day retrospectives before, following a similar format as this, but with only half as many people. I’ve also run larger events with 100-200 people, but “unconference” style with no specific output expected. This event was more demanding, since we had lots of people in the room and expected concrete, actionable output. Norm Kerth’s classic on Project Retrospectives provided lots of useful ideas on how to do this..
All in all it worked out well, and we learned lots (both about the project, and about how to run an event like this).
Joakim Sundén, one of my coach colleagues at Spotify, participated in the retrospective and wrote an excellent blog post about what we did, and also listed some ideas on how we can do retrospectives like this even better in the future. Here is Joakim’s article Running big retrospectives at Spotify. PS – Joakim is the guy with the green shirt below 🙂
(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!).
When I have scaled Scrum over several teams (up to 10 in parallell), I have simply strived to strengthen the same processes that gives traction to a single team.
Alistair Cockburn compiles this beautifully in his Software engineering in 21:st century
People issues determining a projects speed