Monday, February 10, 2020

Where am I?

Since I’ve start working with Crisp, I’ve started blogging on Crisp’s platform. You’ll find more here:
See you there!

Wednesday, April 4, 2018

How to Get your Kanban Initiative Back on Track!

All kanban systems experience some “heart attacks” once in a while. 

As a team, you can react in two ways: abandon your kanban system, or act smart. If you manage the situation well, you can learn from this experience and improve your kanban system to propel you all the way to high-performance.

Building on my popular “Fika” blog series, I present here the mechanism at play behind these “heart attacks” (the policy debt trap) and give some advice on how to best handle it and stay on the high performing path. I also offer some new view on what “failing” with Kanban means: a fantastic opportunity for improvement.

This presentation was recorded during a webinar organized by Digité (of SwiftKanban fame). The actual presentation starts at 09:35 after some introduction by Mahesh Singh of Digité. 

You will find the slides (PDF) here.

Friday, November 17, 2017

Fika Stories 2 - The Policy-Debt Trap

November in Sweden: Blä! The sky is impossibly low and grey, it’s pitch dark at 4 pm, freezing, and then everyone gets cold. Especially men: they get man-cold.

There are also situations when your Kanban gets a man-cold (though it doesn’t need to be November for that): it’s not really dying, but it feels like it and it becomes kind of useless. At the fika, the story sounds usually like this:
“Kanban worked well for a while, but then it started to feel cumbersome, it did not really fit anymore. So we started to skip some dailies…” (more details follow on how things start to go south).

Something is obviously wrong, but the good news is: it may not automatically mean that you’re doomed and that your organization is unfit to all Lean/Agile things (find a new job). On the contrary, it could be positive, a sign that you are improving, becoming more mature! Wait, what? How can this it be?

The cause can be a mismatch between your understanding of your way-of-working and the design of your Kanban system. In other words, that you somehow outgrew the design of your Kanban.

You see, at its core, Kanban is about understanding Work, how you manage this Work and how the two match. Designing a kanban system, you put together a set of policies and rules governing what work you want to visualize, in which way, and how you want to manage it. Using the system daily, you then gain clarity and insight on how work should be managed and seen for you to best succeed (whatever success is for you). It could be insights on who to involve, when you have the daily meetings, what is in your DoD, how to manage Joe’s availability with a column, what WIP limits would work better, etc. And here comes the danger: the more you wait before reflecting this new understanding in your system, the more you build a “policy debt” (and as all of you agilists know very well, a paragraph containing “debt” will never end well). The more “policy debt” you have, the bigger gap between your mental model and your system, and the less your Kanban will be relevant, up to the point where it becomes misleading, unfit. There it is: it doesn’t “work” anymore, even if it all started well.

So, policy debt is bad, but seeing it in effect means that you have matured! You now better understand how to manage your work in your context. You have learned what needs to be done to come closer to your definition of awesome, your fitness to purpose, your definition of high performing. And that’s great news! You just need to implement this learning by performing changes. So, take the time to pay back your debts (re-fresh all policies?), and off you go with a newly-trimmed and Kanban to support you.

As a corollary, it also means that you will see policy debt building up very quickly in new Kanban systems (everything still smelling plastic and yet untested). With an inexperienced team, you must expect - and plan - for moments when the team feels that “the board doesn’t work anymore”. No reason to panic, this is all very normal. Rejoice instead, this is good news: "Team, we are learning!".

This makes me think that there is a way to measure a team’s maturity rate: keep track of the number of policy changes over time (redesign of the board, changes to DoD, new policies to interact with customers, changes to the agenda for daily meetings, etc.). You know that policy debt is building when no changes occur (especially at the beginning of your Kanban journey).

The policy-debt trap in Kanban

