marcusoft.net - sharing is learning


share(knowledge){ return share(knowledge++) }

What is the goal?


I’ve been re-reading The Goal. For the fourth time. And I still got that buzz from it. It’s such a great book - I recommend it to anyone interested in business and becoming more effective.

The book of course got me thinking waaay to big thoughts for my small head and I went all gaga over it and tried to convince people around me that we need to rethink why we are here etc.

This time however I dared to question the book too. I love it. So much that I think it will take me question it a little bit.

Read on ...

50 Quick Ideas on User stories


Now, if there ever was a book that filled a need this is it! I cannot count the number of teams and companies that have struggled to get user stories right - this book is packed with practical, solid, experienced based advices on how to improve how you use user stories to your advantage.

Throughout the short book the authors share their vast experience and again and again shows us that user stories is less about the tool and more about the thinking and approach to software development that follows with it.

I like the structure of each idea that gives a background, a rational and some practical advice on how to get started. Add to this the funny, informative and beautiful graphics that accompanies each idea and you end up with just an awesome book.

The book is organized in 5 parts that connects nicely into the natural software development cycle. For each of the part there’s 10 ideas that you might benefit from, or that can help you improve. To me, this book serves best as a reference book, or something that you use for inspiration when trying to solve a particular problem or situation in how user stories are used. Reading the book as prose from start to finish made it a bit hard to remember all the things I learned, for me.

That might also be my only criticism to the book; each idea leaves me wanting more. But that’s built into the format of such a short, succinct book - I guess. Luckily the authors have left us with plenty of further reading, links and a site where further discussions can be held and more material can be found.

If you ever found yourself not understanding how to fit user stories into your process, or if you think that user stories are not really worth doing - read this. It opens your eyes for more ideas and more options.

Read on ...

Evaluating my presentations... and pricing them?


I’m waiting at a train station to go back after doing 2 presentations on kanban. It’s super hot, I’m tired and it’s 2 hours to wait before my train, with AC, comes. Perfect time to write a blog post in other words. (I’m also happy, proud and healthy again after my flu - came out a bit pessimistic there for awhile).

One of the things that’s always included in my presentation is a slide that asks for feedback. “I love feedback” is my presenter notes and then I ask the people in the room to give me some.

I have experimented with a few ways to get proper and honest feedback and I wanted to share my latests experiment.

Read on ...

How would you measure that?


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?

Read on ...

What I've learned from 'How to measure anything'


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 I’ve picked up from this great book by Douglas W. Hubbard. How to Measure Anything: Finding the Value of Intangibles in Business is the name and link for the book. It’s an awesome read and I recommend anyone to read it.

This is not a review per se but rather three points that I’ve picked up from the book and that already now have helped me immensely.

Read on ...

Data you can't do anything about - what's the use?


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 is spread. Here’s a typical month. See how the Sundays is really bad (yeah, that’s the super low points). But there’s another trend here. The weeks keeps 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?

Read on ...

My post scaffolder for Jekyll


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

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.

Read on ...

Stop starting - start finishing, or else...


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

Read on ...

Always ask kenapa


At my current client we are gathering the most important data (number of customers) for the company well-being and showing it to all the staff, every morning. This is great and have proven very useful to get the attention and interest for everyone. We have spontaneous applauds 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 stared those meetings a bit different. 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

Read on ...

Showing part of Excel trend line in other diagram


I don’t consider myself a 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 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 now can 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 problem with the default, tooling suggested, ways of doing things.

I had 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 get part of a big trend-curve to show up on a diagram showing part of the data. And how we later used that knowledge to start making some interesting prognostications

Read on ...

Inspections welcome


I’ve just come back from a vaccation in Bali. Due to some fortunate overbookings we ended up in a villa that a 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. Our villa

The villa was in an area of other villas in the same class together with some upper class hotel. All of them was 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, sign that said:

Inspections welcome!
Read on ...

A good person and a bad system - my take


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.

Read on ...

How I prepare and create presentations


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 presentation. Below works for me - your milage may vary.

Read on ...

Communication debts and Brazilian office mornings


As a programmer I often end up trying to explain non-technical concepts for 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 in turn based on something that most grown-up people understands: financial debt.

Read on ...

It's just an experiment - experiments in practice


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 a no-brainer. Of course we should open it. But it serves as a good example).

Read on ...

Gods care through the Band Tune Book


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 of saying: I got you, man. Keep going. I've got you.

Read on ...

The "Don't fear audits and the news"-business methodology - with certification


If you lie you have to have great memory
Goldfish by josullivan.59
used under Creative Commons
That's a saying I've heard in a number of place. I have a terrible memory. Ah, it's great and everything, but it's sadly short. So I don't lie. I'm to stupid I have to short memory for that.

That's such a relief! I know that going in. In everything I do. I don't lie. I play it open. There - now you know too.

