Henrik Kniberg

Henrik Kniberg

I debug, refactor, and optimize IT companies. And jam alot too.

Spotify Engineering Culture (part 2)

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:

(Tools used: Art Rage, Wacom Intuos 5 drawing tablet, and ScreenFlow)

Squad Health Check model – visualizing what to improve

Squad Health Check model

(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 about it together with coach-colleague Kristian Lindwall.

Read it on the Spotify labs blog: Squad Health Check model – visualizing what to improve.

Agile @ Scale (slides from Sony Mobile tech talk)

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:

Visualize and limit WIP

Visual planning

Productivity and motivation



Hello managers, coaches, and other change agents

Here’s the thing. Suppose you introduce a change X to your workplace, and then business improves noticably. That doesn’t mean X caused the business to improve. Well, MAYBE it did. Or perhaps business improved for other reasons, and X was actually detrimental, and business would have improved even more without it. So did things work out well because of the great X, or despite the lousy X? You’ll never know, unless you could rewind the clock and play out the same scenario without X. Correlation doesn’t imply causation.

So people like me who work with organizational change, we are in the business of pseudo-science. We get customer feedback and anecdotal evidence, but we can’t actually prove that we are doing any good, it’s just opinions and observations and guesswork. I think that’s fine, but let’s be honest about it 🙂

What is an Agile Tester? Slides from my Sri Lanka talk.

Here are the slides for my talk What is an agile tester from the Colombo Agile Conference in Sri Lanka.

What is an agile tester

read more »

How do you know that your product works? Slides from my Sri Lanka keynote.

Here are the slides for my keynote How do you know that your product works, from the Colombo Agile Conference in Sri Lanka.

Henrik Kniberg

How do you know that your product works

read more »

Focus – slides from my talk at Projektnäring

Here are the slides for my talk “Focus” at Projektnäring. Great group, lots of energy in the room. Had lots of great conversations with people. Thanks for attending!

Sample pics:

Screen Shot 2014-05-09 at 13.11.23

read more »

Spotify Engineering Culture (part 1)

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 to be mostly true for most squads most of the time :o)

Here’s the whole drawing:


Here’s Part 2.

(Tools used: Art Rage, Wacom Intuos 5 drawing tablet, and ScreenFlow)

Keynote slides from my Passion for Projects keynote

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.

read more »

Dyr lärdom från PUST: hur undvika nya IT-fiaskon?

2010-2011 gjorde RPS en bra grej. De byggde ett system (Pust Java) som gjorde polisen mer effektiv. Poliserna fick datorer i sina bilar och kunde direkt registrera brott. Därmed behövde de inte åka in till stationen för att avrapportera lika ofta som med gamla systemet. Systemet var skräddarsytt för att ge hög användarnytta, och projektet blev en framgång. Pust Java blev finalist i CIO awards “project of the year 2011” och DN skrev en helsida “Polisen rapporterar betydligt snabbare med ny metod“. Systemet var inte perfekt, men en bra start. Poliserna sa att det var bättre än vad de hade innan, och folk var optimistiska inför systemets framtid.

Sedan hände något tragiskt. Istället för att vidareutveckla och kontinuerligt förbättra systemet, så valde ledningen att skapa ett nytt system från grunden (Pust Siebel) med undermålig teknik. Det blev ett fiasko. Ursinniga poliser klagade på att en avrapportering kunde ta flera timmar – “Pust Siebel gör en helt frustrerad och på gränsen till vansinnig!” – och saknade det gamla systemet. RPS hamnade i ett mediadrev. En poliskälla uppskattade samhällskostnaden till 10 miljarder kr!

Efter massiv kritik från både media, poliser, skyddsombudsmän och oberoende aktörer med insyn i projektet, beslutade RPS att lägga ner Pust Siebel.  Nu är det allt fler som förespråkar att Pust Java återinförs

Varför spenderar en myndighet hundratals miljoner på att bygga något bra, för att sedan spendera ytterligare hundratals miljoner på att byta ut det mot något dåligt? Ännu värre: varför gör man detta trots att hela IT-avdelningen visste, och högljutt påpekade från början, att det nya systemet skulle bli sämre?

Syftet med denna artikel är att belysa och sprida lärdomarna, så andra företag och myndigheter slipper göra om liknande dyra misstag.

read more »

How we make decisions

We are 35 people at Crisp now, and we are a decentralized organized with no managers. So how do decisions get made? This article is a direct translation of our internal wiki page “Hur vi tar beslut på Crisp” (how we make decisions at Crisp).

read more »

Acceptance-Test Driven Development from the Trenches

Getting started with ATDD

Have you ever been in this situation?

Then this article is for you – a concrete example of how to get started with acceptance-test driven development on an existing code base. Read on.

How I write (and why)

The purpose of this article is…
Actually, there is no purpose. There never is. I just write because I feel like it. Then I read the article and make up a purpose afterwards, and start eliminating anything in the article that doesn’t fit that purpose. But I won’t do that this time. Read on and you’ll understand why. By the way, this text is blue because it’s my second iteration. Black text is the original, first iteration. Here it is:

Let me tell you about my creative process. Every writer has a creative process. Otherwise they wouldn’t get anything written; well, at least not anything creative 🙂 read more »

Good and Bad Technical Debt (and how TDD helps)

Technical Debt is usually referred to as something Bad. One of my other articles The Solution to Technical Debt certainly implies that, and most other articles and books on the topic are all about how to get rid of technical debt.

But is debt always bad? When can debt be good? How can we use technical debt as tool, and distinguish between Good and Bad debt?

read more »

Culture > Process (Paris Scrum Gathering keynote)

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!

read more »

Agile event @ major swedish bank

Yesterday I spent a very inspiring day with a big swedish bank, doing agile intros with 1200 people. We had developers, designers, testers, C-level execs, project leads, pretty much every role represented. The CEO opened with words about why they are determined to go all-out agile, and we had a speaker from another even bigger company describe their ongoing agile journey and amazing results so far. Very interesting. And best of all – no roadmap or other fake attempts at pretending that we know what the journey is going to look like. It was clear that this is a bumpy ride and that change will have to evolve gradually from bottom as well as from top.

read more »

Elephant Carpaccio facilitation guide

The Elephant Carpaccio exercise is a great way for software people to practice & learn how to break stories into really thin vertical slices. It also leads to interesting discussions about quality and tech practices.

The exercise was invented by Alistair Cockburn. We’ve co-facilitated it a bunch of times and encourage people to run it everywhere.

Here’s a pretty detailed (shu-level) guide showing how to run the exercise.

The Solution to Technical Debt

(related article: Good and Bad Technical Debt – and how TDD helps)
(Translations: Russian)

Are you in a software development team, trying to be agile? Next time the team gets together, ask:

How do we feel about the quality of our code?

Everyone rates it on a scale of 1-5, where 5 means “It’s great, I’m proud of it!” and 1 means “Total crap”. Compare. If you see mostly 4s and 5s, and nothing under 3, then never mind the rest of this article.

If you see great variation, like some 5s and some 1s, then you need to explore this. Are the different ratings for different parts of the code? If so, why is the quality so different? Are the different ratings for the same code? If so, what do the different individuals actually mean by quality?

Most likely, however, you will see a bunch of 2s or worse, and very few 4s and 5s. The term for this is Technical Debt, although for the purpose of this article I’ll simply call it Crappy Code.

Congratulations, you have just revealed a serious problem! You have even quantified it. And it took you only a minute. Anyone can do this, you don’t have to be Agile Coach or Scrum Master. Go ahead, make it crystal clear – graph the results on a whiteboard, put it up on the wall. Visualizing a problem is a big step towards solving it!

Don’t worry, you aren’t alone, this is a very common problem. <rant>However, it’s also a very stupid, unnecessary problem so I’m baffled by why it is so common.</rant>

Now you need to ask yourselves some tough questions.

read more »

How to run an internal unconference

An unconference is like a normal conference but with no predefined agenda, no predefined list of speakers, no slides, and…er… actually it’s not very much like a normal conference at all! It’s more like an alternative to a conference. If the purpose of a conference is to collaborate and communicate, then an unconference will often fulfill the same purpose in a more simple, fun, and effective way!

There’s lots of ways of running unconferences. I’ve written a short book (or long article) about one specific format that I’ve been experimenting with over the past 5 years, mostly at companies like Crisp and Spotify.

By now it is well tested and works especially well for 1-2 day internal conferences with 20-80 participants. In fact, participants often say things like “all conferences should be like this!” or “best conference I’ve ever been to!”. Even the most rabid meeting-haters seem to like (or at least not hate…) this collaboration format 🙂

  • Slides (from my Agile Evening presentation on how to run an unconference)
  • Minibook (LeanPub – work in progress)

June 17-18: Advanced Agile with Alistair & Henrik

Good news: Alistair Cockburn is in Stockholm June 17-18! We’ll be teaching Advanced Agile, a workshop for those of you who already have agile training and experience, and want to dig deeper!

Register here if you are interested.

Alistair is a very inspiring fellow! He wrote the original book Agile Software Development and was one of the people who started the whole agile movement. He has also written books about Use Cases and agile requirements. Alistair has a great knack for balancing theoretical depth with practical real-life examples and a dose of humor.

Stop Starting, Start Finishing – slides from Aggro Pekuliar

Hi! Here are my slides Stop Starting, Start Finishing from Aggro Pekuliar. Thanks for attending! And what a cool conference, nice to hang out with a bunch of non-techies for a change 🙂

Crisp DNA spreads to New Zealand!

Sometimes people approach us at Crisp, and ask if we would consider starting a subsiduary in country X or Y.

We normally respond with something like “Sounds cool! But we are a Stockholm company and don’t want the hassle of running a multinational corporation, not unless we see a clear and strong benefit (and we haven’t so far). But if you like our model, feel free to just go ahead and start up a Crisp-like company in your city. Here is how we work, copy & adapt as you like, there is no reason for our two companies to be statically and legally linked together. We’re just happy to see the ideas spread.”

