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!


Friday, March 10, 2017

10 Tips on How To Best Start your Kanban Journey


Are you thinking to start using Kanban but are unsure how and where to start? Here are 10 tips to help you get going on your Kanban journey!




1. Start with a small “Team”

An easy way to gain experience with Kanban is to introduce it to a team that already delivers a well-understood service. These teams usually have a clear purpose, goals, and customers, which makes creating a meaningful Kanban system easier. It is also easier to start with small teams (2-8 persons) than bigger ones. For example, a small project team, an application maintenance team, a small function (process managers, operation, communication, etc.).
(The coach’s comments) Kanban delivers spectacular results (100-700% efficiency increase) when applied to whole value streams involving several teams, functions and specialists. But You’ll need to get some Kanban experience under your belt before venturing there. For the moment focus on a single existing team.

2. Make sure the Team’s lead or manager is on board

The team’s lead/manager must want to introduce Kanban. This is the most important person as he/she is setting the tone for all other team members. If the team-lead does not understand the benefits, is skeptical or against, then don’t bother and look for another team as you will waste everybody’s time, including your own.
(The coach’s comments) You may want to have separated preparation meetings with the team-lead to get buy-in. 

3. Make the team’s purpose clear

Clarity of purpose is key for succeeding with improvements in general and with Kanban in particular. A meaningful Kanban system can only be created when the purpose is clear. So before introducing Kanban, the team should be able to answer the questions: “What service(s) are we providing, to whom?” and “When do we succeed?”. This step is included in the Kanban Kick-start workshop.
(The coach’s comments) Not all organization groups - especially in larger organizations - have a common purpose. Groups are usually put together to manage people. Kanban can be used to bring clarity to those groups as well but it requires more coaching effort, so let them on the side for the moment and focus on smaller service-focused teams.

4. Start where you are

Start where you are” is one of the main principles of the Kanban method. Done correctly, introducing Kanban should create very little friction and almost no resistance to change. Make sure that you follow this principle too by not introducing anything new when adopting Kanban: no new ways of working, new roles, meetings, interfaces or artifacts. Just focus on making the current way of working clear and explicit.
(The coach’s comments) This is plenty enough as a first step, as team members often realize that they have been working very differently all along and need to agree on a common way of working. This may be a change in itself for some team members, but it usually does not create resistance as it comes from the team. After some time, the team will have a much better understanding about how the work works. The team itself will then propose some changes to its own way-of-working (and, yes, that’s totally OK to do the change then!).

5. Establish Pull

Actually, there is one important change to make a.s.a.p: to adopt Pull!
When starting with Kanban, “Pull” is mainly about letting team members pull ready-work when they have capacity, instead of having the manager pushing work onto individuals (regardless of how much work-in-progress they have). In effect, this rule removes a lot of the micro-management from the manager and gives it to the team. This may require a difficult behavioral change for some managers.
(The coach’s comments) Discuss this with the manager on beforehand and make sure to participate to the Kanban meetings to give feedback and support. Eventually “Pull” will encompass other aspects like balancing demand with capacity, replenishment policies, making demands refutable and flow efficiency. But, you have time to get there.

6. Give the team the authority it needs

Kanban is about making the team fully aware and in control of its work. It allows the team to assume full responsibility. For this to succeed, the team must have the authority it needs to decide about its own way of working. It must be up to the team, not the manager or anyone else, to decide the rules and policies about how to handle work.
(The coach’s comments) Of course, this must happen within the boundaries set by the organization (legal, safety, etc.).

7. Make everything explicit and transparent

The key to success with Kanban is to give everyone (team members, customers, and stakeholders) a perfect understanding about the current situation, policies, and past performance (statistics). Everyone should be able to provide input - based on facts - to the question “what is the smartest thing to do for us right now?”.
(The coach’s comments) Makes this as visual, and accessible, as possible (think “stickies in the corridor”).

8. Keep it simple

Regardless of how much time you’ve spend creating your Kanban system, it will be wrong. It’s only by using the system that you will be able to make it right. So, do not spend too much time upfront (keep it simple), start early and keep adapting.
(The coach’s comments) The team will soon realize that “the board doesn’t work anymore!”. That is excellent news! It doesn’t mean that you’ve done a poor job, it simply means that the team has matured and better understands how the work works. Help the team adapt its system (visualization and policies) and off you go!

9. Don’t do this alone

Kanban is much more than stickies on a wall! It looks deceptively simple, but in order to reap the benefits of Kanban (100-700% efficiency increase) you may need help. Learn from others in your organization and elsewhere. Share experience by inviting other teams to your Kanban meetings, go and see for yourself what others are doing, go to “Lean Coffees” and conferences. A Lean/Agile coach can be a good investment to help you go further and make your team(s) succeed in the long term.
(The coach’s comments) Strength in numbers!

10. Spread out!

When you start to be confident with your first implementation, try to expand your Kanban “bubble” upstream and/or downstream in your value stream. Involve customer(s), other units, teams, and specialists that you are depending on. Re-design your interfaces with them by establishing regular meetings to discuss what works and what doesn’t, what you need from them, what you can do better for them, etc. Create a bigger Kanban system with everyone needed to deliver value from concept to cash. Soon, you will have given control of a whole value stream to the individuals working in it, and great things will happen!


Bon Voyage!


Monday, January 2, 2017

New Aim: Knowledge!

Today, I am starting a new chapter in my Lean/Agile journey! After focusing on bringing more agility and flexibility to an Enterprise, I will now go back to what I feel are my roots: a small company.

I am now working for Aim 4 Knowledge, a Stockholm-based company delivering training solution to IT organizations. My new role is officially ‘Product Owner’ for the Lean and Agile area. I will work to bring, create and deliver excellent training and education on:
  • Lean for knowledge work
  • Kanban for end-to-end value streams, portfolio and teams
  • DevOps
  • Agile development
  • Lean Startup & User eXperience
The idea is a to support companies (you?) in creating an iterative, incremental and streamlined value creation stream from customer to production.

Why does this matter? Because more than ever before we are in a fast moving, highly competitive environment where those who win can simply deliver more value, earlier.

Don’t hesitate to contact me at christophe.achouiantz@aim4knowledge.se