I have a very particular set of memories from my childhood, that revolves around me falling, hitting or otherwise hurting myself. If it was just a bruise my father often said to me:

How bad is it? Is it worth crying for, like you do now?

(I was probably exaggerating quite a lot). Of course, it was!

Tell me, what are you going to do if it really hurts, then?

That was maybe not pedagogically correct for a child in pain but it at least got me thinking. Indeed… what comes after screaming and crying? Could I turn this up? Would it make a difference? Would I get … yes, what was it I wanted, really? Maybe just a hug or comfort. Could I get that by other means of communication that the display I was putting on now?

Of course, 7-year old Marcus didn’t reflect...

Lately, I’ve been deeply immersed in discussions about flow, and I’m continually struck by the myriad benefits that stem from prioritizing better, faster, and smoother flow.

In this post, I’d like to share some recent reflections that have been occupying my thoughts.

I once worked at a large company where they had so many priorities 1 features that they decided to introduce … bam-bam-ba-baaaa … Priority 0. But after a few minutes, we ended up with about 5 items in that category and we realized the ridiculousness of continue to do Priority -1 etc.

Today I saw this pattern in action again, and a new realization about a missed teaching opportunity washed over me. I wanted to share this with you in this post.

Over the last couple of weeks, I’ve been re-discovering an old diagram (more like a sketch really). You can find it scribbled on nearly every whiteboard in our office now because it sparked a lot of interesting discussions on flow, flow efficiency, and optimizations for value delivery.

I wanted to share this with you here, in a few iterations, and also share some of the discussions that it triggered.

First of all, this came up as we had a process that was taking too long. It involved a few people from different departments who needed to complete their work before handing it over to the next department. Then there was a user acceptance testing phase at the end that, of course, took a long time.

The backlog of work was growing much faster than these people were completing work. High stakes, stakeholders, and customers were getting angrier by the minute,...

I often give out a lot of books tips in lectures and workshops, so instead of me typing and find links everywhere, I thought I’d put together a list of them here.

There are only 10, so if one is added another one needs to leave. That said - they are in no particular order.

For each, I’ve given a short little review and comment on why I like the book.

“Wow - this release was awesome. So fast, almost no manual testing and only one bug found in testing,” Sarah exclaimed in joy.

“Yeah, but there was that one bug. It should be zero, huh?”, Marcus responded grumpily from his corner, without looking up from the screen.

“Also - there are still manual testing going on. It should be all automated,” John chimed in, unimpressed.

“Fast and fast … still our build runs in 8 minutes. That is a long time. Way too long if you ask me!” Alex sighed as she pointed to the build log on the screen.

Sarah went back to her desk. Her enthusiasm was gone.

I think we often miss the improvements we made by not looking back and appreciate the journey we made. If we only talk about what is still not great we lose track of how far we have come. This is...

Just finished “The Art of Coaching”, by Jenny Bird and Sara Gornall, that taught me a great deal so I thought I’d write down some thoughts and comments.

I honestly don’t remember putting this book into my basket and was quite surprised when it arrived among some other books in my package. Hence I read the book with very open mind and curiosity.

Got a question in an email the other day, asking some advice. Nowadays when that happens I ask permission to publish the answer here to not waste keystrokes into the email-bin.

The question was from my friend Jonas, that works in a start-up that is growing rapidly. He kindly granted me permission to answer here. He was asking this (my translation):

We are on the brink of a substantial expansion and I was wondering if I could pick your brain on experiences and best practices for how to organize a team of developers.

We’re thinking about a team of 4-6 people that has responsibility for a specific part of the product. What roles and responsibilities should be in, or out, of the team?

And in a follow-up mail:

In particular, the product owner role and what that role does and doesn’t do. I like the PO...

I’m talking less and less about agile and even lean, these days. Instead, the poison I’m selling now is flow. In all honesty, it might be better to put it like this:

Opening peoples eyes for the benefits focus on flowing work smoother and faster, alleviates discussions about lean and agile later.

Flow is an eye-opener and shifts your perspective. Things that previously was paramount (ensuring people are not idle, for example) becomes irrelevant or uninteresting. New ways, practices, and innovation quickly spur.

But also new problems occur. One of the most common ones is the fact that flow is severely hurt by tasks that have many dependencies. I think I talk to teams about 4-6 times a week about this.

In this post, I will offer a few thoughts on how to handle this type of situations.

As a consultant, you get to see many, different organizations and look deeply into what makes them tick. This is a great benefit of my job, but at the same time quite hard to find from time to time. The reason for that is that most organizations have very lofty and worthy values but what is lived out is something else.

But I’ve found… who am I kidding … stolen a way that make values more tangible and important in our everyday life. It’s a simple trick that you can start using tomorrow.