Here are some tips on how to avoid the Policy Debt trap:

  • Kanban works best when your policies (incl. visualization) are a true reflection of your current way of seeing and doing things. Unfortunately, teams tend to voluntarily inject a good dose of wishful thinking, wanting to create a “healthy” tension to force change (Document everything! Peer-review all changes! Longer Definition of Done! Tougher Definition of Ready! Etc.). Let me spoil it for you: it never works! Just stop. Now. Do you want positive changes? Don't force it, be as honest as possible when creating your system and let Kanban show you what's the next most meaningful improvement.
  • Pre-cooked Kanban templates may be a quick and easy way to start, but beware! The more complex these are (beyond "To Do, Doing, Done"), the more alien they are to your context, and the quicker they will generate policy debt. Instead, try to tailor your kanban system to your context using a STATIK method (like the Kanban kick-start for example).
  • Policies should be updated as soon as you identify a mismatch. The role of the facilitator of the daily meetings (flow manager, or whatever name you have for it) is crucial here in making the team reflect on which policies don’t work as intended and should be changed or removed. This especially relevant at the beginning of your Kanban journey.
  • You will gain insight faster at the beginning of your Kanban journey, so be prepared to update your policies frequently to not fall into the trap. As a rule of thumb: every week the first month, once a month the first 6 months, slower than that later (assuming a stable team and stable service).
Fell into the trap? Update your policies before Kanban gets a real man-cold!

Thursday, November 9, 2017

Fika Stories 1 - “Help! Our Kanban died!”

In Sweden, we love to ‘fika’. Fika requires you to take time to sit down and sip coffee (usually strong and black) with your colleagues to chitchat about this and that. Visiting different organizations, I tend to fika a lot and hear all these stories about how things are going.

Today, I’ll like to share three classic fika stories about Kanban, more specifically how Kanban doesn’t “work”. It turns out that these stories are usually epic, picturing people and teams valiantly trying to implement Kanban in organizations that, unfortunately, turn out to be quite unfit for value delivery. Thus, the struggle and angst perfectly fitted for an entertaining fika. So, you have the one…

  • Where the org turns out to not be ready for transparency and flow management: ”We tried Kanban but it didn’t work for us: we ended up with too much on our board to handle”. 
  • Where the org exposes it has an inflexible and long tradition of classic, command and control management: ”We could not control our WIP because our manager kept pushing new stuff on our board”. 
  • Where the org reveals it has structures that are unfit to deliver new stuff (e.g. using component teams): “We could not limit our WIP because we got blocked all the time by other teams, so we kept starting new things” (or the opposite, which I’ve heard only once, “We followed the WIP limits but quickly starved because everything always got blocked!”).

Tough! But it’s OK because, in all these stories, Kanban is actually working as it should! It is already helping by being instrumental in all these disquieting revelations, and making the problem blatantly visible: it died! What can you more ask of the poor thing? You see, Kanban is like a canary in a mine: when it dies, it shows you that you’re in real trouble. It means that the most basic preconditions for flow and continuous improvement are not (yet) in place. You must fixe these preconditions to get your Kanban back to life.

What to do then? There are several ways to mitigate some of these problems (start by better training and coaching, perhaps some new policies), but if you really want to get at the root causes, you need to fix cultural and/or structural problems. Unfortunately, there are no shortcuts here: you “just” have to engage senior management. Explain what the dead kanban system means to their organization’s capability to deliver value and improve/innovate; get their commitment and do some change. Feeling up to the task? Look at Jason Little and his excellent Lean Change Management for guidance.

Oh, and by the way, a kanban system does not need to be advanced at all to act as a canary. Any kanban system, even (especially) simple/proto Kanbans, will do it, as each deeply connects with its environment and context.

Now, Good luck!

Tuesday, November 7, 2017

How to Train to Kanban - A workshop at Lean Kanban France 2017

I have the pleasure to be invited back to Lean Kanban France this year

I will host a workshop about how to train to Kanban. This session is specially designed for you who is about to start training one or several teams, or who want to become better at training Kanban. 

It builds on the “Kanban Kickstart” concept and take it further. Welcome!

How to consistently get the value promised by the Kanban method?  A good start is delivering adequate training. 
The problem is that Kanban is tricky training material. On one hand, it appears deceptively simple (stickies on a wall! What could possibly go wrong?) while on the other hand, it has deep counter-intuitive elements that are challenging to put in place, especially in mature organizations (Pull, WIP limits, help each other’s cross boundaries). Quite simply: easy to start without experience, but harder to excel at without experience. 
In this workshop, I share my experience (gathered since 2009 with 70+ teams) on how to train teams in the use of Kanban. I share how succeeding consistently requires seeing training as a continuous effort that follows a team’s maturity curve. We look into how to frame training correctly, how to be clear on the “why” from the start, and what are the “prime directives of Kanban training” that help you better succeed.

