I’ve been very much into Specification by example in my software development consulting. One of the key learnings for me there is to try to make things concrete earlier. Using specification by example we do this by, for each of the features we’re building, sketching down some concrete examples on how that would work.

For example; let’s say that we are building a on-line store and the business rule says Shipping is free for order with 3 items. That’s pretty easy, right? We all have a good opinion on how that rule should be… but is it the same opinion?

When Joakim and I wrote the book we had a chapter on measurement in it, chapter 11 - “Using metrics to guide improvements”. It was intended to show a few ways that metrics can be used in a flow-based process that uses kanban for improvements.

When we wrote it I happened to show it to Torbjörn Gyllebring since he’s very sincere in his criticism. His first words:

You can’t write a word about measurements if you haven’t read “How to measure anything”

When you have not read that book and writing a lot of words on measurements… hearing that has a bit of a “DOH!”-effect on you and your writing. But Joakim had and that made me feel a little better. I was largely satisfied with the chapter too.

But now I have read it and I wanted to share some of the main points that...

Just a short post about data and a common objection. At my current client, we have a lot of data about the customers (patients at a hospital) that we serve each day. We have measured the same way for about 4 months now so it’s pretty accurate.

Lately, I started to see a trend about how the patients are spread. Here’s a typical month. See how the Sundays are really bad (yeah, that’s the super low points). But there’s another trend here. The weeks keep falling - I thought at least. The Mondays are always best and the number of served patients gets lower and lower.

What can we learn from that?

Verification

First, I verified my hypothesis by proper analysis. I created an Excel formula that went through all our data and calculated the average per weekday.

There’s an Excel formula...

I’ve just started to use Jekyll as my blogging engine. It’s mostly nice but I’m getting used to a new tool. And maybe actually the lack of tools since it’s just markdown and git.

One of the things that I found early to be a stumbling block was to create a new post. Since I’m still fresh to the structure of the YAML front-matter, I found myself copying and pasting, missing and misunderstanding.

So I looked for a post generator and found this gist that is used, at the command line, to scaffold up the structure of a new blog post.

Let me show you how I tweaked it and a problem that I ran into, being a newbie.

Tweaking the script

I’m very much a newbie in bash script files so bear with me and please enlighten me if this can be better.

First of all,...

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

I’ve just come back from a vacation in Bali. Due to some fortunate over-bookings 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 wall, nothing was said about their services, no stars or anything like that. Just a simple, but big,...

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

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 organized 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 design … hahaha (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...