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. There’s an awesome little paragraph in the book (page 51-52) showing clearly how Taiichi Ohno (and in turn Toyota) let their strive for a faster flow change things that was considered constants. At the time (and still I presume) you make...

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. No-one ever wants to create technical debt. Some of it is created accidentally since we learn new things, requirements and learn about how the feature is performing in the real life. For example, you have most likely said or heard the following: Oh?! The product id can be blank? What - why don’t they fill that part out? Whoa! That page got A LOT more traffic than we estimated. We need to optimize those database calls. Now! All of those “What?”, “Oh?” or “Whoaaaa!”...

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 other hour because...

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. Help: not needed One day I was out walking and I thought about the team and why we couldn’t connect with them. Don’t they want my help? I often felt like I was like an old grandma offering advice that was really dated and badly timed. And then it dawned on me: They never asked for my help I was sent to this team to “agile coach” but the people in the team...

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

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

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. Structure of this post What I did was that I tweeted as...

In 2013 I got invited to write blog posts for CodeBetter.com. 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 CodeBetter.com 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: My first post was on mob programming and was the first post on the topic written by someone else than Woody Zuill. It’s even mentioned on the wikipedia page for mob programming and those facts makes me immensely proud I wrote a few post on a the work I was doing...

REPOST FROM CODEBETTER 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...