- sharing is learning

function share(knowledge){ return share(++knowledge) }

What I learned coaching a car dealership on stage

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

Agile Islands now asked me if I would be willing to help a company get started with agile. Zebrabil - a car dealership of 7 people. On stage in front of others. In 3 hours.

That sounded super scary and challenging, so I naturally accepted. I learned a lot by doing this and I wanted to share a few things.

Read on ...

Teams are immutable structures

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!

Read on ...

Deploy and release

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

Read on ...

Values to guide us

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 followed some best practices.

Read on ...

Counting words

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.

Read on ...

From push to pull - the essence of kanban

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 organisation the last 20 years, you know this story. Your basic “hard-working, well-intending, trying to cope with the demand from the organisation”-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 things like:

But it’s already on our backlog. We cannot do anything about that.

The other day we tried to do something about this and in doing that we found a key principle from lean that was missing here. We also discovered two different aspects of planning that helped us to sort this up.

In this post, I wanted to share what I learned about these principles and ideas. And show what we did. There’s nothing earthshattering here. It’s just kanban in action and some lean thinking.

Read on ...

Writing a script to extract pictures from Word documents

I had a problem and I noticed that I’ve, in the last couple of years, started to think differently about how to solve problems like these. I thought I share the solution to my problem here but also a little bit about the reasoning behind my problem solving.

The problem is easy enough to describe: I wanted to extract all the images from 20+ Word documents. I decided to write a script and share it here.

Read on ...

Flow in the F1-pit - thoughts on an inspiring video

This little clip pops up from time to time in my twitter feed

I finding absolutely mesmerising and it’s fascinating to watch and see each of the individual crew members in action. Pick one and follow his actions and you’ll see what I mean.


Let me tell you what thought about.

Read on ...

Get a good start - start your days mid-day

One of the things I miss with being a programmer that you can look back on a day and see stuff that has been done. Or, better yet, when you know a bunch of code that you’re going to write but haven’t written it yet. I kind of like that feeling.

Nowadays I often have a really hard time looking back on a day and point to something that I have achieved (other than conversations and if I’m lucky some new realizations). And before I start my day there’s just a bunch of meetings to be had. Nothing concrete.

Ok ok - this post was about one particular practice, I often used when I coded, that I got reminded of the other day. And that I now tried to get that idea into my ordinary schedule. So far it’s been very useful.

Read on ...

Changing the die - that can't go faster

This summer I decided to read The Machine that change the world. This a must-read for every Lean aficionado and the book that first coined the term in the first place.

It was very interesting to see the authors utter fascination of the ways of the Japanese car manufacturer, much of which was the opposite of whatever was the de facto standard for mass production at the time.

My favourite part was the history of car manufacturing that and how the Toyota Production system grew came out of necessity in a country that, at the time, was way behind and with little resources as well as little buying power.

Read on ...

What does technical debt feel like?

The other day a man that I respect very high, Jabe Bloom, tweeted a question:

I tweeted a response but that question got me thinking. I wanted to expand a little bit further than a tweet and this post is where I did that.

Read on ...

Respecting your vacation - how I ended up with 0 emails in my inbox after 4 weeks vacation

Sweden is an amazing country in many regards. One of the best is the by law required 5 weeks vacation per year. I know because I just came back from four of them.

However, in this day of eternal connectivity, social media and culture of responsive being awesome I sometimes have a hard time winding down and really get into vacation mode.

This year was different.

First I went on a 8 week social media fast, which helped me slow the tempo down quite a bit before my rest started.

I also tried a new way of handling my Out-of-office reply in my work email. This post is about my strategy to handling that.

Read on ...

Coaching when help is not wanted or important

I once was coaching at a team and had a big problem getting their attention and interest. We had many discussions about improvements and I used most of my tools but saw very little change.

It took me quite some time to understand why this was hard, but after a while it stood out like a soar and obvious thumb. And I felt so stupid not seeing that before.

It has to do with purpose and intent.

Read on ...

Impacts or backlogs

The word backlog has a negative ring to me (and I think to Swedish people in general). A backlog is a list of tasks that and I’ve yet not completed, things that still is required from me or my team. Putting something on a backlog is a nice way of saying; we will look at it… eventually.

(Business) Impacts, on the other hand, has a much more positive, forward-leaning ring to it. Here a bunch of opportunities that we still haven’t tried, that potentially make us even better.

