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.

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.

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.

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

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.

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.

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. 

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.

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?

Effective revisted

I'm talking a lot about effectiveness and how it difference from efficiency. This probably have to do with two things; first - the difference between these two concepts is at the heart of the lean mindset. The second fact is that I'm Swedish.

Swedish is a very poor language compared to, for example English, that is much richer. If I was to translate the first sentence of this blog post in Swedish you'll get what I mean:

Jag pratar ofta om effektivitet och hur det skiljer sig från effektivitet

Ah, the poverty! It's the same word. There's no difference... in Swedish. I've still to understand if that means that Swedes are focused on effectiveness of efficiency.

Vision statements - why not say what you REALLY mean?

I'm working with vision statements and strategic planning right now. Man - this an area that is really misunderstood and misused I think. Also, and that's what this post is about, I think it's deliberately this way in order to get some wiggle room. I don't understand that. We'll get there.

Definitions

As always I've learned a great deal while diving into this area again and here are the definitions that we are using and that I think is clarifying:

• Mission statement - Why are we here? What is our purpose? For example; Why do the Salvation Army exists in Indonesia? 
• Vision - when we are doing the mission perfectly - what would that look like? This is a dream, a target and something to aspire to. 
• Strategic plan - how will we get from where we are today to the vision? 
• Business plan - what kind of actions and resources will our strategic plan require from us? When or in which order are we planning to do the actions? 

What is this good for?

Guidance. If you read this blog you know that I'm not specifically into detail planning. I don't think it's feasible. For one simple reason; the future is unknown. It's really the only thing that we know about it - it will not be exactly how we planned it. 

However - the list above is very handy anyway I think. Most of the points are not about planning but guidance, alignment and policies for how we act. In that regard this is greatly valuable. 

Hey, it's one of those days, I even think that the last point (that is planning) could be useable. This too will show us where we planning to go. From where we are now. With what we know. 

As long as we understand that these things will change, there's no problem. 

There's a problem here

However... I found that many organisations are VERY reluctant to change these lists. To be quite frank the first point (the mission) maybe shouldn't change. That would mean to change the whole reason for the organisations existence. That is basically destroying the organisation and rebuilding it into something completely different. 

But the vision... might change. If we need to do some drastic adaptations to a new reality for example. Just imagine how the Internet has changed business models. The vision for companies like N.Y. Times and CNN I imagine shifted radically with the new possibilities in a new media.  

From Kanban in Action

Strategic plans is very interesting, I think, and here we should be prepared to change much more than the previous ... levels. This has to do with a very important part that I've wrote in italics above: "where we are today". 

This is also one of the really powerful tenants of kanban: "start where you are - change in small steps". 

The Commissioner of the Salvation Army (CEO in business terms) in Indonesia told me an old English joke that is suitable here:

A man drove up to a woman on the sidewalk, in London, and asked: 

"How do I get to Piccadilly circus from here?" 

The woman responded:

"Oh... that's hard. I wouldn't start from here" 

This is funny (or well...) because it shows that we often don't take the reality into our plans. You know what - it's out there. There's no use lying to ourselves and plan from a place where we not are now. This is how it looks, this are our financial state, these are our customers etc. Now - let's improve towards the wonderful state our vision talked about.

The last part, business plans, is just an example, suggestion in my mind. Here one could benefit greatly from the thinking behind rolling wave planning; for things that is close in the future (next week) we have more details planned, for things that further in the future we leave details out.

Remember that you hold the dial for how much details you put in there. And hence your disappointments... 

You were speaking about a problem?

Oh, forgot about that... Well the problem I have seen a lot is that people and organisations in them are very reluctant to change. About anything. Especially vision statements. 

So we write very lofty statements, with big fluffy words like "holistic", "empower", "best within selected areas", "leading" and "famous".
Often when I don't understand or if I question if what we do really fits into the vision the answer is (had this experience with many clients):

