≡ Menu

Lean Kanban Central Europe – Day Two – PM

Here’s the second installment of my attempt to liveblog from Lean Kanban Central Europe in Vienna.

After lunch, I’m attending the lightening talks. I’ll be updating this entry continually throughout the afternoon. For my morning posts, see this entry.

Paweł Brodzinski – Introducing change the other way around

A story about introducing kanban: Change is usually bottom up and utilizes consultants. This one, didn’t. It’s a 200-person dysfunctional company with no craftsmanship or improvements  but did have one change agent with power and knowledge. Telling people what to do – didn’t work. Selling the idea – but no one believes the change agent had some special abilities. So he started at the team level with a small team of just four people. It helped that he choose a good team with some craftsmanship values. He started holding trainings in the organization and later switched to coaching as people started asking questions.

Lesson: It’s all about trust. Trust of the change agent and trust that the change itself will work. But how to build trust? You can start with small successes. You build authority by helping others, and not only with the change itself. Just be helpful, and people trust you. Create space for failure.

Hakan Forss – May the Force be with you

Nirvana = optimizing for both resource and flow efficiency.

Optimize for resource efficiency – keep the furnace stocked, even if it means stockpiling inventory.

Optimize for flow efficiency – 100% value added delivery of expected features. – who cares how the fire department spends its free time, as long as it gets to the fires fast when needed.

Lean is a business strategy for optimizing both.

You can’t improve what you can’t see. We are visual creatures. Most of our brain’s capacity is used for visual processing. It’s hard to look at a software team in their office and see what’s happening. Kanban boards make knowledge work visual.

Use facts, not gut feel. Collect data and go see what really happens on the floor.

Traditional change involves making a change to achieve a future state. Lean change is continuous. It’s the doing that matters.

Excellence is a habit. Kanban kata is about creating habits.

  • Daily kata
  • Improvement kata
  • Operations review – monthly

Change using small experiments based on testing hypotheses. Stretch your knowledge threshold to learn.

David Joyce – Valuable Conversations

More conversation, less action. Have a different conversation at each stage of the software lifecycle:

  1. Purpose – Who benefits from the work we do? How do you know it’s beneficial? What data will prove we have created value.
  2. Study need and demand – At portfolio level, where does the work come from? What type of work is it? Who funds the work?
  3. Work breakdown policy – How small can we break down the work and still get value? What’s the MVP? What dependancies have to be taken into account?
  4. Prioritization – What should be finished first (not started first)? How do we order the work?
  5. How does work get to teams? – Do we push work out, or let teams pull it? What rules do they follow as to when to pull work, what to pull? How do we choose who does the work?
  6. How to construct teams? – Specialist teams or generalist teams? What happens when a team lacks the resources/skills they need?
  7. How to do the work?
  8. How do you measure value? – What data shows that we added value? What actions do we take based on the value assessment?

End to end – What did we learn? Are we still learning? Are we improving the way we deliver, end to end? Has the progress been visible? Is our end to end delivery time dropping?

Most people are talking about what happens in the team. There are a lot of other conversations required for true agility.

Gaetana Mazzanti – The Rhythm of the Board

A stuck task doesn’t show up in a CFD. The CFD alone doesn’t tell the whole story. Even a control charts won’t show the problem until after the fact. We could just look at the number of items in one queue, but without age, it won’t show stale work. Add number of incoming and outgoing items to that chart, and you see a bit more, but you still won’t see a stuck task. You can use color to show average age in a column (like Kanbanery.com does).

This is a very visual talk – watch the video when it’s published.

Benjamin Mitchell

Encouraging Double Loop Learning When Adopting Kanban


He tells a story about how he had to hide his standups in an environment in which agile had gotten a bad name as a result of bad consulting. As it turns out, though, the CTO was NOT opposed to agile and acting in a deceptive manner reduced trust.

The ladder of Inference

Select -> Describe -> Explain -> Evaluate -> Propose Actions

You see something (like a person’s behavior) and select what you think is meaningful, you describe it to yourself (reducing it to simple terms), then you enter the land of assumptions, in which you try to explain what you don’t fully understand and then evaluate your options based on those assumptions and act on them.

Communicating on the level of observation (Select, Describe) can clarify reality before thinking, speaking, or acting in the realm of assumptions. Communicating on this level also allows everyone to see what others select as meaningful. Benjamin’s example is a Kanban board for a healthy team, but the team was unhappy because as a former Scrum team, they liked to see the left hand column emptying as a sign that they were successful. Kanban didn’t give them satisfaction in the way they were used to getting it. However, if they’d talked on the level of assumptions, they’d be arguing whether the board was valuable, without knowing that they have different values.

Single-loop learning – We learn when our actions produce the desired result. If it fails, you try another action.