Now it’s a bit sad that backlog is a central word in agile because I think it misses the point, quite a bit, and sets us in a defensive mood from the start.

In this post, I wanted to explore some thoughts I have had in my head on why we should stop using backlogs and start using impacts. Not only the words but the entire list altogether.

Read on ...

A walking retrospective that only turns up the good

Today with my team I tried something new for our retrospective. There were a few reasons for me trying something new.

Although I think that retrospectives are a fundamental practice of any agile team and the foundation for a continuous improvements mindset … I still think that I suck at facilitating them. And I cannot get excited about doing so.

Most retrospectives become a wailing-fest of the bad things that happens and very seldom leads to actionable small (!) items that we can implement to improve.

Also … I forgot to book a room after moving the retrospective in time.

These things led me to be a little bit innovative and we ran the retrospective today as described below.

The post will be the description of how to run the retrospectives, a few lines of correct attributions and then a few thoughts about why this worked. Because it was really good! Actually.

Read on ...

The nervous stats checker oscillating syndrome

I had a colleague on one of my gigs many years ago, let’s call him Olle (since that was his name). Olle just got a blood pressure meter for Christmas. He was around 45, at the time, and in reasonably good health, according to himself. But he was one of those guys that “had everything” and someone got him this machine. Mostly for fun.

Now, as he as a gadget geek he loved this new toy and of course started to use it. And he kept records in Excel. A few weeks after he started to track his health, to his horror he saw that he was getting worse by the day he measured.

Now, at the time when he told me this, he just started to measure 3-4 times a day and the result were not promising; his blood pressure was through the roof.

He had a doctors appointment later that afternoon to get proper medication.

I think I’m becoming Olle. And it’s JIRAs fault. And mine own. Mostly my own.

Read on ...

Reading the Scrum Guide

Scrum was my first love in agile. I still remember the revolution and excitement I felt after the Scrum Master course and when I and my colleague Öystein started our first Scrum team. It was awesome!

Later I moved on to more flow based approaches when I ended up in environments where Scrum was not a great fit with it s iterations and locked down scope.

Scrum and I was far away from a time. There are no hard feelings but we just don’t hang around much anymore.

I saw someone tweet something like;

I feel like many people talking about Scrum doesn’t really know what it’s about. Really.

Something like that. I felt that it was about me. So I decided to read the official Scrum guide and take some notes. They are summarized in this post.

Read on ... posts reposted

In 2013 I got invited to write blog posts for I was quite surprised and honoured, since that’s a place where I’ve read many great posts over the year.

I hopped to the challenge though (never regretted doing that) and ended up writing 6 posts, before I lost tempo.

I’m actually proud of all those posts and wanted to preserve them here on my site also. I noticed that has slowed down and went away completely the other week without anyone noticing. So I thought it would be better to save them somewhere else.

Here’s they are:

Read on ...

Repost: The time when we did Lean backwards


I noticed that CodeBetter is slowing down. Maybe dying. I’m preserving my post from there, here to my site.

Original post

A couple of months ago I was very fortunate to work alongside a great team. They had a not so envious task before them, namely to introduce a new main concept into an legacy code base. You know, the code has been around for at least 5 years and now you need to add a concept that was no-one ever thought we would have in there.

They did that. In just 3-4 months and delivered with flying colours. I didn’t have much to do with that, I merely observed their work.

When they were done I proudly introduced the team to a new senior in the company and told him about their feat and how they had gone about doing it. His words: well, that’s Lean backwards then.

He was right, but I never thought about it until then. In this post I’ll describe how they worked, what the “lean” way would have looked like and what we can learn from the difference.

Let me just say that the way the team went about their worked, and the feature was a success in production. Very high quality (2 bugs reported if I’m not mistaken) and well received. In order to not put any blame on that great team I will talk about “we” in this post. Although I didn’t have much to do with their success.

Read on ...

Comments on common board practices - Walk the board from right to left

When our board is lined up as our process it’s quite often an array of columns starting to the left when the idea first comes into mind (or in a backlog column) continuing down our workflow, adding more and more value until it reaches our customers where we can learn from the usage of our new feature.

Although it could be tempting to go through the columns from left to right in our morning meeting, I would suggest that you consider doing the opposite.

Read on ...