As a consultant and coach, I find it very fascinating to see how the same topic has a tendency to arise in many different place and conversations I’m in. All of sudden everyone needs to chat about flow, or estimation or what-have-you.

I like telling stories, as a mean to teach and explain abstract concepts. Often when I’ve told a story once it has a way to surface back into conversations in the near future. I partly blame it on my limited imagination, but when it fits the conversation it’s interesting to notice how you tell the same thing several times a day.

The last couple of days people have been asking me about slack, and I’ve related a story about the pastor that married me and Elin. He was excellent in manage his own time and respected a good slack!

When I started my blog, almost 12 years ago, I often wrote posts of things that I would need to look up again. Sure enough, I sometimes stumble into my own posts when searching for solutions to problems I have.

This post is one of those posts. I was asked to conduct a survey throughout our department and needed to do some slicing and dicing of the stats. I used Google Forms to collect the data and then did the analysis in Google Sheets.

It all came out pretty nice and allowed people throughout the department to drill down into the data in a quick and simple way.

The other day a co-worker (Anders - awesome guy!) pointed me to a change management tool/methodology called Viral Change. I read about it and got quite hooked I have to say, but I’m not yet ready to make a report on how it works or it’s merited.

However, in one of the documents I read they made a little remark that I found very interesting as it brushes on many of the problems that I often have when trying to “do” agile or change into agile.

This post is about that but I have to give a little backstory and my current understanding of Viral Change.

Recently, I had the pleasure of delving into a modern classic: Mark Schwartz’s “A Seat at the Table”. Let me tell you, it’s a must-read.

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.