Double-loop learning – We learn when we incorporate our experiences into reassessing our assumptions.

People tend to fall back on skilled incompetence and skilled unawareness when they feel threatened. They speak and act as they think they should, not according to a careful consideration of their own values.

Compare your values to your behavior. Examples: a team of consultants secretly evaluating a team’s transparency. A person giving feedback that “your feedback was poor because it wasn’t positive and it didn’t include specific examples.” Just think about that for a while.

Unilateral Control Model

Core vales – stay in control. Win, don’t lose. Ensure that no one feels bad. Act rational.

Strategies – State your position. Keep reasoning private. Don’t ask about their reasoning. Save face.

Consequences – Limited learning and reduced effectiveness.

How you feel is not a leading indicator of whether you’re wrong, because wrong feels right until you realize it.

If we feel bad, we imagine bad intentions in others because we can’t see their assumptions.

Behaviors are not inherently respectful or disrespectful. They are filtered through the interpretations of the actors and those impacted.

How to learn mutually

  1. Use publicly testable information and allow free and infomred choice
  2. Then test assumptions, share all information, explain your reasoning and intent.

“There is a world of difference between helping people to see and telling them they are blind.” – Stephen Parry

Don’t start with your assumptions, start by comparing what you and others see and how they describe what is relavant. The core assumptions may be different.

David Anderson

Managing a Risk Business – Understanding Liquidity in Flow


Some poorly understood fundamentals, “some remedial stuff for some of the advanced people in the room”

What does commitment mean in Kanban? Commitment happens when we pull something into the system. The act of pulling a task is the first commitment. “Our intent is to deliver it to you, completed.” And we have a probabilistic expectation of how long it will take, based on historical evidence.

Second phase delivery commitment – When we have confidence that something will be delivered, because it’s far into the process, and at this point we can commit with more confidence to a delivery date.

Lead time should start when we pull it into the system, not when it’s just a pipe dream of the customer’s.  This allows us to control variability in scope so as to generate useful predictions. Be sure to qualify the term lead time and cycle time when you use them, because not everyone has the same expectation of these terms.

Infinite queues decouple systems. If a queue has no limit, the areas between infinite queues is no longer part of the same system as the upstream and downstream stages of the process. It creates a point where work can die, requiring a two-phase commitment. It also makes it impossible to apply Little’s Law for the reasons above.

Some options get discarded, and we don’t show that, but options have value where the future is unknown. If ideas aren’t being discarded, it implies that the future is certain.

Flow efficiency – certain columns in the board are waiting states and some are working states.

Flow efficiency = work time / lead time x 100%

5-15% is normal. Greater than 40% is good!

Therefore, there’s no point in estimating, because you are only typically estimating the work time, even though most of the task’s time is spent in a waiting state.

Lead Time Distribution chart by task type allows for probabilist estimations based on historic data. It can also expose the degree of risk.

Allocating capacity to types of work gives us consistency so that we get better data for predicting performance by reducing variability.

Classes of service can help improve trust by reducing delivery risk by again by allowing us to see the impact of policies on the lead time distribution and to allocate work accordingly.

A lack of organizational social capital leads to a lack of trust in the system and a dependance on trust in individuals, which only lasts until a failure. Estimates and commitments create comfort, without a firm basis for it.

As a senior manager, how do you decide which team/department/vendor to give a piece of work to?

Investment bankers have the answer: invest in the most liquid market with a high level of trust. Question: can we view Kanban systems as markets?

Poor market conditions lead to a lack of trust in the system. For example, a shortage of sellers in a housing market slows transactions as sellers wait for better prices. Less transactions is less liquidity.

In a Kanban system, transactions occur when workers pull tickets to a work state. If the work is well-matched to the skills of the workers, work will flow more freely.

Answer: Different groups can be compared by using pull transaction per person or per dollar (or other unit of currency).

Liquid markets have a tight bid-ask spread. Orders are filled quickly. There are sellers and buyers for orders of all sizes. They are resilient; they return to stable states after a disruption.

In a software Kanban system, these might be mapped to due date performance, flow efficiency, variety of types of work handled, how many types of risk are being managed and how many classes of service are available, and of course, the ability to return to a normal stable state after a disruption.

A good metric should be simple, self-generating, relavent, and leading indicators. Liquidity is a good metric by this definition. It’s also a measure that is global to the whole system and so it’s unlikely to encourage local optimization in favor of better risk management.

Summary and conclusion: Poor liquidity creates unpredictable risk which lowers trust, driving people back to deterministic models (just give me an estimate I can hold you accountable for), but the solution is not estimating better, it’s solving the liquidity problem so that managers can trust and use the probabilistic predictions.

Comments on this entry are closed.