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

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 just a group of people sitting next to...

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 a production server or released to...

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

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. The script Here’s the script: #!/bin/bash totalNumberOfWords=0 for file in ./docs/*.docx; do wordCount=$(textutil -convert txt -stdout $file | wc -w) fileName=${file##*/} echo "$fileName has $wordCount words" totalNumberOfWords=$((totalNumberOfWords + wordCount)) done echo "Total number of words: $totalNumberOfWords" And here is what’s happening. With the for-loop I’m iterating over all the *.docx files in the docs directory. The next line is a little tricky but let’s go through it slowly. First the parts, part by part,...

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. TL;DR - just the script Here’s the bash script that I ended up with #!/bin/bash rm -rf zips mkdir zips cp docs/*.docx zips for file in ./zips/*.docx; do mv "$file" $file.zip unzip $file.zip 'word/media/*.jpeg' -d $file.images rm $file.zip done Decisions, decisions, decisions First of all I decided to write a scrip to do this. I did that because I want to keep my programming thinking alive and also learn something a little new (almost)...

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. There’s a lot of people involved here, at a quick count I see 21 crew members each with highly specialised skills for the job coming up. Did you see the guys holding the tires for the guy operating the drill Did you see the two guys at either side of the front-lift guy that is brushing (?) part of the front wing? And my favourite, from right tire removing guy. Notice how he positions his hands to minimise the movements needed to remove that tire as fast as possible There’s also a lot of specialised gear in action;...

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. I was listening to the (Swedish) podcast Väg...

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