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.

Work in process (WIP) limits is a powerful, lightweight tool to not only improve your process flow but also to find further improvements in your process. I consider it wildly underused but hugely impactful.

Often when WIP limits are introduced we miss the point of them being the driver for further process improvement, but rather focus on what our WIP limit should be, or how we are going visualize it on our board. So I often share a story on how that can work.

I realize that I’m turing into an old man… I have, for many years now, being telling and retelling the same story so many times that people around me don’t stop me anymore.

At the same time I sometimes forget some of those stories. So I thought I’d better write them down before I lose it altogether.

I love working in teams, when I get the chance. There are a few teams that I’ve been in that still lives vividly in my mind. The way you feel togetherness and trust in teams are awesome.

But lately a thought has slipped into my mind; are teams always the best grouping of people to complete a task? What if I’m in more than one team? What kind of team feeling will that give me and the others in the team? What is a number one team?

And; just writing this post feels like blasphemy after 12+ years of promoting teams as the optimal way to work together.

Just to be clear - I still think it’s awesome, but maybe not always best for the situation at hand. </storm of angry comments from agile people avoided>

A year ago I had the great pleasure of speaking at the inaugural Agile Islands. Åland (as it’s written in Swedish) is a small group of islands between Sweden and Finland. It’s kind of independent but a part of Finland. They speak Swedish with the most beautiful accent you can imagine.

The reason there’s an agile conference in a society of about 29000 people (two stop lights on the entire island) is that they want to make the whole society aware and using agile practices. Sharing and cooperating around agile methods is one of the ways that they actually can compete and be attractive. It’s a very inspiring and lofty goal

Now I got invited back. The last year was a kick-off for agile practices (even some articles in the news there) and it left people wondering;

This all sounds awesome - but how do I get started

...

Sometimes in my consultancy the soft “people ware” thinking can borrow ideas from the harder “software” concepts. I want to relate such an idea that I cannot get out of my head:

Teams are immutable structures

I found this very useful to describe some of the unique traits of a team, that is often hard to grasp; such as estimates cannot be compared between teams or that changing teams around to optimize resources utilization is sub-optimization in more ways than one.

But first, there’s a strange word in there. Two, actually!

Today I got a call from a friend that works in a big organization. A bank with very old fashion and rigid processes for how software is handled and released.

Needless to say my friend ran into a wall of pain and trouble as he tries to introduce agile values of small things moving quickly though the value chain. Specifically the client was reluctant to release until everything is completely done - otherwise there's no value at all.

An old trick came to mind as I tried to help him with his conundrum:

There’s a difference between deploy and release

I think I’m not a fan of best practices. For me, best practices are limiting us to be only as good as the practice. Admittedly, that can be pretty good - but I’m looking to become better than I ever thought possible.

Also, as I’m a guy that make my living trying to teach people (often) practices, I have to make another disclaimer; best practices can be inspirations for us to build upon. However, I often see companies and teams instead of focusing on implementing the practice.

Nowadays, what I’m looking for is the principle that led to that practice. And even better; what are the values that pushed us to those principles.

In this post, I wanted to mention a couple of good examples of when values can move teams, organizations, and complete communities forward to a place that no one would have imagined or reached should we had...

I got the bash-programming bug. Lately I’ve been almost making up excuses to dive into another script. For example; the book I’m writing now is closing into an end. So I thought to myself; wonder how many words there are in there.

And the little programmer inside me just shouted out:

That’s a script!

In this post I will try to explain how the script that counts all the words in a bunch of word documents.

I have been working with a team now for close to 6 months. It’s the same old story; team has a lot of very important things to do from 4-5 different stakeholders around the company, team try to keep up, stakeholders around them get upset with the slow progress on the “features”, team struggles under a lot of tech debt that team postponed earlier to get faster progress on the “features”.

If you’ve been in any larger IT organization the last 20 years, you know this story. Your basic “hard-working, well-intending, trying to cope with the demand from the organization”-development team.

What I’ve found fascinating with this team, except that the engineers are amazing developers, is that the whole team feels trap. I’ve asked them numerous times to cut down on work in process (WIP) or cutting items into smaller pieces. Every time I’ve got confused looks and people say...