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.

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