The “Stop starting - start finishing” slogan has been the call to action for Kanban practitioners for a long time. In Stockholm, there’s even a conference each year named just that. And we used it as our first picture in the book.

It’s a great saying and teaches us a lot, and lately, I’ve got a new practical experience of the implications of “stop starting - start finishing”.

The meaning of “Stop starting - start finishing” to me, is like a guiding star and policy that we agree on in the team or in the company: here we try to complete things before we start new things.

I think it was Karl Scotland who said it like this:

“It’s not the more we start the more we finish - it’s the more we finish the more we finish.”

The...

At my current client, we are gathering the most important data (number of customers) for the company’s well-being and showing it to all the staff, every morning. This is great and has proven very useful to get the attention and interest of everyone. We have spontaneous applause when we are doing great - we have discussions (also spontaneous) on days with bad data.

After the morning meeting with the entire staff (quite literally the Morning Prayer, being a Salvation Army hospital :)), we hold a morning briefing with the extended management of the hospital.

Lately, I’ve started those meetings a bit differently. Quite simply, I just point to the diagram with the data up to yesterday and ask:

Kenapa?

The result was a bit surprising and also rewarding.

Of course (:)) Kenapa means “Why?”. Why did that data happen yesterday? Is there something special that happened?

I noticed...

I don’t consider myself an Excel expert user, but recently I’ve started to use it more and more and both come to like it and start doing some pretty advanced stuff with it. As always, this kind of knowledge cannot be had in a faked, training environment - for me it has to be something real to stick.

We have quite a lot of data for one of our hospitals that we can now get some pretty good trends from. But when I wanted to show only part of the trend line on a diagram showing part of the data … I ran into problems with the default, tooling suggested, ways of doing things.

I had to do it myself a little bit and try to extract some Math-skills from way back when. Luckily, I had good help around me…

In this post, I’ll show you what we did to...

title: Inspections welcome author: Marcus Hammarberg tags:

• Lean
• Life of a consultant
• Kanban

• Agile

I’ve just come back from a vacation in Bali. Due to some fortunate overbookings we ended up in a villa that was an oasis of tranquility and luxury. By far the nicest place I’ve ever seen, including the room I stayed in for Agile Singapore. The 3-day stay flew by but was a blessing for my soul.

The villa was in an area of other villas in the same class together with some upper-class hotels. All of them were boasting their luxury, their services, and their capacity. Some had stars on them (I don’t really know what those mean though).

I sat in our car on the way to the beach and we passed one hotel that looked small but very nice indeed. On the...

W. Edwards Deming is one the big quote-machines in the management business and one of the most often cited is this:

A bad system will defeat a good person, every time - W. Edwards Deming

It’s not only sad - it’s also true. Sadly. (Oh wow - that was an recursive sentence almost :)). I believe this and I have seen it in practice. But I have also seen the opposite. Like this:

A good person will defeat a bad system, eventually - Marcus C. Hammarberg

Let me try to clarify what I mean and what I’ve seen to support it.

Story 1

I consulted at a big Swedish insurance company for a couple of years. I was part of a team rebuilding one of their key applications (in VB.NET). Great guys and a team that I often think back of. One of the guys...

I’ve just been to Agile Singapore and had a blast. What a nice bunch of people I met there! And the event was super; fun well organised and informative - that’s all I want from conference.

I also had an opportunity to give a presentation there. It was quite some time since I created one for scratch so I took it (the opportunity) to rewrite my Kanban in Action presentation.

Some people have asked me how I create presentations and I thought that it could be good idea to write it down for myself as well. Hopefully I will do more presentations… then I can use this.

I don’t consider myself an expert on desimomomooahahahaaa (sorry could not keep a straight face… ok - once again…) on design of slides nor do I have deep communication education. I have failed a lot though and I really enjoy doing...

As a programmer, I often end up trying to explain non-technical concepts to non-technical people using things that I’ve picked up as a programmer. Often it doesn’t pay off. “Don’t Repeat Yourself” or “Tell - don’t ask” is not always easy to explain or translate, even if they hold truths and wisdom.

Today I tried to explain Technical Debt to a director of a hospital. That didn’t really work - my mistake. However, the Technical Debt metaphor is based on something that most grown-up people understand: financial debt.

In this instance, we talked about how communication could be improved (as it always could be, I would think) in the hospital. In order to explain this, I drew this graph for her:

You know about debt, right? I asked her. The longer we wait to do down-payments, the more the debt increases, due to the interest...

At my current client we’re starting to work with improvements, as I wrote about before. The things I talk about in that post is small changes, but bigger things we handle on separate lines. For now. That might change.

Today I tried to introduce an idea of experimenting to the team. Let me walk you through it, because I found that by just changing the language a little bit, we got a much better understanding and reduced anxiety. Also I think they all like it.

We are trying to bring our profitability up and hence try to find new ways to serve more customers. In this case there was a suggestion to prolong the opening hours for one department to 1900 on weekdays and keep it open on Sundays too. It’s now closing at 1400 and is not open at all on Sundays.

(Ok, it’s a bit of...

We break for something different. This is not my normal IT/agile/lean post. It’s about God and his care for me

Happy that you continued to read.

I’ve been having some hard days at work. I was very angry and it affected not only me but also those around me. Also I was being affected physically with dizziness and head ache. For the first time in my life I found it better to go home and cool off a couple of days.

I felt so tired and was beginning to doubt if I’m really doing the right thing. In the right place.

So I did things that pick me up. Playing hymns on my euphonium is one of those things. My playing is closely related to my faith, since I’ve made most religious experiences with my instrument in hand, playing in the most cases.

What happened this time was Gods way...

One of the best and shortest explanations of what Lean is really about, I’ve found in the “This is Lean” book by Niclas Modig and Per Åhlström.

The thing that made it “click” for me was a diagram that contrasted Resource efficiency with Flow efficiency. I love it! Even though I might have talked about Efficiency versus Effectiveness… Well, it’s not my book—maybe that’s why it’s famous and I’m not.

Basically:

• Scoring high on Resource efficiency is, for example, a melting plant for steel. You want that running all the time. You keep a lot of material ready to be processed because the plant is so expensive to shut down.
• Scoring high on Flow efficiency is, for example, the fire department. Most of the time they have enormous overcapacity, just sitting around waiting until they are needed. We want much less work...