In fact, I would go so far as to say that it makes me better. Because since I'm playing it open it puts the pressure on me to be great and make sure that my work can take to be scrutinised and reviewed by everyone that I share it with.
It's not scary - because that is how it is from the start.

Read on ...

The time I found myself wanting stuff waiting...


One of the best and shortest explanations to what Lean really is 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 - and that's why it's famous and I'm not, I suppose :).

Basically;

  • scoring high on Resource efficiency, for example, is 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 over capacity. Just sitting around waiting until they are needed. We want much less work waiting (none that is) than our capacity
  • Scoring low-low (lower left) means that nothing gets done and there's also nothing to do. There's only waste in our process and no value gets created. The dessert if you want.
  • Scoring high-high (upper right) means that work gets done just as it's needed and everyone have just enough to do. There's no waiting times and no waste in our process. One-piece continuous flow is one example of this Nivana-like state. 

Now, with that diagram in place, we can describe Lean; Lean is a business strategy to reach the Nirvana-state by focusing on flow efficiency. That means, since it's a strategy, that there are other ways to get there. Lean is just one of them. And Lean focus on Flow efficiency.

If you think that sounded wise and good it's because it's not me; it's Niclas and Per. Buy the book and thank them.

Now I can finally write my blog post. Because for a number of years I've been teaching this, trying to focus on Flow Efficiency. Keep your stock low, limit work in process and move things fast through the process. Which made me the more surprised when I yesterday found myself saying;
This should never be empty. In fact I want as many things as possible in here. 

Read on ...

The humble blogger approach - some practical tips


I hate fights.
And arguments.
Hey, even discussions sometimes I find uncomfortable or at least boring.

Note that I try not to be a coward. I stand up for my beliefs and thoughts. But I don't like to fight about them, that seems very common today. If you wanna pick a fight, just tweet any opinion under the #NoEstimates tag and you see what I don't wanna.

From XKCD
From time to time I've withdrawn from blogging and social media. Just to get away. That might be cowardly, but I didn't see the use continuing fighting about how to approach estimation, what JavaScript data access library is better etc. The world need you and me better elsewhere.

I've stopped being the guy at the computer in the cartoon to the right. But I'm still expressing my views.

In this blog post I'll share how.
I've found a way to express my views without being a coward and in a way that will not, as easy, create arguments and fighting but rather discussions and learning. And peace in my soul.
Read on ...

Embrace uncertainty - the family version


The one talk that made the most impact of me have to be "Embrace Uncertainty" by Dan North. If you haven't seen it... You're dead to me Please view it now!

Dan North - Embracing Uncertainty from NDC Conferences on Vimeo.

The thing that stuck the most for me in there was the short, and depressing, sentence:
We are rather wrong than uncertain. 
Meaning simply that we would rather run with something that we know for a fact to be wrong than to live with uncertainty. We are very uncomfortable with uncertainty. But for those that can embrace it there's other type of control and "certainty" to be had.

Now... I'm beginning to think that this comes to us from an early age. I've done studies... the last one was this Saturday at the mall, with Albert (6).

Here's the conversation we had at McDonalds:

Albert; When is mum back?
Me: I don't know.
Albert: But I want to know when!
Me: After she's done shopping.
Albert: When is that?
Me: Told you - I don't know.
Albert: But when?
Me: In 9 minutes.
Albert: Ah. Thanks. ... That's like 2 hours right?
[She came back after 24 minutes]

I didn't have any contact with her and hence couldn't know when she would come back. Neither could she since she was looking for a specific thing. She didn't know if the store carried the item.

Albert was rather wrong (or rather fed the wrong information) than being uncertain. In a situation where the only fact was that we could not know when she came back.

Note also that 9 minutes was totally made up. And that Albert didn't have any concept of 9 minutes. It's not now. That's the only thing he cared about.

This is of course contrived. Or not. Because this conversation reminds me of many conversations I've been in, where "I don't know" simply was not accepted. This has not only to do with estimates (which I think sometimes can be useful), but let me share a conversation I've had with a high-ranking project manager at one of Swedens biggest insurance companies:

PL: So how long will it take you to finish this service?
Me: I haven't got an idea. We don't even know what it supposed to do yet. Kinda make estimating harder.
PL: But come on, give a ball park estimate.
Me: 100000 hours!
PL: Seriously! That's way to much!
Me: 4 hours
PL: Really... you don't want to do this? That's way to low?
Me: No you wrong. I want to do this - I cannot however. I know too little about the problem.

[30 seconds of silence as we were pondering our situation]
PL: So what do you think then?
Me: 458 hours.
PL: Yeah, that sounds reasonable.

And yes, the 458 was in the Gannt Chart later. And we got beaten up for missing the deadline.

Neither Albert nor the project manager (tm) could handle the uncertainty. Or could even try to look for other questions to ask that would have given them other kinds of control.
Could I?
If I cannot have the certainty you are looking for, am I willing to accept other kinds?
Read on ...