I’m re-reading the Toyota Kata book right now I had forgotten how much it influenced my thinking. If you haven’t read it - go and do that now. Don’t read this post - read the book. I won’t mind.

Toyota Kata is what the author, Mike Rother, calls the mindset and practices that Toyota employs to get continuous improvement to work. Note that Toyota themselves might not recognise the term Toyota Kata, because it’s just how they do.

The book is filled with wonderful stories that shows clearly about how the Toyota mindset influence every aspect about the continuous improvement work there.

In this post I wanted to relate one such story that I meet so often in my daily work and reason a little bit why Toyota (and other lean organisations of course) navigates out of those problems with ease. Whereas I get stuck again and again.

The other week I attended a course that introduced a lean and agile mindset to a group of leaders in a company. My role was to sit back and observe (and to shoot in some of my experience during the training) - here’s one thing I observed.

At one point in time, after we’ve been through the agile manifesto and the principles, and finally the principles of Lean Software development a high ranking manager next to me raised his voice and said:

This all sounds very good. I buy all of it. Its common sense. But the one thing that I don’t get is why we realise this now. We are doing something very different than this now - have we been stupid before?

The discussion that followed was very fruitful and the people in the room learned a lot. But I wanted to go...

Have you ever said something profound and deep?

No - me neither… or rather not on purpose. Sometimes though, when I look back I both realise that some things I said was actually pretty good - and also that I didn’t really understand it when I said it.

I wanted to share such a moment with you and then explain why I think it was actually pretty good.

In this post I suggest that you should:

Lead like all the people in your team/org/companies are volunteers

The one time…

A few months back the Salvation Army in Sweden changed the territorial leader - in Salvation Army speak the Commissioner of Sweden. I happen to know both the going and coming (a couple) commissioners pretty well and really appreciate them as leaders.

However the going commissioner, Marie Willermark, was of particular help to me and...

I’ve just downloaded and started to read the Imposters Handbook., by Rob Conery. It’s a book about all those things that you don’t want to reveal that you don’t know. I most of them I should know since I have read Computer Science. But I don’t. It’s a great (in all senses of the word ≈500 pages!) read and promise to deliver even better things ahead. Go get yours now!

As I started to read it I heard a familiar voice in my head. Rob Conerys. And I just realised how much I’ve learned from him.

Dear Rob,

I first heard your name when you created a course on ASP.NET MVC for the ASP.NET-site. That technology was brand new back then. I then followed you as TekPub was started and I have seen just about everything you ever produced. I’ve also enjoyed some of the...

Before the summer I showed you how to build a Slack bot using Claudia - it’s a very simple ping command that you could run from a Slack-client. However that implementation had a flaw; if the command takes more than 3 seconds to complete it fails.

This has to do with a restriction in Slack that doesn’t allow requests to take more than 3 seconds. In my mind created a super complex and beautiful solution including me handing a message of to a queue and that I then polled and called back to… I ran out of time figuring out.

Which turned out to be a great thing, since the Claudia team not only created a new beautiful site https://claudiajs.com/ but also wrote a tutorial on this exact topic

In this post I will re-implement pingu using a delayed response as in that tutorial.

Since the first time I heard the term mob programming it has intrigued me. I love things that challenges me and me perceptions.

The idea behind mob programming is deceptively simple and yet powerful: have all the team member (3-5 seems most common) working together on one keyboard, one computer and one feature at the time. Or as Woody more eloquently puts it:

All the brilliant people in the same room working at the same problem at the same time

What struck me is that this simple idea solves many problems that I often see teams struggle with.

I’ve written before but never been full time member in a mob. However just before the summer I saw two excellent examples in action, and I have number of friends that have been full time members of a mob for more than a year. My interest with...

About six months ago I got home from the adventure of our life time in Indonesia. At the time I was actually feeling very underwhelmed and that we’ve failed in our work there.

But the more I think about it and the more I speak and write about our experiences there, and especially the mind blowing transformation we led in Rumah Sakit Bungsu - the more I realize that this is an once in a life time thing that have happened.

I’m writing a book about that journey. with my good friends at Oikosofy. But I have also given a few presentations on the topic.

This post is just an update about the progress of the work around the “Salvation Army hospital that rose again” that I’m calling it.

Presenting

I was fortunate enough to be able to present at Lean Kanban North America...

A couple of weeks ago I tweeted:

I'm not far from saying; if your #backlog contains features you've already failed. #impactmapping #userstorymapping #agile #lean

— Marcus Hammarberg (@marcusoftnet) June 2, 2016

In this post I will explain what I meant. And also give a suggestion on how to do something better. I know it’s better - I’ve tested it many times. Just this last hour to be exact :)

I’ve seen problems with backlogs that contains a (long) list of features. It often manifests itself as priorities being changed, team being precieved as non-transparent and sometimes the team feel like they are not included in what is being built.

There’s no use checking what will come next - tomorrow that’s changed anyway

is one thing I’ve heard my team member say. And

...

I’ve written a few posts on Claudia now and as often I jumped almost too early on the boat - it turns out that there’s significant improvements to both Claudia herself and the entire ecosystem around the main tool.

The main tool Claudia:

automates and simplifies deployment workflows and error prone tasks, so you can focus on important problems and not have to worry about AWS service workflows

In this post I wanted to check out a new tool around Claudia that helps you to build bots for use in chats - specifically for this post in Slack.

AWS Lambda is really cool but it leaves one of those: Oh wow… now what am I going to use this for? feeling. It’s just code that scale infinity without you having to worry about it. It’s a very open playing field.

When I started to learn about lean I naturally heard a lot of Toyota stories - it’s pretty inevitable since the whole thinking comes from there. One thing that I learned about was translated as autonomation. I was pretty sure it was a mistranslation.

But the other week when one of my team members said:

What’s the big deal of many things going on? If I’m blocked on a few items I can equally well just start a few more.

(Not his exact words but still those lines of reasoning)

At that point I saw the time to implement some jidoka (as automation is called in Japanese) in our project

What is this “jidoka”-thing really?

Ok, there’s an excellent article about autonomation on Wikipedia so I’ll just summaries it here. The jidoka concept is at the heart of continuous improvements at the Toyota.