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.

Aptitud

We...

Every other day I meet people and organisation that says something along the line of

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

I’m getting increasingly annoyed with that statement. Waterfall (phases with big batches of work) is always wrong. You should get out of that thinking as fast as possible.

Any agile person reading this will not believe it. But believe it. Waterfall is very much alive and being hailed in most many organisations today, in my experience. Especially on the business side of things.

And please don’t believe me about this. Take it from an authority. Let’s pick … Dr. Winston Royce. He’s a good pick because he is the guy that coined the term waterfall in the first place. In the seminal “MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS”-paper.

Here’s an extract of page 2 (!)

Read More

I had one of the more intense writing sessions in my life the other day - getting about 17 pages and 6000 words out in 2,5 hours. But that’s not as important, although fun, compared to the quality and how we did it.

I’d been coaching and teaching at a company for 4 days straight, meeting ca 200 people from 12-15 teams to talk about their opportunities and challenges to apply agile and lean thinking within their current context and organization.

The obvious question on the last day was:

Could you just summarise your thoughts for us? Write some ideas for improvements and next step and stuff.

So we did. And I heard that the report was well received (hence I presume the quality was adequate), but in this post, I wanted to talk a little bit how we worked to get this down, and why that helped...

This week have been a long list of firsts for me, as I have been in China (1st time) and done a full week of training and coaching at a remote client (1st) and also been away from my family for a pro-longed week (sadly not first but seldom).

I have also signed a lot of books (1st) and I started to come up with some small sentences of wishing good luck and success for the people I signed the book for. Putting them all together they became a nice blessing for people using kanban and lean thinking in their work life. Ah, well others too, of course but they would discover the value of my wishes through some pain.

A blessing is a wish for success and well-being in the future and my kanban blessing is just that - some hopes that if they were true would...

User story mapping is a very powerful tool by Jeff Patton and I have used it many times in IT context. With a user story map you list the steps of a user journey in your system on top and then list out the details of each of these steps below (see the picture below because this explaination doesn’t really give the tool justice).

This is awesome but one of the things that I always gets hanged up on when doing this is the incremental part of fleshing out the details.

I wanted to share one situaton when we created an user story map for a very non-IT situation and I learned a bit on what incremental means.

Earlier this year my family and I moved to another...

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 widly 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 altogher.

The door mounting guy

I don’t...

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>

Before I write another word: being a team is...

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 opitmize resources utilization is sub-optimization in more ways than one.

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

Strange words 1 - team

Because what does a team really mean. The Webster definition tells us

a number of persons associated together in work or activity

The focus that stands out for me, in the way that I use the term team, is of course in the cooperation. It’s not...

Today I got a call from a friend that works in a big organisation. 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 had the same problems as my colleague at another client and we solved part of that by just making a clear distinction between deploying and releasing.

Deploying, in this context, is a technical activity. It means putting new versions of the code onto...