Well, you could say that holistic means... 

Best really means that we are ...

The intention of leading was more like ...

This is playing the victim blame game a bit. If it was your intention - why not write that then? How am I supposed to understand what you mean when your vision said something that was so lofty that I didn't get it the first time around?

Either it was a mistake or, you didn't want to be clear and crisp on purpose. Most organisations spend a lot of money and time doing these statements, so the it's probably not lack of competence. So why are we unclear on purpose?

The answer that comes back again and again to me is; because it's hard to change those. In some organisations the vision statement is written into the constitution. I'm in one right now. Updating the vision means that we need to reregister legal documents etc. etc.

So what? To me it's much better to be clear and understandable with the vision that to avoid work. The vision is intended to guide us and show us what to do. Please make those directions clear.

Summary

Good indicators and guides are hard to write. It's hard to get it right. But once created can prove invaluable to help and guide people in your organisation. 

What is your approach to the problem that they are hard to write? 

Do you think really, really hard and then carve it in stone write it once so that you never never have to change this again? 

Or do you change your process here so that you think hard for a short while and then make it easier to change and communicate - so that you have a living dialog about your vision and strategy. 

You choose. 

cc all the things

We are working a lot with trust and transparency in my current team. Specifically on the transparency item one "trick" we have been using is to cc the entire team in as many conversations as possible.

I picked this practice up from the Stripe company and specifically this article, which is a great read if you haven't seen it before.

Yes, they cc the whole company on everything. And I've seen this practice in action at Spotify to certain extent as well.

By now some of you need oxygen; MY GOD! My inbox will be flooded. And how could anyone be expected to read all of that?! Do these people do any real work?

There's three comments that needs to be made here, that I have repeated a lot when trying to implement this in all kinds of teams;

First; you are not expected to read or act on this. CC stands for Carbon (moahahaha!) Copy and simply means that you get a copy. I'd suggest you train the rest of your organisation in how to properly us this and DO not answer to emails that you are CC on, only to the ones sent TO you.

Secondly (related to the first); get good at using the email tool and help others to become better too. I have a very simple rule that takes everything that I am cc-ed on and just put it in a separate folder; "Inbox - CC". I read that when I have time over.

Thirdly (and most important): there's a symbolic value in sharing the information with everyone. We trust each other to let everyone in on all the things. We trust each other to act wisely with that information. We believe that more minds are better than fewer and strive to become more and more transparent with our information.

Summary

The main idea here is not that everyone knows everything all the time, but you already have that information at your finger tips. You can just find it in your email. It's already there!

We don't expect you to act on everything - but you are encourage to take part and offer your opinion in matters that are important and interesting to you.

This is where we trying to go.
CC all the things!

You already have that information.
We share everything

Some thoughts about waste and waste reduction

Every Lean practitioner goes through a phase of "waste elimination frenzy". At least the ones I've met. Ah, well.... I did at least.
This usually happen in the beginning of your Lean journey when you realise that if you can remove waste the flow would be improved and value will be created faster and more effective.

Now we go out on a hunt to find that pesky waste. Kill it! Off with it head! We search for it high and low. "This is wasteful - let's stop it!", "This report is that really adding value... I think it's waste", "Why should have this meeting/function/role/process? WASTE!"

I think this is where many Lean initiatives goes wrong. We're so focused on removing things instead of adding value. It's savings, reduction and removals where it should be improvements, values and focus on people.

From time to time I see people myself try to define waste. So we easily know what we can remove and what stays. I'm not saying that this is not fruitful, it's just ... hold on I'll get there.
Yesterday I saw a really fun and good way of having you think about what is waste and not, by Jon Terry:

Everyone is against waste. But what is it? Rule of thumb: Waste is anything that your customer wouldn't pay for if you itemized your bill
— Jon Terry (@leankitjon) October 14, 2014

