Kanban Guide Is Here – How Not To Read It

An important event in the Kanban community occurred about two months ago. The Essential Kanban – Condensed Guide was released. It’s a compact 20-page book, authored by Andy Carmichael and David J. Anderson. As you can guess, this book is very much up-to-date on most recent developments in the Kanbanland, but is at the same time very short and accessible.

Andy — I’ve known him for a year in-person and somewhat longer virtually — has a talent for word golf, putting important concepts in few words. At the Lean Kanban UK 2013 conference, he came up with the shortest definition of Kanban fitting in only 140 characters.

The Condensed Guide went through a review process by progressively increasing circles of reviewers. Starting with a relatively small number of Kanban coaches and trainers, the authors shared the refined versions of the Guide with broader circles, then with Lean Kanban conference attendees, and then with the public. Being one of the reviewers, I know Andy put a lot of work into the Guide. I wish the Brickell Key award committee recognizes his contribution with a nomination this year (here’s the link where you can do what I did about that.


Now I’d like to talk about how not to read this Guide.

I’ve heard the following phrases (or their variations) in many exchanges with various Agile coaches quite often. I need to qualify they weren’t Agile beginners, but from people with lots of experience, bona fide peer-reviewed status within the Agile community, and some pricing power when it comes to charging clients for Agile advice. Let’s listen:

  • Agile Manifesto doesn’t say that…
  • Scrum Guide says…
  • According to the Agile Manifesto…
  • Where in the Scrum Guide did you find that?

While I suppose some Kanban users will make similar references to the condensed Kanban guide, I expect experts to do so rarely.

I’ve been asked this week to give advice on some metrics-related material. My response was, the material was sound, but I pointed out it was a mismatch to the low organizational maturity. However, in a different organizational unit of the same client company, I made the opposite recommendation.

I couldn’t derive these two diametrically opposing pieces of advice from published values and principles. I didn’t do it by gut feel. I could have just said, let’s do it this way and then inspect and adapt, but that would’ve been nothing more than a case of intellectual laziness. I suppose there could have been some practice or algorithm to lead me to these two conclusions using different inputs. But I’d prefer having no such practice. Otherwise, we’d have to teach people to do things at the practice level. We’d get into arguments about the right way to do the practice. This would lead to dogma. Some of us would become purists, while others would practice the practice-but.

Instead, I simply made sense of a large number of available stories, of success and failure, my own and told by my peers (we meet often at conferences and leadership retreats, co-train, collaborate on engagements and keep up frequent correspondence). Even though these real-world stories are messy, gathering them, making sense of them and deriving useful heuristics are all teachable skills.

Conclusion

The Kanban community values observing what people actually do, how they act, what we can reasonably infer about their thinking. Kanban experts value paying attention to storytellers, making sense of their stories, and continuously questioning contextual appropriateness of their own actions and recommendations. We value it more than the printed word. We understand the knowledge worth having — and from the clients’ point of view, worth paying for — is and will be messy and conflicted.

In the four above situations, Kanban coaches didn’t assign much value to what the four respective Agile coaches said or to the printed word of the Agile Manifesto or the Scrum Guide. Instead, we simply paid attention to what the Agile coach actually recommended to their client in a given situation. Because we’ve come to value one thing more than the other.

The Essential Kanban – Condensed Guide will no doubt educate many current and future Kanban practitioners. But I don’t expect experts or proficient practitioners of the method to do the following very often: open the Guide on some page and say, here it says so.

Posted in books, Kanban, Learning | Tagged , , , , , , | Leave a comment

Carlos Goes Agile

We played the GetKanban game today. Here’s our position at the end of Day 11. People who know the game dread this moment. They know: Carlos, the game’s most infamous character, is about to show up. Reading the event card, indeed: “Allison the CEO hires a new Director of Software Development named Carlos.” There we go again.

End of Day 11

But wait, let’s read the event card further. The game takes an unusual turn today.

Carlos starts an Agile transformation!

Ask the facilitator to remove all blue dice from the board as Carlos’ staff will spend tomorrow in team formation and chartering. The day after tomorrow, the blue dice will stay off the board, but you’ll get two points from each, six total, as Carlos’s teams will be storming. When the teams start performing, the facilitator will give you a new set of blue dice.

Carlos sees the Analysis-done column as his product backlog and says it makes no sense to limit it. Remove the WIP limit from the Analysis column, place a limit of 2 on Analysis-in-progress and infinity on Analysis-done.

CFO, please record a coaching expense of $100 per day for the next 6 days.

Here we are at the end of Day 12.

End of Day 12 - Carlos' Agile transformation in progress

Time to read another event card.

Carlos asks Allison to invest in an Agile tool to track his teams’ work. It happens that Glenn’s father — Glenn is the marketing intern — works as a salesman for a company making such tools. Glenn’s father demonstrates a feature called KanBan, which visualizes each team’s work on a visual board. Then he shows how Carlos can roll the data up from all the team boards. He creates a burndown chart with one click. Allison is impressed and gives Carlos the go-ahead to purchase the tool. Margaret the Marketing Director is impressed too, but agrees with Allison’s decision to limit the pilot implementation to Carlos’ teams.

CFO, please record a subscription expense of $100 per day for using the new tool.

End of Day 13 - grooming the growing backlogs

Carlos asks Allison to assign and train Product Owners to groom the growing backlogs. Allison is suspicious, but agrees to it after a long debate. Remove one red die from the board until further notice.

Meanwhile, Ken the Agile coach says Carlos’ teams are entering the hyperperforming phase. Ask the facilitator to return the blue dice to the board. Ken and Carlos expect all teams to achieve the maximum velocity of six points. The teams failing to deliver six points will have to attend a full-day retrospective with Ken.

End of Day 14 - time to fire Carlos?

Looks like Ken will be busy facilitating retrospectives.

Carlos notices the shortfall in teams’ performance and asks Allison to hire more Scrum Masters to improve team facilitation. Allison responds with two updates. First, the CFO has downgraded his revenue forecast for the next two billing cycles. Second, Margaret is complaining that she has less visibility into what’s going on after Carlos’ investment in the new tool. Carlos throws a tantrum, accuses Allison of being stuck in the Waterfall mindset, and complains that his efforts to transform his department are undermined by his peers who are also stuck in the past and don’t understand Agile values.

You’ve Seen This Movie Before

Allison fires Carlos on the spot.

For what it’s worth, here we are at the end of the game.

Position at the end of the game

Posted in Agile, Kanban | Tagged , , , , , , , | Leave a comment

Carlos, You’re Fired!

Those who have played the GetKanban board game (one of Kanban training tools and a regular occurrence at Kanban community meetups) are likely to remember two dramatic moments.

On Day… — actually, let’s keep it a surprise for those who haven’t played the game yet — Carlos, the game’s most infamous character, enters the building. Carlos really shakes things up. First, he disallows any people outside his functional silo to do the silo’s work. Second, he forbids his direct reports from helping in other departments. Third, he eliminates one of the WIP limits and thus breaks the Kanban system into two. Finally, Carlos ignores the variation natural in the work he manages and insists his staff’s output must be 6 units per day even though they’re only set up to produce 3.5 on average (with some variation).

One of the reactions I get often from my training class participants: “Can we fire Carlos?”

Several days later — let’s keep it a secret how many exactly — there is this happy, cathartic moment: the CEO fires Carlos. The players rejoice. They gradually restore the broken flow of value as the game continues. Their organization recovers eventually and achieves some goal by the end of the game.

During the debrief after the game, some people talk about how they want to do better than Carlos in the real life. Some managers in the room realize they’re Carlos. Some realize they used to be Carlos, but changed their ways. They’re validated.

But if all we’ve talked about is, good riddance Carlos and how the software developers can now hug the testers, then that’s a relatively shallow learning outcome from the game.

Let’s Listen To Deeper Reflections

GetKanban game in progress - the logjam caused by Carlos

Product Owner

My job is to prioritize this backlog. And it only keeps growing! Now I understand why I feel so discouraged and why what I do seems so disconnected from our customers.

Senior Software Developer

I’ve worked in this industry for fifteen years. I’m used to getting called into these “why not six” closed-door conversations from time to time. Something is different in recent years though.

It used to be that the person questioning me, who had an office with a door, did the same job before their promotion. They understood me. Now, I find myself explaining myself to more people and none of them have written a line of code in their life.

Scrum Master

On my last job, I was constantly forced to make excuses why my team’s release burndown wasn’t trending at six points per sprint. It was humiliating. I felt, even if I could solve this problem somehow, it wouldn’t have mattered to our customers. I quit because I couldn’t take it anymore.

Agile Coach

On my last gig, I was responsible for coaching one of Carlos’ teams to hyper-performance. Six points per sprint is a crude way to put it, but I get that this is a game.

Executive

We’ve got a whole system that educates, promotes and rewards people like Carlos. We still have this system.

Posted in facilitation, Kanban, training | Tagged , , , , , , , , | Leave a comment

Kanban Training in Canada

As a Kanban coach and trainer, I often get asked about Kanban training: availability, which class to take, why, what about certifications, and so on. With this post, I hope to outline the key answers to such questions, focusing on what’s available right here in Canada.

The Lean Kanban University roadmap for Kanban proficiency consists of three stages:

The LKU awards two certifications:

  • TKP for successfully completing the TKP class
  • KMP for successfully completing both KSD and KMP classes (total 4 days of training)

Historically, there has been more Kanban training in Western Europe than in North America. And a larger proportion of North American classes were offered privately on client premises. This resulted in limited choices for North Americans wanting to take open, public classes. The situation began to change in 2015 and continues to change in 2016. More trainers offer more public Kanban classes in Canada, USA and Mexico. This includes my firm, Lean A-to-Z, Inc., which holds an independent Lean Kanban franchise.

We will be running a week-long Kanban training program in Toronto on April 4-8. You can take any of the three classes or mix and match them. Here are the registration links:

We also plan similar events:

The Team Kanban Practitioner and Kanban System Design classes will also be offered in Kitchener-Waterloo in June.

Which class to take?

The Team Kanban Practitioner and Kanban System Design classes have no prerequisites. Choose by the benefit desired in your organization’s context. If you want training for your own career development, choose KSD.

The Kanban Management Professional class is more difficult and has two prerequisites: KSD and several months of experience practicing what you learned there. If in doubt, go for KSD only. However, some participants can cope with the difficulties and complete KSD and KMP back-to-back. Those are typically consultants and managers with diverse experiences.

For participants taking more than one class, TKP+KSD (3 days of training) and KSD+KMP (4 days) are the most sensible combinations. Some participants may find value in taking all five days.

Quality

The Lean Kanban curriculum was developed by a global network of trainers. It continues to evolve as dozens of trainers conduct hundreds of classes to numerous trainees around the world. We maintain frequent correspondence, meet face to face often at conferences and Kanban Leadership Retreats, and thus continue to refine the design of your learning experience.

The instructional design, material, games, exercises, powerful questions, case study choices are all informed by our observations of what people actually do differently in their workplaces and careers after the training. What you will do differently matters to us more than any expert’s notions about how to present a body of knowledge.

Region-specific Advice

My franchise’s training offerings are somewhat skewed towards Central Canada and our American neighbours in the Northeast and Great Lakes regions. Here are some recommendations for those outside these geographical areas.

Western Canada: come to the Lean Kanban University headquarters and training centre in Seattle. Classes of all levels are regularly run there – check their latest schedule. You can also reach out to Calgary-based Dave White, Canada’s first Accredited Kanban Trainer.

French Canadians: availability of Kanban training in French continues to be scarce. Nevertheless, Montreal is home to more KMP certification holders than any other Canadian city. (And Quebec more than any other province.) There is already a Montreal-based French Canadian trainer who is working on his Lean Kanban accreditation. He may soon be able to offer certified Kanban classes in French.

Atlantic Canada: there are currently no class listings in this region. Please reach out to me if you believe there’s a local group that can support a public class or if you’d like to request a private class.

Conclusion

This was a short summary of the current state of Kanban training in Canada. Please consider what Lean Kanban has to offer and our training schedule. I’ll be happy to take any questions.

More detailed discussions of each class will follow in the future posts. The same goes for Enterprise Services Planning – there’s technically a forth stage. (It’s largely for the executives, senior leaders and their improvement consultants. ESP training is offered as a five-day modular program and includes enterprise services, project forecasting and portfolio management.)

Posted in Kanban, training | Tagged , , , , , , , , , , | Leave a comment

Decisions Before Data

I’ve been giving some consultations and on metrics lately. People ask for advice and show desire to have data in their decisions. Data, as opposed to opinions or, worse, looking at the crystal ball or superstition. We talk concepts, we dive into specifics of their situation: organization, services, teams, products, and we spend a fair bit of time on people’s feelings and perceptions. Something interesting becomes clear.

You have to put decisions before data.

This sounds counter-intuitive. Shouldn’t we gather data before making a decision?

No, first you have to decide what kind of decisions you want to make. What will you decide about and how?

If you know what you’re deciding about, people can find the data to support your decision-making method. To help you decide. People will find the right amount data, what’s really necessary. They will find an easy way to get the data, not wasting time or overpaying for information that matters little in the decision.

In the words of a decision research expert Douglas Hubbard,

You most important decision is the decision-making method that you’re going to use.

(said in his LKNA13 keynote).

But if data come first, then it’s the opposite story. Too much data, too much time or effort to get them, not sure what to do with them, and people may be afraid of what decision will be made. Is the decision you’re thinking of making to fire or promote me or one of my peers? I might bring different “data” to help you make your decision!

A natural question arises here, wouldn’t it be better if we had a healthier organizational culture where people felt safe and could gather their process metrics without fear of repercussions?

Depending on how much margin your business has for wishful thinking, you can revisit this question in the future — or you can start now to increase the transparency of what you decide and how.

Posted in Consulting, decision making, Improvement, leadership | Tagged , , , | Leave a comment

Replenishment Canvas

I included a new simple tool in the previous blog post, Observing Replenishment. Now is the time to introduce it properly.

LINK TO DOWNLOAD REPLENISHMENT CANVAS

Replenishment Canvas Thumbnail

Replenishment is about making better decisions about what your business should be working on now versus deferring until later (and possibly not doing at all). The Replenishment Canvas is a simple tool to connect logically several ingredients of such decisions, such as people, timing, information, options, decisions, and procedure.

You can use the Replenishment Canvas in at lest two ways:

  1. Observing and taking notes during the current replenishment-related activities
  2. Supporting the design of improvements to the decision-making process

Enjoy! Feedback, improvement suggestions, stories are welcome.

Posted in coaching, Kanban | Tagged , , , , , , | Leave a comment

Observing Replenishment

Replenishment (or commitment) meeting is an activity concerning the decisions made at the so-called first commitment point of a Kanban system. It is one of the seven Kanban cadences, which are all part of the Kanban method. Cadenced events happen, as the notion of cadence suggests, predictably at deliberately chosen intervals. They connect information flows (predictably) and thus close the feedback loops. The healthy feedback loops enable evolutionary change.

What if you don’t have a Kanban system? You’re still running some business. This involves making regular decisions about what you should be working on now versus what you should defer until later. When you design a Kanban system to model the process (as it’s actually practiced) of delivering a product or a service that is part of your business model, the Kanban system’s first commitment point will mark the point in the workflow where you make such decisions.

Making commitment points explicit is likely to bring some transparency and clarity to your decision-making process and stimulate improvement. This is one of the many benefits of introducing a Kanban system. Implementing a replenishment meeting takes this benefit one step further.

What are we looking for in a replenishment meeting? Some coherence, logical connectedness of the following:

  • Participation: Who are the decision-makers? Were they in the room?
  • Information: What did the decision-makers bring to the meeting?
  • Options: Before the Decisions were made, what options were available? Was the Information relevant to the options?
  • Decisions: Which Options were chosen? How did the Information lead to choosing some Options over others?
  • Timing and Change: When was the previous replenishment meeting? How did the set of available Options and the Information change since then?
  • Procedure: how did the decision-makers actually decide? Were the appearances compatible with their method?
  • Duration: How long was the meeting? Was its duration commensurate with the multitude of choice?

Now let’s go and observe an actual meeting billed as Replenishment. All names and timings are changed to protect privacy.

A coach's notes from  the replenishment meeting. Various problems are highlighted. See the text below.

It’s quite clear that no act of commitment or replenishment took place here. The obvious clues to that are:

  • The set of decisions (features to start) matches the set of options exactly
  • The metrics presented by the Team Lead relate to a different, lower-level work item type. User story-level metrics could be useful for sequencing user stories. Feature-level metrics could be useful for scheduling features. The information presented doesn’t connect to the options or decisions in this case.

We just saw pseudo-replenishment. We also saw several things that let us reasonably infer a number of things about the system. There are at least two work item types. The two form a hierarchy and there is a two-level workflow. Each level has a first commitment point somewhere. And somewhere, sometime, two groups of decision-makers, people with different rank in the organization and different boundaries of autonomy, meet and use some decision-making process to make their respective decisions.

Shortly afterwards, a design meeting is called and it goes on for two hours. People with higher titles are absent, but a group of business analysts and a Senior Architect join. The discussion is largely about some design of the solution, acceptance criteria and such. However, there are several scattered moments totaling maybe 10 minutes, when: the Architect surfaces some technical risks, the Business Analysis Lead does the same for some requirement risks, and people come to the conclusion that several particular work items out of many others should be started before all others based on these risks.

Those ten minutes were the replenishment meeting. Implementing the replenishment meeting, one of the Kanban cadences, means making this decision process transparent, connecting its elements logically, with the intention to improve the decision-making. As the decisions in this example involved sequencing work within committed scope, it would be more appropriate to call this activity proto-replenishment. Read more about proto-replenishment here. Proto-replenishment is to proto-Kanban (e.g. Team Kanban) is what replenishment is to Kanban.

As for the Kanban system replenishment, it is not in the cards yet for this particular service. They are, for the time being, only able to pursue localized, team-level benefits. When they design a Kanban for their multi-team service, implementing the replenishment meeting will come into focus.

Summary

  • Replenishment meeting is not a new ceremony to introduce in your process
  • Somebody, in some time and place, already makes decisions. Replenishment meeting is about making the decision-making method transparent, so that people can improve it. Transparency may even save them time.
  • Implementing replenishment meeting involves both observing how people try to make decisions now as well as designing improvements to the process.
  • It’s very important (to your business) to understand the logical connectedness of decision-makers, information, options, timing, and decisions.
Posted in coaching, Kanban | Tagged , , , , , , , , , | Leave a comment