Skip to content

Henrik Kniberg's blog
Syndicate content
from the Crisp Consultants
Updated: 12 min 40 sec ago

What is Scrum? (slides from my talk at KTH)

Wed, 10/08/2014 - 10:10

Here are the slides for my talk “What is Scrum?” at KTH (Royal Institute of Technology). It was a guest talk at a course called Projektstyrning. Hoping to inspire young entrepreneurs to plant agile DNA in their companies from the very beginning. Last time I spoke at KTH was 6.5 years ago, that’s when I met the first Spotify team, and I’m really happy to have been able to influence and participate in their journey!

Here are some sample slides from the talk:

What is Scrum? Screen Shot 2014-10-07 at 08.20.00 Don't go overboard with agile

Categories: Blogs

WIP and Priorities – how to get fast and focused!

Thu, 09/25/2014 - 12:23

Many common organizational problems can be traced down to management of Priorities and WIP (work in progress). Doing this well at all levels in an organization can make a huge difference! I’ve experimented quite a lot with this, here are some practical guidelines:

WIP = Work In Progress = stuff that we have started and not yet finished, stuff that takes up our bandwidth, blocks up resources, etc.. Even things that are blocked or waiting are WIP. Visualize and limit WIP
  • WIP is what it is, regardless of priorities (priorities are what we should be focusing on, WIP is what we are actually doing. They sometimes match…)
  • It’s almost always a good idea to visualize WIP, whether it is at a team level or company level or whatever. Invisible WIP is hard to discuss, hard to challenge, and hard to limit. And hence, invisible WIP tends to grow and slow us down.
  • Make WIP in-your-face-Visible! Ideally on the wall, since people will see it (and hence discuss it) without having to actually find and open a document. If it’s not on the wall, it tends to be ignored or forgotten. Analog visualization (stickynotes etc) usually works best, but showing a digital visualization on a screen works too.
  • Use a “noise threshold” to avoid micromanagement. Avoid cluttering the visualization with hundreds of tiny things. For example, the noise threshold for a team-level visualization could be “if it’s less than 2 hours of work, just do it, don’t bother putting up a sticky”. At a department level the noise threshold could be “things that involve more than one team for more than a week”. Items smaller than that are allowed to “fly under the radar” (which has the added bonus of provided an incentive to break work down into small chunks).
  • If there’s lots of noise, aggregate and visualize the noise (so that it too can be discussed/challenged/limited). For example “# of currently open Jira tickets” instead of displaying each individual ticket.
  • The goal is to visualize all significant WIP that is burdening this team or department or project or whatever, and to do it in a way that doesn’t involve managing hundreds of individual notes on a board.
  • It’s almost always a good idea to define WIP limits. The WIP limit is just “how much stuff can we have in progress before we start getting bogged down with multitasking and coordination overhead”. Start high and gradually reduce it, it’s an awesome way to drive out waste! This is one of the key principles in Kanban.
  • Current WIP will sometimes be higher than the WIP limit! That’s OK. It’s an alerting system. Current WIP is simply our current reality, while WIP limit is our desired reality. Visualizing both makes the problem explicit. As long as we’re over the limit, our main focus is finishing things (or canceling them) and we are super-restrictive about starting new things.

Here’s an interesting study that shows how WIP limits dramatically benefit quality and speed “The Impact of Agile – Quantified

Priorities are something different.

Cascading priorities

  • Priorities are a guidelines to help us decide what new WIP to take on (when our WIP limits allow it), and what things to reject or postpone. Without clear priorites, we risk unaligned autonomy and suboptimization.
  • Priorities also help us resolve resource conflicts within our current WIP (“Joe is needed for both of these tickets, which should he focus on first?” or “Let’s help Team X first, Team Y’s stuff is lower prio”)
  • Priorities should be limited, too! Something like 1-3 items is usually sufficient. Because if everything is important, nothing is important! And if the list is too long, no one will read it or remember it.
  • Priorites can be fluffy ( “our current priorities are 1) repay technical debt, and 2) improve the backoffice UX”.)
  • …. or specific (“our current priorities are 1) Deliver feature X, and 2) Prototype feature Y, and 3) Install the new build tool”)
  • Priorities may correspond directly to the WIP items (“these 3 WIP items are top priority”, or “the WIP items on the board are stack-ranked in priority order”). But they don’t have to be that specific.
  • The test for useful priorties is:
    • 1) “This list of priorities helps us decide what to do today, and what NOT to do today!”
    • 2) “This list of priorities is so short and clear that everyone involved knows it by heart!”.
    • 3) “We all understand why these priorities make sense for the company”
  • Priorites are not exhaustive. We may have lots of things going on that are not directly related to our top 3 priorities. That’s OK, but:
    • Non-priority work should by default not conflict with priority work. There are of course exceptions (“the server just crashed, bring it up again NOW!”), use common sense and talk about it.
  • Guiding principle:
    • 1) Can you contribute to a high-prio item today (directly or indirectly)? If so, do it! Not sure? Ask!
    • 2) If you can’t contribute to a high-prio item, then work on something lower prio, but don’t let it conflict with people working on high prio work.
    • 3) Be explicit about your choice and why.
  • Priorities are cascading (or hierarchical, if you prefer, I just tried to find a less ominous-sounding word)
    • Your team has priorities. So does your department. So does the whole company. Higher level priorities trump lower level priorities, and are essential for alignment. That means:
      • 1) Lower level priorities should, at best, be aligned with higher level priorities (ex: “Department’s priority is Y, Team’s priority is Y”, or “Department’s priority is Y, team’s priority is X which contributes to Y”)
      • 2) Lower level priorties should, at least, not conflict with higher level priortities (ex: “Department’s priority is Y, but that involves mostly other teams, our team can’t really contribute, so we’ll instead prioritize X, and make sure we don’t take time from anyone working on Y”).
  • Avoid individual priorties. That tends to kill teamwork. Better to share priorities at a slightly higher level, such a team or workstream or project.
  • Priorities change (of course!)
    • It’s useful to have a recurring prioritization meetings to reevaluate priorities (every sprint for a team, every 6 weeks for a department, or whatever).
    • … but priorities can also change at any time in between!
    • Higher level priorities shouldn’t change as often, as they have ripple effects on lower level priorities and WIP. Causes confusion. The frequency of prioritization meetings should correspond roughly to how often we expect priorities to need to change.
  • Long-lived and short-lived priorities can be on the same list!
    • For example “our priorities are 1) customer support, 2) project X, 3) tech debt”. Project X might be short-lived and soon to be replaced by Project Y, while “customer support” might stay top priority for years!
  • When a priority list has more than one item, be clear about what this really means.
    • Ex: If our top priorities are “Project A and Project B”, what does it mean? Is A more important then B? Or are they equally important, but more important than other projects? Should we try to work exclusively on A if possible, or should we balance our time between both A and B?
    • No exact rules needed, just some guiding principles.

If used appropriately, cascading priorities and WIP visualization and WIP limits can really help your organization be focused and fast!

Categories: Blogs

Spotify Engineering Culture (part 2)

Wed, 09/24/2014 - 11:59

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)

Categories: Blogs

Squad Health Check model – visualizing what to improve

Tue, 09/16/2014 - 10:00

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.

Categories: Blogs

Agile @ Scale (slides from Sony Mobile tech talk)

Mon, 09/15/2014 - 14:09

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



Categories: Blogs

Hello managers, coaches, and other change agents

Fri, 09/05/2014 - 16:28

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 :)

Categories: Blogs