Engaging with readers of my book (another one in the works) has been one of the most rewarding aspects of my career shift. The questions and discussions that arise often lead to insightful reflections. Recently, Massimiliano Spolverini posed a thought-provoking query:

In your book, the second rule of thumb for determining WIP limits suggests that setting WIP too high can result in idle work items. However, later, the approach of gradually decreasing WIP (the “Drop down and give me 20” experiment) implies that if too many work items are idle, one should revert to a higher WIP limit. Isn’t this contradictory?

In this post, I aim to address Massimiliano’s question and provide clarity on this matter, acknowledging that there’s no singular answer but rather a spectrum of considerations.

Setting the Context

The chapter in question, Kanban In Action chapter 6, delves into the significance of...

When I conduct workshops on kanban/lean, I always include a game because I believe it enhances the learning experience. One of my favorites is the Number Counting game, which I once animated in PowerPoint. You can view it here.

This game vividly illustrates the benefits of limiting work in process (WIP) as the lead time for all projects significantly decreases, along with improvements in quality.

However, I’ve always been tempted to introduce some curve balls and changes during the exercise. Yet, I refrained from doing so due to the anticipated difficulty and stress. Recently, I tested some variations on myself and wanted to share the results with you.

Original game - my score

The game involves completing three columns with letters and numbers as quickly as possible. In the first round, the columns are completed row-by-row, resulting in longer lead times due to frequent pen switches. Here are...

I had the opportunity to test my teaching skills to the max, as I got the question if I could come to my son Albert’s class, to teach “some programming”. I have taught TDD to kids before, see this long video for the result. But those kids were 3-4 years old.

Adding to the challenge was that this was my own sons class and I felt that I had to make him proud as well as fight a bit for being heard.

I took on the challenge and it went well, but I thought I’d share some of my preparation and experiences. A few people have asked me privately and I realize that this is a request that many of us in the IT business might get. If you read this you can avoid my problems at least.

The good people at Businessmap (formerly Kanbanize) invited me to write a guest post on their blog. I accepted and wrote a post on tracking and learning from Queue Length, a topic I picked up from Donald Reinertsen excellent book Principles of Product Development Flow.

Go over there and read the post - I’m happy how it turned out.

The rest of this post will be very meta… because it will be about how I can write the post on short queue length fast, by having short queue length.

I agreed to do something a little bit scary, a couple of weeks back. And then it got even more interesting as new information unfolded.

My task was to facilitate a retrospective with 5-6 managers across our organization. That was a bit scary - but then I realized that they all were going to be remote. I had never done a remote retrospective before so that made it more interesting.

I didn’t do anything particularly revolutionary, but I was happy with the outcome and the format. You might find this useful too - so I thought I’d share it here.

I’ve worked in a few places that have had hack weeks or hack days; a simple little thing where the whole company stops for a while and get to spend some time making something that you’re really passionate about.

This was first made famous by Google and their Google Time that have produced amazing products like Google Earth and Gmail. (That linked article, by the way, is showing my point of this post with painful clarity)

At every place that has had this kind of opportunities and practices I’ve also seen people skipping those days, because:

• We are too busy
• Well, that’s cute - but this real work needs to happen now.
• Not this week, but next.

That’s dangerous. Those silly habits are what is building your culture. Without that (where hack week is just an example) you are not you anymore.

In many of my encounters, I often hear variations of the statement:

We’re doing agile for some of our work, but other needs waterfall.

This assertion increasingly grates on my nerves. The truth is, waterfall, with its phased approach and large work batches, is unequivocally flawed. It’s high time to break free from this outdated mindset.

Contrary to popular belief, waterfall is not an antiquated relic. It persists and is lauded in numerous organizations today, particularly on the business side of operations.

To illustrate this point, let’s turn to an authority on the subject—Dr. Winston Royce, the very man who coined the term “waterfall.” In his seminal paper, “MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS”, Dr. Royce himself expresses reservations about the model’s efficacy.

Why Waterfall Falls Short

The pitfalls of waterfall are myriad and well-documented. From my years of experience and observation, a few...

During a recent writing session, I experienced one of the most intense periods of my life. In just 2.5 hours, I managed to produce 17 pages and 6000 words—an achievement I found both exhilarating and exhausting. However, what truly mattered wasn’t the speed or quantity but rather the quality and process behind it.

My writing endeavor followed four consecutive days of coaching and teaching at a company, where I engaged with approximately 200 individuals across 12-15 teams. These interactions centered around discussing opportunities and challenges in applying agile and lean thinking within their organization.

As the week drew to a close, the inevitable question arose:

Could you summarize your thoughts for us? Provide some insights for improvements and next steps?

With this task at hand, I embarked on a journey of collaborative report writing, which I found immensely rewarding. In this post, I aim to share insights into...

This week has been a series of firsts for me. I visited China for the first time, conducted a full week of training and coaching at a remote client (another first), and endured a prolonged separation from my family (not a first, sadly, but still rare).

Amidst these experiences, I found myself signing numerous books for the first time. As I penned my name, I began crafting small messages of good luck and success for the recipients. Over time, these messages evolved into a special blessing for individuals utilizing Kanban and Lean principles in their work lives. Well, others too, but they might discover the value of my wishes through some trial and error.

User story mapping is a powerful tool developed by Jeff Patton that I’ve often employed in IT contexts. With a user story map, you outline the steps of a user journey in your system and detail each step below (see the image below for a better understanding).

While this tool is excellent, one aspect I always struggle with is the incremental fleshing out of details.

I’d like to share an experience when we applied user story mapping to a non-IT situation, shedding light on what incremental truly means.