Tuesday, March 14, 2017

Explaining the DevOps Hype

I recently did a deep dive into DevOps to create a DevOps Foundation training. I thought it would be an uneventful journey, but while doing some research to complement my own experience I uncovered something much bigger than what I was prepared for. As if there suddenly was this major unavoidable thing popping up in front of me (“this is no moon, this is …a space station!”).

It’s only common sense!?

Having worked with agile for quite a while, my view on DevOps was basically this: DevOps is about delivering the right service/product by shortening and improving the communication channels and feedback loops between the different units, teams and specialists in a value stream. In other words, e.g. “Infra” and “sec” must be involved from the start, operations engineers have as much excellent input from day one than any other application engineer and everyone must be involved to maintain and evolve the service/product. 

Wake up! There is more a Stake here!

While this is true, what really surprised me was how much deeper the DevOps movement goes: DevOps is far more than an alternative mindset, it really encompasses the work culture you must adopt if you want to be successful in the cloud. And, as there is a cloud in your future (whether you like it or not), it means that you will be working with DevOps or you will not work at all! 

This is how I see it: DevOps is the re-writing of the IT services development and maintenance handbooks so that the services can be fit for the cloud. 

This is worth looking further into, so let me elaborate on that a moment. 

From the Enterprise to the Cloud

To understand what is happening, I strongly recommend you watch Mary Poppendieck´s fantastic talk “The Future of Software Development” (Berlin’s GoTo Conference, November 2016). She summarizes the evolution of our industry from “the Enterprise” model (golden age in the 90’s) to Internet/“the Cloud”. Mary is always excellent, but this must be the most insightful talk I have seen about our industry, by large, go and watch it now! I have created two figures that try to summarize some of her key points (directly extracted from Aim 4 Knowledge’s “DevOps Foundation”). 

 Figure 1: the forces pushing for the cloud (click for larger)

Figure 2: DevOps as a reaction to these forces (click for larger)

These two figures summarize the forces behind the emergence of DevOps (Why DevOps?), and the DevOps main components as a result (Infrastructure as code, Micro Services, Cross-functional teams, automation, feedback, continuous delivery and resilience engineering).

In Figure 2 you only see the result (DevOps emerging), but it is interesting to understand how it came to be: the real engine of transformation has been the survival instincts of the people in Dev and Ops. The existing development and maintenance handbooks (ITIL, PM body of knowledge, etc.) were fit for the Enterprise model and cannot cope with the level of scaling, complexity, and speed needed in the cloud. This made it unsustainable for the people tasked to develop and maintain these services. Quite bluntly, they had to adapt and re-invent the handbooks or quit (utterly dejected in the process). So, they pulled in everything that could help: agile, lean, automation, modern management methods, etc. The result is an adapted handbook, and its appropriate culture, that is “fit for purpose” (effective and sustainable) for the cloud. We call it “DevOps”.

Wait, should I throw out everything I’ve learned because it is not fit for the Cloud?

Well, yes and no! I believe that the way the practices and taught and communicated are more at fault than their essence. Take for example the ITIL. The way ITIL is described, taught and implemented is very much anchored in the Enterprise model. Control is established by having many loosely-coupled processes, slow by design, implemented by-the-letter in silos. It is not surprising then that the very people that should be helped by these processes are the first to reject them once scale, speed and complexity are cranked up. Therefore, ITIL is proven to “not work” with DevOps. Well, on the contrary, we need it more than ever! But it should be reformed, adapted to better fit this new context we are rushing headlong into. We must change the way it is described, taught and implemented. Thankfully, there are efforts to make this happen, for example with Gene Kim staunchly defending ITIL for DevOps, or Pelle Råstock with his lightweight and service-centered TRIM model.

Re-write your own Handbook, Now!

Go and learn what DevOps is about, for real. Don’t go for tool vendor X’s “we have you covered” sales pitch. DevOps is much more than tools: it is about re-writing your service/product creation and maintenance handbooks. This requires new practices that are fit for the cloud. These require new ways of thinking and new mindsets: a new culture! As you can imagine this will take some time. 

As everything accelerates, my advice to you is: start now!