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

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.

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.

See?!

Let me tell you what thought about.

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.

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.

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

Dear tweeter friends.

In a tweet or two... could you describe what Technical Debt /feels/ like? #twitterBasedResearch#plsRT

— Jabe Bloom (@cyetain) August 5, 2017

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.

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.

What?! What have you done? Why?

The reason you are on vacation is to rest from work. That means that you are better off not switching your brain back into work mode every...

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.

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

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