I shared what I learned from David J Andersson as a good way to identify what is waste or not. It was quite the wake-up call for me, but it's a very sharp tool. David said that standup-meetings was waste, in the true Lean-sense. The agileist in me rebuked of course and then David said:

Well... if it's not wasteful it's adding value. So why don't you do more of it? Let's do it all day long? 

And I forcefully answered: "Oh yeah?! But a......aeeee..... yeah, you are correct. Sir."

What's a little waste really?

Because it's true. Standup is not directly adding value. 

Just as raising the hammer to hit the nail is not driving the nail into the board. It's just preparing to do that. But maybe, just maybe, there's a better, more effective way to drive nails into the board. Like a nail gun. Or do we need nails altogether? The value comes from the finished product, not the individual nailed boards. Maybe we should glue them together? 

Let's bring it back to standup. Most people I've met find these short meetings valuable. But they are, in the true lean-sense, waste. How can this be? 

I learned a little phrase (also from David J Andersson, if I'm not mistaken) that helped me to get this clear:

Value trumps flow, flow trumps waste elimination 

What this means is that we're first of all focusing on getting value - being effective, reaching our goal. After that to have a good flow in our system and then on waste elimination. Or in other words: if there are a way to get more value out of our system without flow (?!) we take that route. And if we can get flow with waste still present we don't need to eliminate the waste - we have flow.

Many Lean initiatives goes the other way; eliminate the waste to get better flow to get value.

What is waste elimination good for then?

I think it's important to understand that waste elimination is just a tool to make our process more efficient. But it's not a goal in itself to eliminate waste. The goal is to increase the value that the system is producing. 

Meaning that the hunt for waste should be treated as you smell the diapers of a baby (to borrow from Kent Beck and his code smells analogy):

If smell something bad you should at least investigate. It doesn't have to mean problems, but it's worth a quick check just to make sure...

Or closer to the topic at hand:

Waste in the system should at least be investigated. Maybe there's problems that are hindering us, maybe not. Better check it out. 

So the next time someone says; "I heard that Marcus said that estimating/standup meetings/[your favorite long held practice here]" you can reason with that stubborn consultant.

• Yes, but we get better flow from this (as the case of standup, due to information sharing)
• Yes, but our system is producing value faster (as might be the case of estimates... who knows)
• Ok, let's see if there's another way to write our code with less errors faster than to do TDD. I'm open to find out, if you can show me the increase in flow or value. 

Waste reduction is about becoming more efficient.... but that's not as important as becoming more effective.

Todo: Add tests ...

I added this line in a README file for one application I'm writing now. Like I have done before many times. However, for the longest time I have written my tests first, maybe not TDD or even unit tests, but I write the test first. Most of the times.

But not this time. Because I was in a hurry and I didn't think that this application would be something we'd use.

And of course we ended up using it. And creates a financial record and prints a receipt. It's kinda of important that it's correct.

It just struck me:

• how much harder it is to write the tests afterwards
• how much I change in my production code, that wasn't in place, when I go through it and test it
• how much more boring it is to write the tests afterward
• how easy and tempting it is to "cheat" and not test the hard stuff
• how hard the feeling "this is not done/safe/correct/complete" hits me in the face
• how little satisfaction I get from completing a test. It's just like paying off an overdue bill. "Yes, I should have done this before. Now it's done". 

I'm not saying that You have to write your tests first. I'm just saying that to me it's: easier, safer, less boring, gives me better discipline and more rewarding. You do as you want. 

I will never write "TODO: Add tests..." again without remember these feelings. 

The only easy day was yesterday - this is a message of hope

At my current "client" we have been employing a lot of activities to increase the number of customer we serve per day. I've blogged about this before.
Now it turns out that we have succeeded. The customers are pouring in. And the staff finds themselves with much more work than they have experienced in about 5 years. Yesterday was our best day so far and it was amazing to see the difference from a normal day;

• Everyone was moving fast - compared to sitting around waiting
• Everyone was focused - compared to not really knowing what to do
• Everyone was excited - compared to disillusioned and bored
• Everyone was tired after the day - compared to feeling tired of boredom

From Wikipedia

In the daily morning meeting the day after (today) we saw that people was tired and thought it was very stressful yesterday. I was reminded about the Navy Seals motto:

The only easy day was yesterday

In this post I wanted to describe why this is true for everyone embarking on continuous improvements and why this not is a problem, but rather a message of hope.
Under one condition...

My second book is out ... kinda

To many of my colleagues and friends writing a book is at the top of the dream list or life goals. I have been very fortunate to have done that, but quite honestly I never even dreamt that I would do it. Or that someone thought that what I had to say was interesting enough to read it.
Maybe should have realised that after 500.000 views on this blog but still...

Ok, something really strange have now happened. I have been published again. The book is called Architect book which is even more strange, since I don't consider myself an architect. At least not on the levels that this book is about.

Ugly clothing, symbols and values

Here in Indonesia most companies and organisations have some kind of uniform or at least very strict dress code. For example where I work, the Salvation Army, we have Salvation Army uniform on Mondays and Tuesdays, a set batik shirt on Wedenesdays, "pick your own batik" on Thursdays and training clothes on Fridays.

Here's a collage for you to feast your eyes on be scared by, showing some of those shirts:

I must say... most of these shirts I've found really silly and ugly. The don't sit right on me. I feel awkward.

How to make a empty diagram in Excel

If I don't write this down I will forget it before the end of the day. That right there was the reason I started my blog, ca 900 posts ago.

A couple of days ago I was, again, creating a big diagram on a whiteboard. This particular one was pretty high and a lot of data points had to go into it. It turned out to be hard and messy to both update and read.
I have done this so many times that I've lost count. I never found a great solution.
I don't want to use a small A3 report because I want everyone to see it. And I don't want to print a big A1 sheet every day, because it's to expensive.
And I don't want to use a projector because this needs to be physical and tangible. And in front of everyone everyday.

Someone suggested to print an empty diagram in a big size and then laminate it with plastic to be able to enter the data on top of the basic diagram.

"Brilliant idea - let's try it. I'll create an empty diagram in Excel and then we print it!"

I heard myself say. And after ca 2 hours I felt the need to write this blog post

...and then it moved - the greatest feeling in the world!

By Ben Currington used under
Creative Commons

Have you ever try to lift a piano?

If you have I bet you have the same experience as me; you go up to the piano and take a good hold and ... nothing. It's like it's bolted to the floor, or something (oddly enough my exact words the first time I tried to lift a piano).

This is impossible. We will never make it.
But you get one more guy and then you make another try. Maybe if someone could just slid a mat underneath ...
And you try again. 1...2...3... and ... IT MOVED!

Right there!

That split second is my favorite feeling in the whole world.
Trying really hard, and get the first little sign of that your efforts are in the right direction. When IT MOVED!

Why so sad? Can we point to improvements without making people feel bad?

"Fry complaining" by Umberto Salvagnin,
under Creatives Common

- As agile and lean practitioners, why do we always focus on the negative? "It's managements fault", "This needs to go faster", "The quality is substandard", "You don't use TDD" ... tell me when to stop...
- Because that where we have "unrealised improvement opportunities", dummy!

- But it's not very attractive and makes our "sell" much harder.
- Yeah, but it sucks! So it needs to be improved

- Is there maybe another way to say that so that the receivers doesn't feel that they suck?
- Maybe... but it's very much up to them. They still suck, are they ready to hear it or not? Also, I'm not actually telling them that they suck, of course. I just tell them that "we're looking for better".

- But that means that we're never satisfied.
- No exactly! I'm never satisfied.
- Sucks to be there... No highs... never content with where you are...
- Yeah! That's what makes me great.

I don't know. I just don't know.