About a year ago Sandy Mamoli came from a long way (New Zealand) and visited the Crisp office to discuss our model. Actually,we’ve bumped into each other at a number of conferences around the world, sharing ideas discussing different ways of running consulting organizations.

Now she’s gone ahead and done it: started a company based on the Crisp model. Way cool! Looking forward to seeing how it works out, and maybe stealing some ideas back as they evolve our concept 🙂

Check it out:

Stop Starting, Start Finishing! My slides on how to improve your life.

Here are the slides from my keynote Stop Starting, Start Finishing, from the LeanKanban Nordic conference.

Thanks for the great response! It seems like this was exactly the type of stuff people needed to hear! Some of the most tweeted quotes from the presentation:

  • “Organizations with slack are faster than organizations where the goal is to keep people busy all the time.”
  • “Those who can’t say no to anything, are those who burn-out and must say no to everything”
  • “Time is free! You get 24hrs per day!”
  • “I wanted a long term client because then I can see the consequences of the bad advice I’m giving” (hmmm…. maybe I shouldn’t have said that… lol)
  • This tweet warmed my heart: “@henrikkniberg has totally done it for me today. I need to change my life! 🙂 #sssf13”

Below are some sample slides. I had a lot of fun drawing the pics for this presentation! Thanks for giving me an excuse to waste spend time on that 🙂

Oh, and before you ask. I used ArtRage (software) and Intuos5 (drawing tablet).

read more »

Agile India slides

Agile India 2013 in Bangalore. Wow, what an awesome conference! I was amazed by the energy level of the participants, spent hours talking to people about all kinds of really interesting challenges. Based on the fully packed rooms and incredible feedback, it seems like my talks were exactly the kind of information people were looking for. Feels great to be able to help!

I also managed to squeeze in a site visit to a local development center, and discuss their agile implementation. Always fun to jump into trenches and see what is going on out there.

Anyway here are the slides from my presentations:

Thanks for a great time everyone!

Experiment: Do kids really want school?

Over lunch, the kids were griping a bit about how the winter vacation is too short, and how it should be MUCH longer! The vacation should be several weeks, or months, or even years! Imagine that!

So Mr Evil Coach Dad decided to try an idea on them 🙂

read more »

How to build the Right Thing

The software industry is going through a shift of mindset.

Agile basically solved the problem of how to deliver software. Most any company that applies an agile method and mindset can get working software out the door. Now, the biggest waste in software development seems to be building the wrong product, or the wrong features.

“There is surely nothing quite so useless as doing with great efficiency that which should not be done at all” -Peter Drucker

This insight has given rise to methods and techniques such as Lean Startup, Impact Mapping, Story Mapping, Feature Injection, etc. But is there a common denominator, a set of underlying principles?

On Feb 11, Gojko Adzic organized a full-day meetup in London with people deeply engaged in this issue, people like Jeff Patton, Mary Poppendieck, Ingrid Domingues, Chris Matts and others who have been inventing and spreading techniques for dealing with the how-to-build-the-right-stuff issue.

It was a very inspiring day! We compared our different approaches and experiences, extracted the core principles, and (to our surprise) managed to condense it into this shared message:

Great results happen when:
1. People know why they are doing their work.
2. Organizations focus on outcomes and impacts rather than features.
3. Teams decide what to do next based on immediate and direct feedback from the use of their work.
4. Everyone cares.

There. So now just go do it! 🙂
Actually, if you want a more detailed description of each point see Gojko’s post.

Posts from the other participants:

Full participant list (in no particular order): Gojko Adzic, Mary Poppendieck, Gabrielle Benefield, Tom Poppendieck, Gordon Weir, Henrik Kniberg, Jeff Patton, Ingrid Domingues, Karl Scotland, Russ Miles, Christian Hassa, Dulce Goncalves, Aaron Sanders, Shadi Almviken, Chris Matts, Olaf Lewitz and Matthias Edinger.

read more »

Scaling Agile @ Spotify (JFokus slides)

Here are the slides from the Jfokus talk that Anders Ivarsson and I did on Scaling Agile @ Spotify.

How to run a Big Retrospective

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:

  • Insights (“what did we learn?”)
  • Recommendations (“what should we do the same in the future, what should we do differently, and why?”)
  • Mysteries (“which questions and problems need further investigation?”)

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 🙂

Lean Mindset with Mary Poppendieck, Feb 7-8

On Feb 7-8 Tom & Mary Poppendieck will be in Stockholm, we are running a workshop called “Lean Mindset“. Mary and Tom are only here 1-2 times per year, so this a good opportunity!

The workshop emphasizes research, case studies and exercises. You will learn what a lean mindset is, how other companies have exposed and resolved paradoxes, and how this has helped them compete more effectively in today’s fast moving marketplace.

There are still a few spots left, more info and registration here.

Join us!

How Spotify builds products

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

read more »