If you are running some kind of big room planning pulse, the preparation you put inis half the success. The last thing you want to do is to round up 10 senior team members and turn up with a feature described solely by a one-liner “next gen product”. Scenario Before I go into details of

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

In this blog post I want to share a powerful tool, the Leadership Health Check. It will help you become stronger as a management team and reveal improvement opportunities for how you, as a team of active servant leaders, better can enable the agile teams you support.

But first, let’s take it from the beginning.

One of my favourite exercises in my toolbox as an agile coach is something I learned during my years at Spotify; the Squad Health Check. It’s a retrospectives format, a self-evaluation workshop, in which the teams express how they feel they’re doing on wide variety of topics such as collaboration, value of what is delivered, ability to influence, received organizational support, etc. The result generates insights and commitment to actions of improvement for both the team and the supporting leadership. I love it because I believe it’s a great tool for strengthening autonomy, culture and continuous learning.

More than a year ago, a colleague at Spotify Georgiana Laura Levinta and I created a health check for the leadership of our Tribe (Tribe is a semi-autonomous department at Spotify encapsulating 4-8 teams and with a dedicated set of leaders and managers). Geo and I were inspired by the Squad Health Check, but the goal with this adoptation was to help the Tribe’s managers perform a self-evaluation of their ability to provide active supportive leadership to the squads within the tribe, and to generate a discussion on how they can improve as a team to be able to provide even better support.

Since then, I have together with my current client Casumo, adopted this for their context, culture and beliefs. We’ve run it several times with great success and value, both with the company’s leadership team but also on cluster level (semi-autonomous department). I believe the Team Health Check and the Leadership Health Check both are tremendously powerful; hence I want to unleash them to the wider agile community, hoping that more organizations will find them valuable and useful. Or at least be inspired by them, and then try something totally different.

Continue reading

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

Adapting to accelerating change

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.

Continue reading

Don’t stand in the way of great employees.
That’s one of the operational mantras that guide the finance technology company iZettle.
Two others are “Keep the startup spirit strong” and “Stay adaptable to changing market needs.”
In this blog post, we share some of the things we are implementing and tweaking at iZettle to keep producing great results and attracting in-demand, talented developers. My role has been to assist the tech development organization in making this work.
(Another blog post coming soon will cover the transformation of making the whole company agile, while this post focus on the practices that are put in place to keep a high performing, decentralized tech development organization at iZettle.)
Let’s begin by facing the reality of fast-growing startups.

The organizational challenges for most fast-growing startups
Most startups want a flat organization to keep their entrepreneurial juices flowing, but when new employees join in a steady stream there eventually comes the point where the founders or upper management feel overwhelmed by chaos.
Things get confusing.
Employees aren’t seen.
No one seems to know what’s going on.
What usually happens for most start-ups at this point is that bureaucracy processes start piling up. Layers of management are added, and project managers are introduced to coordinate the chaotic environment. And so are written reports for managers to send to upper management, and silos are building up between different departments. And decisions are taken somewhere else.
And then what happens?
Usually, entrepreneurial enthusiasm suffers and so does talent motivation and speed of innovation.
And that is exactly what iZettle wants to prevent.
But that is easier said than done when a company grows like a wildfire.

Continue reading

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.Continue reading

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 🙂

Continue reading

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

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

Here are the slides from my talk about Spotify Rhythm at Agila Sverige.

The talk is about Spotify’s current approach to getting aligned as a company. It covers:

• what problem we’re trying to solve, and how we’ve gone through two other models (OKR and Priorities & Achievements) before arriving at our current model
• how we define “Bets” using the DIBB framework (Data-Insight-Belief-Bet)
• how we prioritize bets using stack-ranking based on company beliefs and north star goals
• how we visualize bets on a kanban-like company level board, and group them into Now – Next – Later columns
• how different parts of the company visualize their own bets and align with higher level bets, using interlinked bet boards.
• how we synchronize and prioritize our work using different cadences at different levels of the company.
• how this model is used to support squad autonomy
• our challenges and learnings with this so far

Holy crap how did I manage to cover all that in 10 minutes?! Guess I talked fast 🙂

Some sample slides below.

Continue reading

UPDATE Dec 2016: Wrote an article about LEGO’s agile journey, see here. Includes all of the material below, plus explanations and updates.

Here are the slides for our talk Agile @ Lego at Passion for Projects in Uppsala. Enjoyed discussing this stuff with project managers and the like from all sorts of industries. A common theme from the conference was the power of self-organization, and the role of leadership in creating the right context for self-organization to happen. Our talk provided a real-life large scale example of this.

Continue reading

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.

Continue reading

Here are the slides from my keynote “Real-life agile scaling” at Agile Tour Bangkok. Enjoyed hanging out with everyone!

Key points:

• Scaling hurts. Keep things as small as possible.
• Agile is a means, not a goal. Don’t go Agile Jihad. Don’t dump old practices that work.
• There is no “right” or “wrong” way. Just tradeoffs.
• There is no one-size-fits-all. But plenty of good practices.
• Build feedback loops at all levels. Gives you better products and a self-improving organization.

Here is an InfoQ article with a nice summary of the keynote.

Sample slides:

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 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.

Continue reading

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.

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

(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

Here are the slides for my talk “Lean from the Trenches” at Øredev, Malmö. And here is the book/ebook, in case you want more details. There may also be some copies left at the conference bookstore. Thanks for attending!

Here are the slides for my keynote “Lean from the Trenches” at Agile Eastern Europe, Kiev. And here is the book/ebook, in case you want more details. Thanks for attending!

When I have worked with scaling Scrum over several teams (up to 10 in parallell), I have 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

• Can they easily detect something needs attention? (Good at Looking Around)
• Will they care enough to do something about it? (Pride-in-work; Amicability)
• Can they effectively pass along the information?  (Proximity; face-to-face)