tag:blogger.com,1999:blog-14230034296326949992024-03-18T10:47:21.300+01:00Lean und KanbanThoughts on Lean and Kanban. Follow me on Twitter: @arneroockArnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.comBlogger74125tag:blogger.com,1999:blog-1423003429632694999.post-78362736315104218322019-05-29T14:43:00.000+02:002019-05-29T14:43:05.804+02:00Thoughts on Hierachies (Part 1): In the Dojo<i>I‘ve been wrestling with the topic of hierarchies quite a while, wrote several drafts for blog posts and deleted all of them. Now I figured that maybe the issue was that I was trying to write one grand blog post, where I would express all my thoughts on hierarchies. But the topic feels too big for me, and there are still so many things I haven‘t managed to wrap my head around. So I decided to slice the topic into smaller chunks and start publishing whatever might be good enough already. So here‘s the first part of a series of posts that are to come later.</i><br />
<br />
In the good old days, I used to train karate a lot. And I remember one day a read a newspaper or something and spotted an ad, which caught my attention. It read something like this:<br />
<br />
"Karate is a great martial art and can be a very useful means for self defense. At the same time, the way it is practiced is very hierarchical. In our courses, we will teach you karate in a non-hierarchical, participatory way."<br />
<br />
Back then I just shook my head and didn‘t think about it too much. But recently I remembered the ad and found it quite interesting. The authors obviously thought hierarchy is inherently evil and needs to be avoided at all cost. An assumption I don‘t agree with - neither in general, nor specifically when it comes to karate.<br />
I believe hierarchy in itself, like most organisational structures, is neither good nor evil. It can be more or less appropriate or helpful in a given context. It will come with certain costs and certain benefits. And it can used in a more or less helpful way.<br />
<br />
Let‘s look at hierarchy in karate. Yes, it‘s true, the hierarchy is very obvious in the dojo: we have a master and we have a group of students. They are not treated as equals during the training sessions. And then there‘re the different levels of expertise, which are indicated by the color of the students‘ belts*. In the beginning and at the end of every training session, the group lines up in a standardised formation: The master on the one side, the students on the other. And the higher a student‘s belt, the farther to the right this person stands. So just by looking at the line-up, you can clearly see the hierarchy. During the training sessions, the hierarchy will also be reflected in the way people behave. The master tells the students what to do, and they do it. They don‘t question what the master says. There‘s no debate and no participatory decision making. And since a lot of the exercises are done in pairs or small groups, and the master cannot be present in all groups at the same time, the student with the highest belt becomes the proxy master in his/her absence. The same is true, if the master cannot show up for a training session: The student with the highest belt will lead the training session, no questions asked (unless it‘s a group of children and/or absolut beginners).<br />
<br />
If you just look at the things I have just described and if you are suspicious of hierarchies, then it‘s understandable why this might be a turn-off. But this is only one part of the picture, and by only looking at this, you would be missing at least two other, critical aspects.<br />
<br />
1) Practicing karate means practicing dangerous techniques. Discipline, strict rules and hierarchies are means to make the practice <b>safe</b>. One of the main assumption here is that the person, who‘s highest up in the hierarchy knows best how to guarantee safety and will do her/his best to keep everyone safe. Based on my experience this works quite well, in more than 2,000 hours of training, I have been injured once, and I have witnessed maybe one dozen other injuries.<br />
<br />
2) You cannot understand the aspect of hierarchy in karate, without looking at the whole system. One other widely important aspect of karate is <b>respect</b>. Looking at hierarchy in Karate in isolation, without connecting it to respect, will show you a completely flawed picture. Respect is deeply engrained in every karate session. Every training session starts and ends with a ceremony, where people bow, in oder to show respect. Respect towards their master, their peers and the art of karate. Every kata, every sparring situation, any kind of excercise really starts and ends with a bow. This is a recurring gesture, which signals respect and means: "I respect you, I see you as a partner (not as an opponent), I want to learn with and from you, and I will do my best to keep you safe."<br />
Why is respect so important, when looking at hierarchy? Because it guarantees that a master will never misuse his/her authority. Respect is based on reciprocity: It‘s required that students show their respect to the master, and the students can be sure the master respects them as well and will always act in their best interest.<br />
<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimO-pvFfelbpcAMLDMQQIPA1A0Hw3bQNbdEmASy3yw6nZFBIS_4fqJKoZnbr3wsvK-i-Yo13v2PE37TeGLL7h0NdWzXMFecvobs6P9UxbK3KMnG6Pe31qva20c4jpNIEP_ltvQlRPXY0Q/s1600/Karate_web.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1498" data-original-width="1000" height="640" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEimO-pvFfelbpcAMLDMQQIPA1A0Hw3bQNbdEmASy3yw6nZFBIS_4fqJKoZnbr3wsvK-i-Yo13v2PE37TeGLL7h0NdWzXMFecvobs6P9UxbK3KMnG6Pe31qva20c4jpNIEP_ltvQlRPXY0Q/s640/Karate_web.jpg" width="427" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Photo credit: <a href="https://www.zielecki.com/">Christian Zielecki</a></td></tr>
</tbody></table>
<br />
Of course I know that a karate dojo is very different from a business organisation. I am not advocating for using the karate system in our work environment. So what can we learn from all this, when it comes to hierarchies in a business context? When I reflected on this, I took away two general insights:<br />
1) Hierarchy is not inherently good or evil. It serves a purpose, and we should evaluate the usefulness of hierarchy based on how effective it is in serving this purpose (and what the costs are).<br />
2) It can be too simplistic to look at hierarchies in isolation. We need to view it as a part of a bigger system and look at the other elemenst of that system as well as the interactions between the elements.<br />
<br />
* Technically this is not 100% correct, it‘s the kju ranks, which indicate the level of expertise, not the belt color (you could have two people with brown belts and different kju ranks). But since the mapping is almost 1:1 and for the sake of simplicity, I use belt colors in this post.<br />
<br />
<br />
_______________________<br />
<br />
<i>Are you interested in organisational structures? Then you should check out my posts <a href="https://www.software-kanban.de/2016/04/an-alternative-view-on-company.html">An alternative view on company structures</a> and <a href="https://www.software-kanban.de/2019/04/results-only-work-environment-rowe.html">Results-only Work Environments (ROWE)</a></i><br />
<br />Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com7tag:blogger.com,1999:blog-1423003429632694999.post-14665700048141770992019-04-25T17:18:00.001+02:002019-04-25T17:18:24.745+02:00Results-Only Work Environment (ROWE)Recently I have been doing quite some reading on remote work. In one of the books I was reading, the author suggested adopting ROWE to make remote work easier. I had heard about ROWE 10 years ago but then almost forgotten about it. It sparked some thoughts and after brief conversations with <a href="https://henningwolf.de/">Henning</a> and <a href="https://stefanroock.wordpress.com/">Stefan</a>, I feel these thoughts are worth sharing.<br />
<h2>
What is ROWE?</h2>
ROWE is, of course, an acronym. It's short for "Results-only Work Environment". I am not going into details or the history of the concept - <a href="https://workplacepsychology.net/2017/01/04/results-only-work-environment-rowe/">this blog post by Steve Nguyen</a> gives a good overview.<br />
The basic idea of ROWE is pretty simple: Results are all that counts. It does not matter <i>when</i> people work; it does not matter <i>where</i> people work; it does not matter <i>how</i> people work - as long as they deliver the desired results.<br />
It‘s easy to understand why this concept is appealing to Agile folks: It gives a lot of autonomy (back) to the employees and frees them from micor-management and stupid policies. To my understanding ROWE was developed as an alternative approach to being paid and evaluated simply by how much time someone spends in the office. That surely makes a lot of sense. And it explains why ROWE got quite some traction in government agencies and big, old-school corporations. <br />
<h2>
Problems with ROWE</h2>
We all want great results. So what‘s not to like? Reading through some articles, the main areas of criticism seem to be that a) It‘s very hard to create a shared understanding of the desired results and how to measure them; and b) contrary to proponents‘ claims, ROWE does not always reduce working long hours. Some studies indicate it can have the opposite effect and actually harm work-life balance even more than traditional work environments (see "the Risks and Obstacles of ROWE" in <a href="https://workplacepsychology.net/2017/01/04/results-only-work-environment-rowe/">Nguyen‘s post </a>for sources). <br />
These concerns sound legit to me, but in this blog post I want to stress a different concern, that is probably as serious as the ones already mentioned. I use ROWE as an example, but the critique holds true for any kind of hands-off management that focuses entirely on results/targets. My main concern is:<br />
<br />
<i>ROWE totally ignores methods and therefore makes organizational learning very hard (if not impossible).</i><br />
<div class="separator" style="clear: both; text-align: center;">
<i> </i><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3GKHp8ePg98j1tL6Cz42vOujRtVn6S7BiOeMAhJgg1Dc3Rry6GvmS-ojGCoc2k7BEhWBMN5Q4QIBLxCHiDGE4VrrPSrRdHQ2KPnMt6HOQ11RhiZ35FQY6a2gL-yCYPH5r8Wt9Eu5HbvM/s1600/Folie6.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" data-original-height="540" data-original-width="720" height="300" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi3GKHp8ePg98j1tL6Cz42vOujRtVn6S7BiOeMAhJgg1Dc3Rry6GvmS-ojGCoc2k7BEhWBMN5Q4QIBLxCHiDGE4VrrPSrRdHQ2KPnMt6HOQ11RhiZ35FQY6a2gL-yCYPH5r8Wt9Eu5HbvM/s400/Folie6.jpg" width="400" /></a></div>
Imagine you are running ROWE in a small company. You as a CEO are quite happy with the results. Your clients are also happy, and you earn a lot of money. Now you want to grow the business and hire a bunch of new people. How do you onboard them? Sure, you can agree on desired results with them and hope for the best. But chances are that at a certain point you will not be happy with the results anymore. What do you do now (other than fire people, because they are "under-performers"? How do you train people, if you have no understanding which methods work in which situations and which don‘t? How do you make sure co-workers will learn from each other, if there is no structured conversation about methods? Learning and scaling the business becomes incredibly hard in this situation. And for employees who struggle with their work (for whatever reason) it becomes very frustrating, because there will likely be no structured mentoring.<br />
And it gets worse. Deming advised managers always to ask "By what method?" whenever someone bragged about their achievements. He stressed the importance of a solid method you can learn, teach and iterate on. If you don‘t do this and purely look at results, you are rewarding luck and unethical behavior. <br />
<h2>
Conclusion</h2>
Yes, we want to keep methods as lightweight as possible. But let‘s not throw out the baby with the bath water and abandon them all together. Without solid and explicit methods there will be no organisational learning, and personal development of the employees will be sub-optimal. ROWE might sound appealing at first glance, because it emphasizes individual autonomy, but it does exactly that: neglecting the methods that can (repeatedly) lead to great results.<br />
<br />
<br />
P.S. If you liked this blog post, you should check out my <a href="https://www.software-kanban.de/2016/04/an-alternative-view-on-company.html">post on company structures</a>.<i><br /></i><br />
<br />Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com1tag:blogger.com,1999:blog-1423003429632694999.post-81628085334000175512019-03-05T15:25:00.000+01:002019-03-17T19:47:23.205+01:00Lean-Agile Roast: SAFe<span id="docs-internal-guid-f6a30ad4-7fff-4d9d-fcb6-6ed5c2a33272" style="font-family: "arial"; font-size: 11pt; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">I </span><span style="font-family: "arial"; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">know </span><a href="https://www.linkedin.com/in/erikschon/?originalSubdomain=se">Erik</a><span style="background-color: transparent; color: black; font-family: "arial"; font-size: 11pt; font-style: italic; font-variant: normal; font-weight: 400; text-decoration: none; vertical-align: baseline; white-space: pre;"> </span><span style="font-family: "arial"; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">and </span><a href="https://www.linkedin.com/in/hakanforss/">Håkan</a><span style="font-family: "arial"; font-style: italic; vertical-align: baseline; white-space: pre-wrap;"> for almost ten years now, and they both have an impressive track record of Lean and Agile. Not only do they deeply understanding the concepts, but they also are true practitioners and have driven substantial change in various big organizations. Since I have moved to Stockholm in 2017, we get to meet and talk more regularly. In several of these conversations we touched the pros and cons of the </span><a href="https://www.scaledagileframework.com/">SAFe Framework</a><span style="font-family: "arial"; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">. We agreed that we would need a longer discussion to properly discuss the topic, so I invited them, and we recorded our conversation, which went on for over an hour. When we had drinks later that evening, Håkan said that he felt like he was been roasted (of course in a very friendly, a very Swedish way). </span><span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-style: italic; vertical-align: baseline; white-space: pre-wrap;">Although this was not our intention, we all agreed that it would be a great concept:-</span><i>) So I give you the first part of our Lean-Agile Roast on SAFe. You can check out <a href="https://medium.com/@erik_schon/lean-agile-roast-safe-part-2-8e387ae0a045">part two of this Lean-Agile Roast on Erik's blog</a> and <a href="https://hakanforss.wordpress.com/2019/03/07/lean-agile-roast-safe/">part three on Håkan‘s blog</a>.</i></span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><span style="font-style: italic; vertical-align: baseline; white-space: pre-wrap;">If you prefer to listen to the whole conversation, you can </span><i><span style="font-family: "arial" , "helvetica" , sans-serif;"><a href="https://drive.google.com/file/d/1Q0UeIRKC3sGBN5uLpGTbE9Ejmk7zisnE/view" target="_blank">download the audio file here.</a></span></i></span><br />
<div>
<div dir="ltr" id="docs-internal-guid-1419dc6b-7fff-1703-dede-9357df278369" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-style: italic; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTglud02TI4EhKVTYHSefFuDfb1wghyqD6XmOy-QlG60gvQPaRGJM9JXmEKRSpx2dKNUb8_mCyxZvzkFPMuYwm_Jdj029OGZntjMBs3Cm5NeZjwilIeyMx9VTzF0tUr1xh9BBtiXgstvk/s1600/Liquorice_Allsorts_in_a_glass_bowl.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="1122" data-original-width="1600" height="448" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiTglud02TI4EhKVTYHSefFuDfb1wghyqD6XmOy-QlG60gvQPaRGJM9JXmEKRSpx2dKNUb8_mCyxZvzkFPMuYwm_Jdj029OGZntjMBs3Cm5NeZjwilIeyMx9VTzF0tUr1xh9BBtiXgstvk/s640/Liquorice_Allsorts_in_a_glass_bowl.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><i><span style="font-size: small;">SAFe: A big bowl of candy? (Image credit: <a href="http://elcome%2C%20h%C3%A5kan%20and%20erik%20to%20our%20little%20conversation%20about%20safe.%20i%27m%20happy%20to%20have%20you%20here.%20i%20would%20like%20to/" target="_blank">Wikipedia</a>)</span></i></td></tr>
</tbody></table>
<div dir="ltr" id="docs-internal-guid-1419dc6b-7fff-1703-dede-9357df278369" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">(<a href="https://medium.com/@erik_schon/lean-agile-roast-safe-part-2-8e387ae0a045">Part 2</a>, <a href="https://hakanforss.wordpress.com/2019/03/07/lean-agile-roast-safe/">Part 3</a>)</span><br />
<span style="font-family: "arial"; font-size: 11pt; font-style: italic; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<div dir="ltr" id="docs-internal-guid-74eb4c1c-7fff-70ad-bc9d-561669f75a7e" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Welcome, Håkan and Erik to our little conversation about SAFe. I'm happy to have you here. I would like to start with a question for Håkan. A lot of people from the Lean/Agile community are kind of suspicious about SAFe and you have just become a certified SAFe trainer. How come?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Håkan: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Yeah that's right. I was moving to a big Swedish insurance company and they had taken some initial steps in that direction. And from a personal point of view a lot of the principles and the values that are stated in SAFe are something that I totally agree with. So therefore I didn't have any problem to actually explore being a trainer and help train people around us, because I think if you train them with a focus on principles and values then the method would follow as you learn more and more.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">I believe this has been about six months. What have been your experiences so far?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Håkan: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">I'm really impressed by the depth of the material. I might not agree with all the details but there's a lot of intellectual property that is really useful to get started. And also there is what is called the implementation roadmap. In there it's described how to actually do the implementation, which has been very helpful to hold people back and not just throw themselves into the implementation without learning first.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" id="docs-internal-guid-1419dc6b-7fff-1703-dede-9357df278369" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-style: italic; vertical-align: baseline; white-space: pre-wrap;"></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Erik you have been more on the other side of the spectrum, when it comes to SAFe. What are your concerns?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<div dir="ltr" id="docs-internal-guid-024aca99-7fff-509f-46ee-f32a11f9e3c1" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Erik: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Well, I think way back SAFe and I got off to a bad start. It wasn't even called SAFe at the time. This was in 2010/2011 and I was a big fan of Don Reinertsen, the author of </span><a href="https://www.amazon.com/Principles-Product-Development-Flow-Generation/dp/1935401009/ref=sr_1_1?ie=UTF8&qid=1550417331&sr=8-1&keywords=reinertsen+flow" target="_blank">Principles Of Product Development Flow.</a><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> He recommended us at the start of our </span><a href="https://medium.com/@erik_schon/the-mental-leaps-more-faster-better-happier-more-innovative-df6ca5ca53e7" target="_blank">Lean/Agile transformation journey</a><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> to read Leffingwell's book <a href="https://www.amazon.com/Agile-Software-Requirements-Enterprise-Development-ebook/dp/B004JLMUJU/ref=sr_1_1?ie=UTF8&qid=1550417262&sr=8-1&keywords=leffingwell+requirements" target="_blank">Agile Software Requirements</a></span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">. So I started reading it, but I couldn't finish it! And that very seldomly happens for me that I can't finish a book. It was not to my liking, not to my taste. So we got off to a bad start and we took a different path to scaling. Our ways of working with large scale Scrum systems was inspired by the Lean community and by Kanban -- we were always trying to learn and to get inspiration from several sources. I found the book a bit dogmatic and it felt like a bag of goodies: a lot of good stuff but no consistency, no real depth. And it was hard to get to the essence, that was my initial impression. But bear in mind: I see a lot of skilled people who know the principles, and they work with the SAFe framework and they get it to work really well. So if you know what you're doing, if you're a practitioner and you know the principles I guess you can make any framework work. Because then you start from the needs and you start from from your context, and then you tune and tweak the framework to suit those needs.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">When I prepared this conversation I remembered that Schiller once reviewed a book and wrote: “This book contains many new things and many good things. Unfortunately the new things are not good and the good things are not new.” And I was thinking you could say the same thing about SAFe: It contains many new things and many good things. But the new things are not good. And the good things are not new. Does that make any sense to you both?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Erik: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">I think that's a very interesting summary. I have to admit that I haven't dived into all the details or taken any training. So I've looked at it from the outside. Still, I've seen a number of companies, that were on their journey and talked to people, who were part of that journey. Your description seems fairly, consistent with what I hear. Håkan, I would like to hear your view on that since you're in this now.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Håkan </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Yes I think there's not a lot of new stuff in there.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Is there valuable stuff in there?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Håkan: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">You could say it's a framework that embraces everything that has seemed to work at some point. Which could be a problem. But it also actually puts it together in a way that it should work together, if you actually are using the principles and the values. From my point of view there is nothing that is really, really new and SAFe is just a way to communicate the ideas to an audience that is not necessarily knowledgeable about this area. If I go to the CEO of my company, they might not even know the concepts of Lean and Agile, but you can talk to them around this material in a way that they understand what it could potentially look like in the future.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Why do you think SAFe is so successful.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Erik: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">I would say it's very neatly packaged. It comes in a box and it's very easy to explain to upper management. And it solves a real need. It fulfills a real need to deliver faster and that's a legitimate need. I really think it is. In that sense it helps a lot of companies that would otherwise struggle quite a bit.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Håkan: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">And I think one of the biggest values that it brings is that it is great in communicating the ideas. So there's lot of good stuff and it's well presented, so you can just use it and you don't have to reinvent the wheel. You can take the ideas and build on it. And that's been a great support in many situations, where you might not yourself have developed the training material around a certain area. There's a lot of help from that framework itself.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">We had a conversation this morning at the </span><a href="https://www.meetup.com/Stockholm-Lean-Coffee/" target="_blank">Stockholm Lean Coffee</a><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">, where we discussed the idea that maybe the main purpose of SAFe is just to help organizations deliver big projects or programs. And this it does really well. So if you look at it this way it's a really good tool. But a lot of people are assuming that what it should be doing is also enabling an organization to develop their own ways of working. And this is probably not what SAFe is intended to do. Would you agree with that?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Håkan: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">You could say something similar about Scrum, right? So from my point of view Scrum has one rule that rules them all, which is inspect and adapt. So I'm someone, who would say I'm a very proud Scrum-But. And I think that's the same idea about SAFe. There are built-in mechanisms to actually adjust and make changes. You can change the core values and principles as well, as long as you are actually doing what is in that rule which rules them all. You should always inspect and adapt. I don't see a problem in that sense.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Erik: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">But isn't there a risk, since the SAFe is such a big framework, that this fundamental rule gets lost, because you see all the other good stuff? And then you might miss out on the fundamental thing, which is to inspect and adapt, the improvements, the continuous learning. All those things. Because you're so busy just understanding and grasping the framework that is so big.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Håkan: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Sure. But then there's a lot of material that prescribes the kind of meetings and so on in a similar way as the Scrum framework would do. One important part of that is that you should measure things - that you should evaluate at the end of the Program Increment (PI). And you should look at the bigger picture and optimize the bigger picture and not the individual parts. So if you actually are following a lot of the material that is described, you are at least on a path of that learning. But of course you can get lost just like you can get lost in just doing Scrum by the book and not applying inspect and adapt.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Would you say that the one rule that rules them all is the same in SAFe: inspect and adapt?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Håkan: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Yes I would.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Erik: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Would the C-suite also formulate it that way? If you would ask that question to upper management, what would they answer? Why would they use SAFe? Is it because of inspect and adapt, or is it for some other reason?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Håkan: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">No, no, no. They want business results. And I guess that's the same thing if you would implement Kanban or XP or whatever. They are not particularly interested in the method itself. But they want the actual business results and I think that's a very similar thing with SAFe. You need to deemphasize the idea of the SAFe framework itself, it's the business results that we are after. And it's clearly stated what they expect the business results would be by implementing SAFe.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Another aspect we discussed this morning was that a typical manager, who is not the owner or the founder of a company is usually not incentivized to think ten years ahead or even five years ahead. So the incentive is to deliver stuff. And this is where SAFe could be helpful. But the incentive is in most cases not: in five years from now or in ten years from now I want this to be a real learning organization. And this is maybe a little bit tricky, because on the one hand we would like organizations to be more like learning organizations, on the other hand it seems very hard, because why would it be in the interest of a manager to invest in the future and then everyone else would say: "Oh this is a weird person. What is (s)he doing?" I think you have maybe similar thoughts, Erik?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Erik: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">Yeah. That's a really really tricky. I mean being a middle manager myself and having been in that situation: How do you progress without being seen as a UFO or sort of alien? And if you're too alien you might get shut down. So of course you want the sustainability to be there for the company for the long term. And you also want to deliver results, and that is a very tricky trade-off. You want to do both, and I think ultimately it will come down to learning some new patterns and un-learning some old patterns and re-learning. And different frameworks and different philosophies can emphasize that more or </span><a href="https://less.works/" target="_blank">LeSS</a><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> - pun intended. So I think that's my take.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">There is a lot of stuff in SAFe. And if you look at the poster it can be a little bit overwhelming. My friend Henning likes to make this joke: He shows the SAFe poster to people and then asks them: " Where's Waldo? Where's the customer?" Because there's a tiny spot, I think on the bottom left or something, where you can find the customer. At least it's not very prominent. And so I guess there's also a risk that you lose the customer out of sight, because there's so much process and so many roles and artifacts. Is that something you've seen?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Håkan: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">If you follow the implementation roadmap of SAfe (which has some great tools in it by the way), one of the things that you do before you get started is to do a value stream analysis. You then identify how you set up your organization and your Agile Release Trains. What we have found with the work that I've done so far is that this type of work has not been done that much before. So by going through that and actually looking from that lens we actually put more emphasis on the customer and ask what customer value is, before you get into defining the Release Train and the delivery organization. So I actually found it to be a little bit opposite. That this helps upfront with thinking about these things in an organization. So from my point of view it really has helped to take that perspective even more. And then on the portfolio level the suggestion is to use prioritization and scheduling based on </span><a href="http://reinertsenassociates.com/" target="_blank">Don Reinertsen‘s</a><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> principles around cost of delay, which also put the customer in the focus. So there's a lot of mechanisms in there which are leaning towards a very high customer focus. So I actually found it to be helping to put those things in the front seat, instead of something that you can potentially introduce to the organization later on.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">I can can totally understand why it's tempting for a manager to implement SAFe. If I try to put myself in this person's shoes, where I'm managing an old school company and I see that we have to change, that we need to become more agile. Now I see that there's this framework called SAFe, and it has a lot of interesting stuff and has this implementation handbook and everything. So that sounds great, and I would probably want to buy it. Erik, what would you do in this situation if you would be this manager, but you didn't want to implement SAFe? How would you start such a journey?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Erik: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">I'm thinking about acting your way into a new way of thinking, acting your way into a new mindset. We were struggling quite a bit with this in the beginning of the journey in the part in Ericsson where I worked. We had two thousand people at ten different locations in our product development unit. And we were thinking about the whole transformation approach and asking ourselves: Should we do that like an implementation project with a plan and a roadmap and all the steps predefined? We were going back and forth and ultimately we thought that if we want to change our way of working, then we should change our way of changing first. So we didn't come up with a big project plan. We had a one pager showing the rough direction where we were going. We had a few principles and we started moving. So I think that the whole approach to change is pretty important: As a manager in the organization, do you start with yourself and then do the whole transformation approach differently? Or do you do it the traditional way, where you have the risk that you will continue to do things the way you've always done them? Then you don't get into the inspect and adapt and improvements loop. That's my fear. My respect goes to all skilled people, who know the practices, who are practitioners and who know the principles. They are of course aware of this and will tune and tweak things. My fear would be that it's too easy to start with the classic way of driving change: to have all the big plans upfront and then start executing to implement the new new framework. Many organizations, if not most of them, have done that several times and they get bored or fed up with it. And then this becomes the new fad and there will be no real change, because the managers will not change their way of acting. And then they will not change their way of thinking and then you're back to square one after some time -- that will be my fear. So what would I do? I would do something similar to what we did, in addition to everything I said. Having a group of people, who are formal or informal leaders and let them work together as a cross-functional team, meeting regularly to inspect and adapt. Visualize what they do, lead by example and then act. Act your way into new thinking and have full transparency for all the other teams and all the people in the organization to see what you're doing. Also have working sprints or whatever iterations you have, to walk the talk.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Arne: </span><span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;">And with with all your skepticism about SAFe do you see any good parts?</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;">Erik: As we... [to be continued]</span><br />
<br />
<span style="font-family: "arial"; font-size: 11pt; font-weight: 700; vertical-align: baseline; white-space: pre-wrap;"><span style="font-family: "arial"; font-size: 11pt; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">(<a href="https://medium.com/@erik_schon/lean-agile-roast-safe-part-2-8e387ae0a045">Part 2</a>, <a href="https://hakanforss.wordpress.com/2019/03/07/lean-agile-roast-safe/">Part 3</a>)</span> </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; vertical-align: baseline; white-space: pre-wrap;"><br /></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 11pt; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">Curious to hear more about Håkan‘s experiences with SAFe? How it relates to estimates and Kanban? Why Erik thinks it‘s like a black hole and what Marie Kondo has to do with it all? Then check out <a href="https://medium.com/@erik_schon/lean-agile-roast-safe-part-2-8e387ae0a045">part two of this Lean-Agile Roast on Erik's blog</a> and <a href="https://hakanforss.wordpress.com/2019/03/07/lean-agile-roast-safe/">part three on Håkan‘s blog</a>. </span><br />
<span style="font-family: "arial"; font-size: 11pt; font-style: italic; vertical-align: baseline; white-space: pre-wrap;">Thanks, <a href="https://twitter.com/henningwolf">Henning Wolf</a> for the idea that led to this conversation! </span></div>
</div>
Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com53tag:blogger.com,1999:blog-1423003429632694999.post-87349214730391798722018-10-11T19:33:00.000+02:002018-10-12T15:10:56.200+02:00The Bias that cried WolfIt was a couple of months ago, when I first came across this image, showing a big group of wolves traveling in the snow.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4KgPybe1akFFcctj3YOsb9rtVK1rbhq4TYalP1sBM9Or9VdeGyOLfRiz2ps-ik5LZkGTO4yINOmnvdMH8J_5EZVz4MetSONdB3H79PumBdozG3Z5F-dZ5Rj7UKVDlqmMnpwVEiq5nd3o/s1600/Wolves.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="720" data-original-width="1280" height="360" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh4KgPybe1akFFcctj3YOsb9rtVK1rbhq4TYalP1sBM9Or9VdeGyOLfRiz2ps-ik5LZkGTO4yINOmnvdMH8J_5EZVz4MetSONdB3H79PumBdozG3Z5F-dZ5Rj7UKVDlqmMnpwVEiq5nd3o/s640/Wolves.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><div style="font-size: medium; text-align: start;">
<i>Source: <a href="https://www.youtube.com/watch?v=OT2TAp3Jcgg" target="_blank">this youtube video</a> (although it appears to be a still from BBC´s "Frozen Planet" from 2011)</i></div>
</td></tr>
</tbody></table>
<br />
The picture comes with a description about the structure of the group: The weakest individuals in the front, followed by the strongest ones to protect the group from an attack from the side. In the very back we are supposed to see the leader of the group, who makes sure no wolf is left behind and the whole group travels in the right direction.<br />
Since then I came across countless versions of this picture&story, packaged as a lesson in leadership. The take away usually comes as some variation of: "Great leaders are servant leaders."<br />
<br />
When I first saw this picture, my initial reaction was:<br />
<br />
<b>Wow, this is so powerful! I am totally going to share this with all my followers!</b><br />
<br />
Luckily, I did not do this immediately, but looked at the comments first. And (what a surprise!) it turns out the description is complete nonsense. Whatever we see on this picture, it is not what the author wants us to believe. So my second reaction to this picture was:<br />
<br />
<b>Oh crap, this is fake! I am glad I checked before I distributed this even further.</b><br />
<br />
A couple of days ago, I saw this picture again, and this time I had a different thought, which now makes much more sense to me:<br />
<br />
<b>Why on earth should human leaders be able to learn something from a group of wolves?</b><br />
<br />
I mean, seriously, am I the only one who thinks this is ridiculous? Even if the description was correct: so what? It might be an interesting fact for everyone, who is interested in wildlife. But what makes us think we could transfer insights from this to our daily work? Last time I checked, we all were humans working in corporations, not wolves roaming Alaska. These two scenarios can hardly be more different. I guess nobody would use wolves as role models, when it comes to diet ("Rotten carcasses are good for you!") or other behaviors ("Wolves teach us that we should always sleep naked in the snow!")<br />
But there is something about this specific leadership narrative that makes it so appealing to (some of) us: We <i>want</i> to believe that it is true! Or, to be more specific: Those of us, who believe in a certain school of leadership, want this story to be true - because it reaffirms our belief. This certainly applies to me. Now that I reflected on this, I realized that I wanted this story to be true so badly, that all my rational safe-guards were bypassed within the blink of an eye.<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxZvw1lJz0gD2i2NRBDdJFhel39h2iOuRNlSXbn3qjmM-ByVavPBBJDq7m0NvHPHrgNWZLyI1lOY8Ewp6fPFEyNRR5MeubypDDwdW_RjE4gPC0cDdlow_U71cNatvaiCR9ux0nfJzlmCM/s1600/Wolves_Eating.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="800" data-original-width="1200" height="425" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhxZvw1lJz0gD2i2NRBDdJFhel39h2iOuRNlSXbn3qjmM-ByVavPBBJDq7m0NvHPHrgNWZLyI1lOY8Ewp6fPFEyNRR5MeubypDDwdW_RjE4gPC0cDdlow_U71cNatvaiCR9ux0nfJzlmCM/s640/Wolves_Eating.jpg" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><i>Source: <a href="https://commons.wikimedia.org/wiki/File:Timber_wolves_fighting.jpg" target="_blank">Wikimedia</a></i></td></tr>
</tbody></table>
<br />
The reason I am posting this is because I believe this is a great example of how powerful biases (in this case: confirmation bias) can be - and how sneaky. In this example I was not only biased to (almost) share a fake story on the internet, but also to neglect the obvious differences between wolves and humans. And then there is of course the echo chamber problem: Even if the story would be true, and I had shared it, then only people within my filter bubble had seen it. These people mostly share my believes, so chances are that they would have liked the story very much and shared it once more. But would that really help our course of advocating servant leadership? I doubt it. At least I have a very hard time imagining someone with a very different view on leadership seeing this picture and thinking: "Wow, this is how wolves are leading. I will totally change the way I lead people in my organization!"<br />
<br />
<i>P.S. If you are interested in cognitive biases, you should check out my posts on <a href="http://www.software-kanban.de/2017/09/thoughts-on-confirmation-bias.html" target="_blank">confirmation bias</a>, <a href="http://www.software-kanban.de/2016/11/thoughts-on-groupthink.html" target="_blank">groupthink</a> and <a href="http://www.software-kanban.de/2017/08/thoughts-on-survivor-bias.html" target="_blank">survivor bias</a>.</i>Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com2tag:blogger.com,1999:blog-1423003429632694999.post-27437775586691806172017-09-23T17:45:00.000+02:002017-09-23T20:47:23.669+02:00Thoughts on Confirmation Bias<i>This post is part of a series on cognitive biases. You might also be interested in my thoughts on <a href="http://www.software-kanban.de/2016/11/thoughts-on-groupthink.html" target="_blank">groupthink</a> and the <a href="http://www.software-kanban.de/2017/08/thoughts-on-survivor-bias.html" target="_blank">survivor bias</a>.</i><br />
_____<br />
<div style="text-align: center;">
<i style="text-align: right;"></i><br />
<div style="text-align: right;">
<i style="text-align: right;"><i style="text-align: right;">"People have no trouble turning any information into a coherent narrative." <br />Jason Dana</i></i></div>
<div style="text-align: right;">
<i style="text-align: right;"><i style="text-align: right;"><br /></i></i></div>
</div>
<h3>
Zener Cards</h3>
J.B. Rhine, the founder of parapsychology, was convinced that ESP (<i>extrasensory perception</i>, ie receiving information with the bare mind, instead of the known senses) exists. In the 1930s and 1940s he conducted hundreds of experiments to prove his claim. Amongst other things Rhine invented a card deck called <i>Zener Cards</i>. A deck comprised of 25 cards with one of five different symbols on each card. The "sender" (often Rhine) looked at a card, while the "receiver" (a person potentially capable of ESP) had to guess the symbol on the respective card. If people would just randomly guess, they would get an average of five correct answers. When a person scored way above five, Rhine saw this as prove for ESP. Over time, Rhine thought he had found people, who were extraordinary good at ESP, because they consistently scored above five.<br />
Millions of people believed Rhine‘s research, he sold lots of books and got funding after funding. However, later it turned out that his methods and his data were completely screwed. Rhine was so desperate to prove his claim, that he went through his data over and over again, until he finally found what he was looking for. For instance, when a promising "receiver" seemed not to perform well enough in a series of tests, Rhine found what he called "forward displacement". This means that the "receiver" did guess the correct answer, but his/her guesses were "displaced", so that he/she did not guess the actual card, but the upcoming one. Another obscure phenomenon Rhine discovered was what he called the "decline effect". When a receiver started promising, but then failed to continue his/her correct guesses, he/she must have been fatigued or bored (and therefor the results must be discarded). Probably the most absurd claim Rhine made was that whenever people scored <i>above</i> average, they clearly were capable of ESP; and when they scored <i>below</i> average, this too was proof for ESP, because they used their ESP skills to embarrass Rhine!<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7z_PXH26HNBa-LHk83PxoHlWAOFE8uurFr4vcGh2e3xazAoJbNSbOitmVKVIYokrynWsiTosCpZvqMrnbVIlV7WyJHTDbDG_w1VgHB84WkWydujbnCl3mZeR3mXcGXQF0xWnMjlGT_Ow/s1600/Hubert_Pearce_with_J._B._Rhine.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" data-original-height="498" data-original-width="751" height="424" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh7z_PXH26HNBa-LHk83PxoHlWAOFE8uurFr4vcGh2e3xazAoJbNSbOitmVKVIYokrynWsiTosCpZvqMrnbVIlV7WyJHTDbDG_w1VgHB84WkWydujbnCl3mZeR3mXcGXQF0xWnMjlGT_Ow/s640/Hubert_Pearce_with_J._B._Rhine.png" width="640" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;"><table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td class="tr-caption" style="font-size: 12.8px;"><i>J. B. Rhine with one of his "receivers", Hubert Pearce. Source: Wikipedia</i></td></tr>
</tbody></table>
</td></tr>
</tbody></table>
I‘ve learned about Rhine and the Zener Cards from reading the great book <i><a href="https://www.amazon.com/Standard-Deviations-Assumptions-Statistics-2015-07-21/dp/B01N8YDW2J/ref=sr_1_4?ie=UTF8&qid=1506178084&sr=8-4&keywords=standard+deviations" target="_blank">Standard Deviations</a></i> by Gary Smith. The story is a striking, yet extreme example of <i>confirmation bias</i>, "the tendency to search for, interpret, favour, and recall information in a way that confirms one's preexisting beliefs or hypotheses" (<i>Wikipedia</i>). One interesting thing about Rhine is that there‘s no strong evidence that he intentionally cheated. He thought his methods were totally valid. And he was without any doubt a smart man.<br />
You‘ve probably seen lists of dozens of cognitive biases. While it turns out that some of them are so context-dependent that it‘s questionable how useful they really are (and others could not be replicated in subsequent experiments), it appears to me that there‘s no real doubt that confirmation bias exists and that it seriously impacts our behaviour and decision making. We are all affected by confirmation bias, even if we think we would be better able to deal with it than others. For a vivid and astonishing example (there‘s a magician involved!), watch this video. You will get to know c<i>hoice blindness, </i>which is very close to confirmation bias IMO.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<iframe allowfullscreen="" class="YOUTUBE-iframe-video" data-thumbnail-src="https://i.ytimg.com/vi/tuEGoAabL9o/0.jpg" frameborder="0" height="426" src="https://www.youtube.com/embed/tuEGoAabL9o?feature=player_embedded" width="512"></iframe></div>
<br />
<br />
<h3>
Why are we affected by confirmation bias?</h3>
It‘s not entirely clear why confirmation bias (and similar effects) seem to be hardwired into our brains, but there are some explanations that make sense to me:<br />
<ul>
<li>In <a href="https://www.wired.com/2011/05/the-sad-reason-we-reason/" target="_blank">this article</a> Jonah Lehrer links confirmation bias (and similar phenomena) to our ability to persuade others, which is a critical skill for humans as social beings. In that sense there‘s a lot value in our brain finding more and more arguments for our point, so that the rest of the group follows or supports us: "the function of reasoning is rooted in <em data-reactid="283">communication</em>, in the act of trying to persuade other people that what we believe is true." </li>
<li>David McRaney suggests that confirmation bias might has offered an adaptive advantage to humans as a species He gives the example of a caveman being out in the woods. He has a hunch that there are cheetahs out there, which is obviously dangerous to him. He therefore looks for clues that confirm his hunch. In cases like this it‘s generally much better to go with confirming information, instead of looking for disconfirming information. Or as McRaney puts it: "It‘s better to be wrong than to be dead." (<a href="https://youarenotsosmart.com/2017/07/20/yanss-103-desirability-bias/" target="_blank">You Are Not So Smart Podcast, episode 103</a>) </li>
<li>Sarah Gimbel and Jonas Kaplan from the University of California point out that relatedness is extremely valuable for humans. Whenever we change an important belief, we put this relatedness to our peer group at risk. So although it might make sense to change a belief from a rational, individual‘s perspective, it might be to costly from a group perspective.<br />Gimbel and Kaplan also explain that important beliefs can become part of our identify, and threatening this beliefs triggers very similar reactions in our brains than eg meeting a bear in the woods.</li>
<li>Kaplan adds two more interesting views on this: Firstly, mental models need some level of stability to be useful in the real world. Therefore we need to balance the influence of new information with this need for stability. Secondly, new information ist not stored independently in our brains. We don‘t simply add another piece of information, but instead we connect it to other information we already have. So changing one piece of information could cause a "chain reaction" and might not be worth the effort. (Listen to this excellent <a href="https://youarenotsosmart.com/2017/01/13/yanss-093-the-neuroscience-of-changing-your-mind/" target="_blank">episode 093</a> of the You Are Not So Smart Podcast with Gimbel and Kaplan.) </li>
</ul>
Whether or not these theories can be backed up by more research in the future, there‘s strong evidence that humans have a hard time dealing with <a href="https://en.wikipedia.org/wiki/Cognitive_dissonance" target="_blank">cognitive dissonance</a><i>:</i> When our beliefs don‘t match our behaviours, we tend to become psychologically uncomfortable. Therefore we strive for internal consistency, either by changing our behaviour or by justifying it (or avoiding situations in which this inconsistency becomes evident). Changing our behaviour seems extra hard, one reason being that when we do change it, we‘ve created another inconsistency, because our current behaviour deviates from our past behaviour. Therefore oftentimes we justify our behaviour by looking for more and more confirming data and neglecting disconfirming data. Confirmation is not a big problem with minor or relatively unimportant beliefs, but it really kicks in with "cherished beliefs", those beliefs that are linked to our core identity (for many people religion or politics).<br />
It gets weirder: in <a href="https://youarenotsosmart.com/2010/06/23/confirmation-bias/" target="_blank">this blog post</a> David McRaney writes about a study from 1979, which suggests that "even in your memories you fall prey to confirmation bias, recalling those things which support your beliefs, forgetting those things which debunk them."<br />
The internet does not really make things better. As Justin Owings points out in <a href="https://justinowings.com/confirmation-bias-and-the-internet/" target="_blank">this blog post</a>: "Thanks to Google, we can instantly seek out support for the most bizarre idea imaginable. If our initial search fails to turn up the results we want, we don’t give it a second thought, rather we just try out a different query and search again. [...] People have always been prone to confirmation bias, but the Internet amplifies the phenomenon since we need not look far to confirm our particular bias. It’s always a click away.” That‘s also the reason why it‘s almost impossible to win an argument online - the other party will always find websites which support their opinion.<br />
<br />
<h3>
What can we do about it?</h3>
The research on confirmation bias is not new, and most people have heard about at least some of it. Yet I am amazed by how little we talk about the impact of confirmation bias (as well as other biases) in our community. One reason for this might be a phenomenon called <i>Bias blindness</i>, which means that we underestimate the effect that biases have on us compared to others.<br />
If only a small part of the research about confirmation bias is valid, we are wasting tons of money by making flawed decisions in any part of our organization: Should we hire this person? What product should we develop next? Should we invest in a new market? etc.<br />
So what to do about it? Obviously I don‘t have the silver bullet and research shows that it‘s incredibly hard to overcome or even dampen cognitive bias. But I really think we should talk more about these things and share ideas. Here are some of my thoughts on how to fight confirmation bias, please share yours in the comments section):<br />
<ol>
<li>Whenever we hear someone (our ourselves) say things like: "I knew it! Here‘s yet more evidence that XY is correct!", we should be cautious and try to look out for confirmation bias.</li>
<li>I think it‘s important to institutionalise a process in which we come up with criteria for success and failure (or better: confirming or disconfirming data) <i>in advance</i>, i.e. before we start with a project, initiative, etc. "How will we know we are successful?", "What are signs of failure?", "At what point will we re-evaluate what we‘re doing or stop it all together?" are good questions to discuss (I believe this is called <i>Preregistration</i> in the scientific community). What happens instead (and I am guilty of doing this many times) is this: We are very enthusiastic about a thing and really want it to succeed. So we start a project and invest time and money. After a while the data shows that the desired effect does not occur. But instead of questioning what we are doing, we start looking for other "great" effects we can observe: "Yes, sales did not go up after implementing this feature, but look how much this blogger liked it! So let‘s do more of it." In this case we not only deal with confirmation bias, but most likely also with the <a href="https://en.wikipedia.org/wiki/Sunk_cost#Loss_aversion_and_the_sunk_cost_fallacy" target="_blank">sunk cost fallacy</a>.</li>
<li>Writing things down often helps. By grabbing a piece of paper and writing down our assumptions, we can create a commitment, which makes it harder to justify contradicting actions afterwards. The story goes that Warren Buffett admired Charles Darwin‘s approach to confirmation bias: "Charles Darwin used to say that whenever he ran into something that contradicted a conclusion he cherished, he was obliged to write the new finding down within 30 minutes. Otherwise his mind would work to reject the discordant information, much as the body rejects transplants. Man's natural inclination is to cling to his beliefs, particularly if they are reinforced by recent experience--a flaw in our makeup that bears on what happens during secular bull markets and extended periods of stagnation." (<a href="https://www.forbes.com/sites/rogerdooley/2013/05/07/buffett-confirmation-bias/#61eab9161685" target="_blank">source</a>) </li>
<li>Have someone take the role of <a href="https://en.wikipedia.org/wiki/Devil%27s_advocate" target="_blank">devil‘s advocate</a> is always a good idea, especially with big decisions. In addition, it‘s often beneficial to invite known critics to voice their opinion. Warren Buffett, again, is known for inviting his critic Doug Kass to challenge his investment plans (<a href="http://fifthperson.com/2-examples-of-why-you-must-challenge-your-confirmation-bias-when-investing/" target="_blank">source</a>). </li>
<li>On a related note David Rock points out in <a href="https://neuroleadership.com/portfolio-items/break-bias-decide-september-2017/?mkt_tok=eyJpIjoiTURNM1lqVTNZMkprTm1JNCIsInQiOiJ6WGJMOUh6bWhCZFdya0RBQk9QMUZwZTQ5b1NEWHdOeE9lMlwvVVwvVjRJQ2ZVQWZTckRLczRrbGpnWnR4c2x6OHI5ZXNYVmdyNlJvTXYyZkxVT0l5ZllNdmhwd1B3djhSOThYME1qR1ZTd2RwTWpDZUVhbHVnQmtlMXdMQ3NFWTRvIn0%3D" target="_blank">this webinar</a> that it‘s a good idea to fight bias as a team. Rarely all members of a team need to be involved in actually making a decision. So some of them can focus on observing how the decision is being made, share their observations and trigger a discussion about the biases at work.</li>
<li>It‘s good to keep in mind that often people are not as rational as we think (or wish for). If we wonder why someone is insisting on his/her opinion, despite all the evidence against his/her point, chances are that we won‘t convince this person by adding more arguments. In fact, this could result in this person insisting even more on his/her option. This is called the <a href="https://rationalwiki.org/wiki/Backfire_effect" target="_blank">backfire effect</a>.</li>
<li>If someone seems to behave irrational, we should not assume he/she is an idiot. It‘s almost always a good idea to take a break and let heated discussions cool down. From what I understand the <a href="https://en.wikipedia.org/wiki/Prefrontal_cortex" target="_blank">prefrontal cortex</a> plays an important role in what we call rational behaviour. Unfortunately, this part of the brain is easily tired. So give it time to "recharge", before making important decisions.</li>
<li>Taber and Lodge have found evidence for what they call the "Attitude strength effect": Subjects voicing stronger attitudes will be more prone to confirmation bias. (for a summary of the study see <a href="http://intelligence.org/files/CognitiveBiases.pdf" target="_blank">this PDF document</a>.) One conclusion from this might be that we should not expect someone to change his/her opinion, when this very person has just talked about this very opinion with utter conviction. In this case it might be a better idea to take a break and continue the conversation in a smaller group.</li>
<li>The way most people (me included) search for information seems to be problematic. When we do research, we often use a search engine to find what we are looking for, or so we think. But knowing a little bit about confirmation bias, I tend to believe that we are rather typing in what we already believe and/or what want to be true. I remember searching for phrases like "Kanban success stories" or "Lean cycle time reduction". And of course I will find what I was looking for. But what if I would search for phrases like "Kanban does not work" or "Lean is is fad"? Wouldn‘t I find completely different results? I now try to make it a habit to search for disconfirming results on Google. But what can I say? It‘s hard...</li>
<li>We all know the term <i>filter bubble</i> and some of its implications. We might call social media a big confirmation bias machine. The first problem is that we are only connected with people who are mostly like us, meaning they probably share most of our cherished beliefs. So I don‘t even get to hear disconfirming data. The next problem is that I get rewarded, whenever we post something that confirms our group‘s beliefs. For this we will be instantly rewarded in the form of likes, retweets and positive comments. So our beliefs are being re-affirmed and strengthened all the time. If we want to change this, we might want to consider following/friending people on social media, who are different from us and have very different opinions/beliefs. I‘ve done that, and it‘s interesting but it can also be very exhausting. </li>
</ol>
<ul>
</ul>
<div>
These are some ideas I have about mitigating confirmation bias. I will soon publish another blog post on debiasing strategies in general.</div>
<div>
<br /></div>
<div>
If you want to dig deeper, you might want to learn about biases that are closely connected to confirmation bias. Here‘s a list I‘ve compiled:<br />
<br /></div>
backfire effect, belief bias, belief preservation, belief overkill, choice blindness, desirability bias, frequency illusion, hypothesis locking, morton's demon, motivated reasoning and motivated scepticism, myside bias, non-falsifiable hypothesis, polarization effect, positive bias, selective thinking, Tolstoy syndrome<br />
<ul>
</ul>
<div>
<br />
P.S. Of course the belief that confirmation bias exists is also affected by confirmation bias. I‘ve at least done some googling and searched for phrases like "confirmation bias is not real", "confirmation bias is overrated" etc. I did not find any useful information.</div>
Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com2tag:blogger.com,1999:blog-1423003429632694999.post-78986210558382615392017-08-13T12:12:00.001+02:002017-09-23T17:51:28.394+02:00Thoughts on Survivor BiasOver the course of the past years I‘ve become more and more interested in cognitive biases, how they affect our work and what could be done to mitigate them. A couple of months ago I‘ve published my <a href="http://www.software-kanban.de/2016/11/thoughts-on-groupthink.html">thoughts on groupthink</a>. Today I want to share some thoughts about <i>survivor bias</i>. I believe it‘s hard to exaggerate the effect of this bias, but at the same time it seems to be relatively unknown in our community.<br />
<br />
<b>Never give up!</b><br />
For whatever reason Facebook decides to show me these "motivational" pictures with "deep" messages every now and then. Yesterday I saw this gem:
<br />
<br />
<br />
<br />
<div style="text-align: center;">
<img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEitZ3UyUV34Ql5O4Ad6gBgIxS3qVMrl_KDu0WFEr0l_hZ_ii2GI52Bsl5-5nSFToG7ZTFBBpNkY-cQJ9VlILHzPDdRtlA4Q5_hyufsA58oVTuXfc47ZJC5WgdyaD94cQ02bmT10H6wSgSg/s320/Never-Give-Up.jpg" /></div>
<br />
<br />
Seems like good advice. It must be good advice to never give up, if this was the secret sauce for Coca-Cola‘s success, right? Of course it‘s not! It‘s pure survivor bias. Just as well you could ask a millionaire what her recipe for success was and then she would reply: "Quit your job, sell your house and your car, go to the casino and bet everything on number 12! That‘s exactly how I got rich." Of course that‘s bad advice, but unfortunately this is exactly how many business books and other guidebooks work.<br />
We‘ll come back to this later, but first let‘s hear about a story from World War II.<br />
<br />
<b>Abraham Wald</b><br />
The Hungarian statistician Abraham Wald was part of a group of geniuses, who helped the US win World War II with weapons of mathematics. The group was called "Applied Mathematics Panel", and there‘s a <a href="https://youarenotsosmart.com/2013/05/23/survivorship-bias/">wonderful article on this group, written by David McRaney</a>. One task the group was assigned to was to figure out how to improve the armor of allied bombers. It was clear they needed extra protection (too many were destroyed in combat), but it was unclear were exactly to put the additional armor, and protecting the whole plane would make it too heavy. So commanders examined the planes that returned from battle and looked at the bullet holes. It was easy to spot patterns (one obvious one was along the wings), so they concluded to add extra armor at exactly these places. Fortunately, Wald was involved in solving this problem, and his clear thinking probably saved hundreds of lives. He concluded, that the exact opposite of this had to be done: improve the armor at the places where no bullet holes could be spotted. His reasoning went like this: The planes we get to see here all have survived the battle, so they have done pretty okay. But all the planes who did not return from combat would have needed extra protection, because they had been hit at all the places we don‘t see at our planes here.<br />
<br />
<b>Survivor Bias</b><br />
Wald‘s story perfectly explains what survivor bias is:<br />
<br />
<i>The logical error of concentrating on the people or things that made it past some selection process and overlooking those that did not, typically because of their lack of visibility.</i> (Wikipedia)<br />
<br />
It would be easy to smile at this story from World War II and just carry on. But survivor bias has serious implications for almost all areas of our professional and personal lifes. Here are some examples:<br />
<ul>
<li>Ever heard someone say this: <br />"The quality of XY nowadays is so crappy. I have a really great 20-year old XY, but they don‘t make these anymore"? <br />I‘ve certainly said something like this many times. However, chances are that this statement is not true. In fact, the quality of many things has drastically improved over the last decades. They‘ve made a lot of crappy items in the past as well, but they all have disappeared, so that only the (few) good ones have survived. Or, if you look at it the other way around: They build good ones and crappy ones today, but we haven‘t figured out yet, which ones are the good ones.</li>
<li>We tend to believe that the cities of eg the Renaissance must have been really beautiful, and all the art of this time was extraordinary. This must be the case, because all the buildings and all the art from the Renaissance we get to see is very beautiful. But of cause we never get to see all the ugly buildings, paintings, songs etc., because they were torn down, cast away, not passed on and not talked about in history books.</li>
<li>Social media is a big survivor bias machine. Whenever I browse through my Facebook stream, I get the impression that all my friends have spectacular lifes, while mine is nothing but boring. Wherever I look: Happy people with a drink in their hands (one with an umbrella!), travelling the world, chilling at the beach in wonderful weather. At least two survivor biases at work here: 1) People only take pictures when the skies are blue and the wine is plenty. 2) People tend to only post spectacular stuff. They rarely post pictures of them being bored on a cloudy day. <br />In the case of social media, events "survive" the processes of photography and social media posting only if they are interesting and colorful.</li>
<li>I do not understand a lot about mutual funds, but I stumbled on <a href="http://finance.martinsewell.com/fund-performance/EltonGruberBlake1996a.pdf">this paper</a>, whose authors claim that "[a]lmost all prior mutual funds studies suffer from survivorship bias".</li>
<li>Ever heard of this anecdote? When cats fall from a balcony, they have a bigger chance to survive, when they fall from a greater hight! The data for this conclusion was drawn from the observation that cats that were brought to the vet had greater injuries if they had fallen from 1-6 stories, compared to cats who had fallen from higher than six stories. One explanation given was that whenever cats fall from a greater hight, they have enough time to spread their legs and use their body as some kind of parachute. Sounds amazing, but perhaps the more reasonable explanation for this phenomenon is this: Cats who fall from higher than six stories are rarely taken to the vet, because they did not survive the crash or, if they do, their owners don‘t find them or do not have any hope for cure.</li>
</ul>
These are just some examples from very different areas, and the list could go on and on. What all these stories have in common is that the conclusions we draw from the data are backward looking: We look at a set of visible data and conclude what must have happened in the past. That seems reasonable, but as Gary Smith claims in his book Standard Deviations: "When we chose a sample today and look backwards, we only see the survivors" and that those studies often suffer from survivor bias. From a scientific standpoint we should have done the following to conduct serious, forward looking research: Take 100 random cats, for each one toss a coin, throw half of them from the 3rd story and the other half from the 8th story and then see which group has the greater injuries. No, I am in no way proposing actually doing this, but you get my point:-)<br />
<br />
<b>Great Companies</b><br />
Now what has all this to do with the Lean/Kanban community? I think one serious implication is best illustrated by Jim Collins‘ best-selling book "Good to Great". Collins compares eleven "great" companies and then finds a set of seven characteristics all these companies share. His conclusion is that he has found the recipe for success and if you use this recipe, your business will be successful as well. Gary Smith points out that Collins‘ approach is pure survivor bias, because it‘s backward looking. Collins only looks at companies that still existed at the time of the writing of his book. So we have no way of telling how many other companies did the exact same thing but went bankrupt anyway. Smith also points out that the eleven "great" companies do not perform that great anymore: Between 2001 and 2012, these companies combined did worse than the overall stock market.<br />
<br />
Now if even Collins‘s work (who worked as a Stanford professor) is affected by survivor bias, we can be sure that many, many other articles and books are as well. So we should be very careful, whenever we read something about "the 10 things that all successful managers/teams/organizations do" or the like. Plenty of these writings exist in our community, as well. I am not suggesting that these stories are useless. I find many inspiring ideas in them, many worth trying and adapting. I just disagree with the (implicit or explicit) conclusion that we, too will become successful by doing the same thing.<br />
<br />
P.S. I‘ve also written a <a href="http://www.software-kanban.de/2017/09/thoughts-on-confirmation-bias.html" target="_blank">blog post on confirmation bias</a> you might also enjoy reading.<br />
<br />Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com14tag:blogger.com,1999:blog-1423003429632694999.post-66655689032418646142017-03-07T13:44:00.001+01:002018-10-14T16:26:08.929+02:00Kanban and the Post Office<i style="background-color: white; color: #727272; font-family: times, "times new roman", serif;">This is a translated and modified version of my article "Wie bei Kanban die Post abgeht", which was published online at Projektmagazin in February 2015. If you prefer German, you can </i><a href="https://www.projektmagazin.de/meilenstein/projektmanagement-blog/wie-bei-kanban-die-post-abgeht_1097593" style="font-family: times, "times new roman", serif;" target="_blank">find the original German article here</a><span style="font-family: times, "times new roman", serif;">.</span><br />
_____________________<br />
<span style="background-color: white; font-family: "arial" , sans-serif; font-size: 14px;"><br /></span>
<br />
<span style="background-color: white; font-family: "arial";">Once I was with a company, that had freshly started using Kanban. Peter, the CEO was happy with what they already had achieved and proudly presented their board to me. Indeed I was impressed with how far they had come in such a short time without having much external expert support! </span><span style="background-color: white; font-family: "arial" , sans-serif; font-size: 14px;">The board roughly looked like this:</span><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBe8PnnIqBZ3nGDO1Sh8uFOxXUIWHgk1ef_qsdBBYqXnhXT8SQgf1T8HkoR3ZB8Z31W6cURkPtk256ySGZR1ALj7iv5xI659GHL0MWySbUFocBY4MLZT2Mk76y-e6bKpmSoD7q_uZEWD0/s1600/Folie1.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgBe8PnnIqBZ3nGDO1Sh8uFOxXUIWHgk1ef_qsdBBYqXnhXT8SQgf1T8HkoR3ZB8Z31W6cURkPtk256ySGZR1ALj7iv5xI659GHL0MWySbUFocBY4MLZT2Mk76y-e6bKpmSoD7q_uZEWD0/s1600/Folie1.jpg" /></a></div>
<span style="background-color: white; font-family: "arial" , sans-serif;">Sipping our coffee, we had a chat about Kanban in general and their board in particular. After a while I asked about the problem with queues in the post office. My conversation partner looked in me in disbelief, so I started from the beginning.</span><br />
<br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">"When I was a kid", I said "every post office was organized in a way that each counter had its own queue. If you had a package to ship, you had to decide for one of the queues and line up - of course it always was the wrong choice, because it turned out that all other queues were serviced much faster. Today, post offices are organized differently. Usually, you‘ll only find one central queue for all counters. Only shortly before its your turn, you‘ll be directed to the next available clerk. Why is this? This system offers at least three major advantages:</span><br />
<ol>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">Predictability improves significantly. In the old system, it happened quite frequently that I had lined up in a specific queue only to discover later, that the person in fron of me had a very complicated issue he wanted to discuss with the clerk. Bad luck! The same thing happened, if my queue was served by a trainee, who (of course) was way slower than his/her colleagues. Certainly these things happen in the new system, as well. But here trainees and complicated requests have different ramifications, because the delays are split amongst all the customers, so to say. This is called "using pooling to buffer variability". Needless to say that this improved predictability and unified wait times lead to higher customer satisfaction.</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">The new system is way more reliable. Imagine one of the clerks needs to leave his/her counter, because he/she is needed elsewhere. In the old system, this had caused severe disturbance, because the queue now had to be distributed amongst the other queues. But by what mechanism? Should the customers just line up at all the other queues? And wouldn‘t that be unfair, because they had already waited in the disintegrated queue? In the new system, it‘s still annoying, when a counter is being closed. But the impact for the overall system is rather low. Nobody has to be redirected. The wait time for all customers gets a little bit longer, but nobody feels treated unfairly, because the additional wait time will be evenly distributed amongst all customers.</span></li>
<li><span style="font-family: "arial" , "helvetica" , sans-serif;">The new system is less stressful for the clerks. In the old system, every clerk had to serve each of his/her customers, before he/she could close the counter and leave work. Everyone had "own" customers and should have felt responsible for them individually. In the new system, all the clerks work as a team and share responsibility for all the customers. If someone is having a rough day (or difficult customers), his/her team mates will compensate for this automatically."</span></li>
</ol>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<ol>
</ol>
<h3>
<span style="font-family: "arial" , "helvetica" , sans-serif;">
Keeping an eye on the queue as a whole</span></h3>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">During my little monolog, Peter had been nodding a lot, so ha seemed to agree with all this. After I had finished, he directed his gaze to the board again and started thinking out loud: </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">"In our context, the tickets on our board are the customers in the post office, each with different requests. Our team members are the clerks, who deal with the requests. A finished ticket is the equivalent of a served customer (hopefully a happy one!) At the moment we assign people to tickets right from the beginning, everyone has his/her own queue and is responsible for dealing with it. This means we are working in the old post office system. When I think about it, I have witnessed all the disadvantages you have just described. So for us, too, one joint queue should be a much better solution. But for this our board had to look differently."</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">He grabbed a marker, went to a nearby flip chart and started to sketch a modified version of the board. </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVaHh7gUgkq38ztidKNnHPlit0hBB8SAw357gO1agb7rz3KGA-oQXa_mo8NlPyiQYSS7wdYX8HYTenBpxGNVRonNxPED5OhRYajwCTOmFJu6sgYEonQ9gHAAUTqa3YndOU1W-uHzsPIpk/s1600/Folie2.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjVaHh7gUgkq38ztidKNnHPlit0hBB8SAw357gO1agb7rz3KGA-oQXa_mo8NlPyiQYSS7wdYX8HYTenBpxGNVRonNxPED5OhRYajwCTOmFJu6sgYEonQ9gHAAUTqa3YndOU1W-uHzsPIpk/s1600/Folie2.jpg" /></a></div>
</div>
<div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">For the columns "To Do", "Next" and "Done", the swim lanes had disappeared. They now only existed for the activity columns "Dev", "Test" and "Deploy". It seemed like a small change, but I think it was a big step in the right direction towards more flexibility, collaboration and knowledge sharing. </span><br />
<h3>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span><span style="font-family: "arial" , "helvetica" , sans-serif;">Holes in the input queue</span></h3>
<span style="font-family: "arial" , "helvetica" , sans-serif;">I then nudged Peter a little bit more and asked: "What about holes in the "Next" column?" Again, he seemed to be puzzled, so I elaborated: "I guess, that the tickets in the "Next" column are prioritized by some sort of mechanism that makes sure the tickets with the highest value (or best value-cost-ratio) are on top of the queue and the less valuable ones are at the bottom, right?" Peter nodded, so I went on: "Now what happens when, let‘s say Stefan is done developing a ticket and wants to pull the next one from the "Next" column? Of course, he should pull the one at the top of the queue." </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">I grabbed a marker and wrote "1" on the top ticket, "2" on the next one and so on. "Unfortunately, I am pretty sure that in many cases that will not happen. And the cause for this is specialization. That‘s probably the reason why you have the swim lanes in the first place. So if ticket 1 requires a specific skill, which Stefan does not master, he will leave the ticket where it is and pull ticket 2 instead. Now after a while Inken wants to pull a new ticket. But again, she‘s lacking the required skill for ticket 1. She doesn‘t feel comfortable pulling ticket 3, either, so she pulls ticket 4. Does this scenario sound realistic?" </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">Peter nodded his head thoughtfully. He knew where I was getting at and changed his sketch of the board again. At this point it looked like this:</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgm9SLXT0fkXKoRUXrIlTPymldSINOBwM_V4uFgEDNVam47fpVnf_1BpS-A_02JujtKwADDyV2J-lPGDSDO3ilh1p2QkXYVZ-P_0WNQApN6KU_Rtcqfmn7JgpdWLaakjykugcEqAqLDicg/s1600/Folie3.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgm9SLXT0fkXKoRUXrIlTPymldSINOBwM_V4uFgEDNVam47fpVnf_1BpS-A_02JujtKwADDyV2J-lPGDSDO3ilh1p2QkXYVZ-P_0WNQApN6KU_Rtcqfmn7JgpdWLaakjykugcEqAqLDicg/s1600/Folie3.jpg" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Before I could go on, Peter started speaking, and he said the exact same thing I was about to say: "This is a disaster! From a business perspective, these "holes" are an absolut no-go, because they mean we are delaying the most important tasks/projects, while we are working on less important ones. We cannot have this!" </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">While he paused, I explained, what I had seen many times before: "Yes, I agree. But here comes the catch: If you want to make sure the most important tickets are always being worked on, the company has to invest in this new way of working. And depending on the degree of specialization, the technology you use, your code base etc. it might be a quite high investment. The board helps, because if designed appropriately, it will show you how far you‘ve come at any time. But of course, the sole visualization will not be enough. You will probably have to train your staff and collaboratively develop policies that make sure you gradually improve."</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">"Of course, I understand", Peter said (and he looked a little bit depressed). "I will start working on this tomorrow. Do you have any other advice on how the board can support us in this effort?" </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<h3>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Some more ideas for improvement</span></h3>
<span style="font-family: "arial" , "helvetica" , sans-serif;">I paused for a moment and thought about this. Then I replied: "In my experience it‘s mostly unfavorable to have swim lanes (or columns for that matter) named after specific people, because it tends to perpetuate the current division of work. It might be a good idea to have the specialization written at your swim lanes instead. The specialization might be a technology, a project, a product etc. And if you decide to do so, it might be a good idea to have avatars for each team member to indicate who‘s working on which item. The advantage of avatars compared to swim lanes is that they are more fluid. It‘s easier to move avatars from one item to another. And probably even more important in your case: you can easily have two or even three avatars on the same ticket. And that‘s exactly what you want: several people working on the same task, so that the specialist knowledge can spread." </span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;">Again, Peter started to change the layout of the board, and now it looked like this:</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfxHcMugG1oFH5VMtwcGEA6R1dk0bOFL-D93TJbL04XDm60IQemw8ODVjABLn8J3_HpSYkkqBm2rgOG5U2ybCD4x8AEfitVXSuGj8lsDKOIB1KDLnu01Z4xR-MRuvqdwaMws98yQ2rAWo/s1600/Folie4.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhfxHcMugG1oFH5VMtwcGEA6R1dk0bOFL-D93TJbL04XDm60IQemw8ODVjABLn8J3_HpSYkkqBm2rgOG5U2ybCD4x8AEfitVXSuGj8lsDKOIB1KDLnu01Z4xR-MRuvqdwaMws98yQ2rAWo/s1600/Folie4.jpg" /></a></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">I finished my thoughts by throwing a couple of more ideas at Peter: "In order to make more explicit, what you want to achieve, you could introduce a policy that goes like this: <i>In every column there have to be at least two different avatars at any time</i>. You could easily track your improvements by counting the number of tickets on which two or more people have collaborated. It might also make sense to limit the number of avatars per person, to encourage collaboration across specializations...But I feel we get carried away. So before going any further, I think you should gather your team and explain to them what you want to achieve and why. I am sure they have plenty of ideas how to get there themselves!"</span><br />
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<h3>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Reflecting</span></h3>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">One of the biggest benefits of Kanban is that it focuses on queues. Through the board we can gain visibility of the queues. And by limiting work in progress, we actively manage queues and thereby improve flow. Managing queues is a powerful, yet relatively simple way to decrease lead time dramatically. Of course the board can only show us improvement opportunities, if we are willing to look at them and if we know where to look. So the board should be designed in a way that it shows queues immediately. Ideally, this visualization is accompanied by metrics, which show the impact of (often growing) queues over time. </span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">In my experience it‘s always a good idea to have a closer look at the division of queues and ask questions like: How many different queues do we see? Why are they separated? What would be the advantages and disadvantages of merging several queues into one major one? How high would the investment be? </span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">I am not saying it‘s always a good idea to have one common queue (the modern post office system). It‘s mainly a tradeoff decision, which should be answered considering different factors like risk, short-term costs, customer and employee satisfaction etc. In fact, many post offices still do have a separate queue for banking issues. This probably makes sense, because it would be very costly to train every clerk in banking tasks.</span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">Another interesting point is to look at this problem at different levels. In this post I‘ve discussed the issue of having individual specialists, whose work is divided by separate queues. Merging these queues might cause more collaboration and spreading knowledge. The same logic applies at a team or even department level. For instance, in product development it‘s worth asking: Do our development teams work on separate queues or do they pull items from a common queue? And again: What are the advantages and disadvantages? What would it take to change this? At which cost? And then at an even higher level: How do the queues look like for our departments and business units? Would it make sense to have a common queue here, as well (at least for some kind of work)? To get a better understanding of these different levels, I find the concept of <a href="https://www.leanability.com/en/blog-en/2013/07/kanban-and-its-flight-levels-3/" target="_blank">Kanban Flight Levels</a> as developed by Klaus Leopold very useful. </span></div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;"><br /></span></div>
<div>
<br /></div>
</div>
<div>
<span style="font-family: "arial" , "helvetica" , sans-serif;">What are your experiences with separate vs. common queues (and the post office)? Please leave a comment!</span></div>
<br />
<br />
_______________________<br />
<br />
<i>Like this post? Then you should check out my post <a href="http://www.software-kanban.de/2012/06/utilization-as-proxy.html" target="_blank">Utilization as a proxy</a> and my more recent post <a href="http://www.software-kanban.de/2017/02/keep-ball-rollin.html" target="_blank">Keep the Ball rollin´</a></i>Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com3tag:blogger.com,1999:blog-1423003429632694999.post-17418697675050258712017-02-20T18:10:00.000+01:002017-02-20T18:24:31.866+01:00Seriously, what is a Pull System?Almost 5 years ago, I‘ve published a blog post called <a href="http://www.software-kanban.de/2012/07/what-f-is-pull.html" target="_blank">What the F*** is Pull?</a> The distinction between <i>Pull System</i> and <i>Pull Behavior</i>, that we‘d come up with earlier at the <a href="http://leankanban.com/klr/" target="_blank">Kanban Leadership Retreat</a> still makes a lot of sense to me. Yet I keep seeing a lot of confusion around the concept of pull, and I myself often had troubles explaining it in a crisp, comprehensive way. A couple of months ago, I was fed-up, freed up some time and thought about it a little bit more. After a little bit of scribbling and googling, I wrote down a short definition, which I am quite happy with. And like with most things, I did not invent this definition, it had all been written down before. It‘s just that I did not read the right resources before and that the wording of many texts did not convince me. Often, the definitions are too detailed for my taste and too focused on manufacturing systems. So here's how I define a Pull System as opposed to a Push System in a context of Kanban - maybe it‘s useful for others, as well.<br />
<br />
<h3>
Definition of Push vs. Pull</h3>
<i>In a Push System, new input is determined by a plan or event. Output has to be adjusted accordingly.</i><br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvaQ0R-_jQTdPWC7FhS2U04UNesIfCjgqqL3FQ9Bf3WJenTTLNEPLMmQFl-KG3h56jTo203mR51qf2leKkRafo7UEQcoqUC917Uv6g0cTW21hIEY2cM4akJDrjPcpM9Z0qNnPk5YadKQA/s1600/Push-System.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="206" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgvaQ0R-_jQTdPWC7FhS2U04UNesIfCjgqqL3FQ9Bf3WJenTTLNEPLMmQFl-KG3h56jTo203mR51qf2leKkRafo7UEQcoqUC917Uv6g0cTW21hIEY2cM4akJDrjPcpM9Z0qNnPk5YadKQA/s400/Push-System.jpg" width="400" /></a></div>
<i><br /></i>
<br />
<br />
<i><br /></i>
<i>In a Pull System, new input is determined by the system‘s capacity/capability. Input has to be adjusted to the output.</i><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq4e2N3QN9pBdMRjLZaOSblerdJit0M03nYnZ8z1t5zQho2J87o9tvRWc0SPD6_pQhE9b0jpPA7sxUEeGLAREe0R0J7bIEsPo9WTkyMmyIiVJy22JHWWuJ2x-2tyLj4l9GxoxudNZ_gMY/s1600/Pull-System.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="221" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhq4e2N3QN9pBdMRjLZaOSblerdJit0M03nYnZ8z1t5zQho2J87o9tvRWc0SPD6_pQhE9b0jpPA7sxUEeGLAREe0R0J7bIEsPo9WTkyMmyIiVJy22JHWWuJ2x-2tyLj4l9GxoxudNZ_gMY/s400/Pull-System.jpg" width="400" /></a></div>
<h3>
Pull Systems and WIP Limits</h3>
Now the connection between Pull and WIP limitation becomes evident. As Don puts it: "WIP limits are inherent to Pull Systems." If the input is to be determined by the system‘s capacity/capability, we 1) have to know this capacity/capability (therefore Lean‘s notion of studying the system and <a href="https://vimeo.com/79779869" target="_blank"><i>Understanding</i> as one of Kanban‘s core values</a>); and 2) we have to make sure that we never load the system beyond its capacity/capability. The easiest way of doing this is to only allow a new work item to enter the system, after another one has been finished. We have to "read" our system from right to left - just as we should "read" our Kanban board from right to left - hence the slogan <i>Stop Starting, Start Finishing! </i><br />
<i><br /></i>
<br />
<h3>
Pure Pull Systems?</h3>
It‘s worth mentioning that pure Pull Systems probably do not exist. As Don Reinertsen points out in his brilliant presentation <a href="https://vimeo.com/53321681" target="_blank">The Science of WIP Constraints</a>, even the leanest system has a push-pull-boundary, meaning that the pull mechanism only starts after a certain process step. Before this step, work is pushed into the system. Even at Toyota, there is a minimum of planning and buffering involved - they don‘t melt new steel for every new car.<br />
What‘s probably more important to knowledge work is the fact that want to achieve as much pull as possible in our system, but we also want our system to be able to absorb some push. Sounds strange, but it enables us to cope with major unforeseen events. In Kanban lingo, most expedite tickets will be pushed into the system. Ideally, our system is under-utilized, so that it provides spare capacity to deal with this extra work. But even if it does not, we might be willing to accept the push, because the cost of waiting for a free slot would be much higher than the cost of temporally overburdening the system. But that should be discussed further in a separate blog post...<br />
<br />
_______________________<br />
<br />
<i>Like this post? Then you should check out my previous post <a href="http://www.software-kanban.de/2017/02/keep-ball-rollin.html" target="_blank">Keep the Ball Rollin‘</a></i><br />
<i><br /></i>
<br />Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com7tag:blogger.com,1999:blog-1423003429632694999.post-85692504672450778082017-02-07T11:42:00.000+01:002017-03-07T13:57:47.201+01:00Keep the Ball Rollin‘<br />
<i>This is a translated (and slightly modified) version of my article "Der Ball muss rollen!", which was published online at Projektmagazin in May 2014. If you prefer German, you can <a href="https://www.projektmagazin.de/meilenstein/projektmanagement-blog/der-ball-muss-rollen_1090466" target="_blank">find the original article here</a>.</i><br />
<h3>
<span style="font-weight: normal;"><br /></span></h3>
<h3>
<span style="font-weight: normal;">
Yet another sports analogy</span></h3>
Once I was with a company, where every conference room was soccer-themed. Not only were the rooms named after famous soccer clubs, but they were also decorated with "devotional objects" like jerseys, balls, pennants, etc. Of cours,e you would also find those funny quotes like "Soccer is like chess, only without the dice" all over the place.<br />
I recall one meeting, where people were vividly discussing how effective software development teams should be set up. Probably influenced by the environment, I started thinking about soccer teams and what we could learn from them. Okay, sports analogies are not really new in software development, but let‘s give it a shot...<br />
<h3>
<span style="font-weight: normal;"><br /></span></h3>
<h3>
<span style="font-weight: normal;">
How (not) to manage a soccer team</span></h3>
Let‘s start with the composition of a soccer team. We‘ll find a goalie, defending players, midfielders, and of course the strikers. Looks trivial at first glance, because in order to win a match, there are "tasks" that need to be done in each of these areas. And obviously, a goalie needs completely different skills than a striker.<br />
But wait a minute! If we think about it a little bit harder, we‘ll find an incredible waste of resources here! Even if midfielders support the defense every now and then and strikers fall back occasionally, it‘s very clear that all players are extremely poorly utilized! What‘s the ball possession of an average striker? Two to three minutes? And if we look at the goalie, it‘s even worse! It looks like he‘s just standing there and waiting for something to happen at least 99.9% of the time. Now think about the ridiculously high salary level of professional soccer players and you‘ll probably be close to a nervous breakdown.<br />
Needless to say, that we as experienced project manager instantly understand the disastrous management we‘re dealing with here! If a striker is only needed, let‘s say, 30% of the time (we also calculate things like zone defence here), then why not have him play three matches in parallel? We would still have a 10% buffer if something goes wrong. Looking at the goalie, we‘ll find even more to optimize, because he‘s "needed" even less often. So he could easily play ten matches simultaneously. That‘s good, because our amateur teams are desperately looking for a better goalie...<br />
Now let‘s take a quick look at the substitution bench! Here we‘ll find plenty of great resources that are not utilized at all. They are paid for doing nothing! So let‘s reduce the number of substitutes dramatically. How many of them do we really need? Three should be more than enough. All the others could be used way better outside of the bench: They could play in other teams, train our junior teams, give out autographs at the mall, etc.<br />
<h3>
<span style="font-weight: normal;"><br /></span></h3>
<h3>
<span style="font-weight: normal;">
How (not) to manage a project</span></h3>
All this is, obviously, nonsense! Nobody would even consider optimizing a soccer team in the way just described. But why not? Why exactly is it common in professional soccer teams to under-utilize extremely expensive "resources", while it scares us to death to do the same thing in knowledge work? One major difference lies in the fact that in soccer it‘s really easy to see the damage that‘s done, when a player is not at the right spot at the right time: the other team scores! In professional soccer, the difference between scoring a goal and allowing the other team to score, is probably worth a 6- or 7-digit number. Given this order of magnitude, who cares if a player is not fully utilized?<br />
And a second point comes into play: In soccer, it‘s clear to everyone, that what the coach can do is to train the team and provide them with a viable strategy. What he can <i>not</i> do, though, is to come up with a detailed plan for the whole match - or even the first ten minutes. If this would work, we could indeed create plans for every individual player, and we could even have them play several matches simultanously. The plans then would read something like: "At 15:53 pass the ball to player 8...At 15:57 prevent the ball from being lost on field 3...At 15:59 score a goal on field 2..." Of course it‘s ridiculous to even try this, because we know a soccer match is way too complex to even try to plan at this level of detail (1). And we all know that not everything goes according to our plan in a soccer match, and we have no chance of predicting what the opposing players will do at any time.<br />
<h3>
<span style="font-weight: normal;"><br /></span></h3>
<h3>
<span style="font-weight: normal;">
Comparing projects to soccer? </span></h3>
Let‘s summarize what we‘ve got so far: When it comes to professional soccer, we‘ve long accepted the fact that the high degree of uncertainty makes it useless to come up with detailed plans upfront. In addition, it‘s relatively easy to access the risk of a player not being at the right spot at the right time. This enables us to make reasonable trade-off decisions: How high are the costs of under-utilized players compared to the cost of a delay, because the team has to wait for a player, who‘s not ready to take-over the ball or block an opponent? In soccer, this cost of delay is so enormous, that dramatic under-utilization is accepted even for players who earn millions of Euros.<br />
<br />
If we keep this in mind, perhaps the comparison to project work is not that absurd after all! Just as in soccer, in many projects we have to deal with great uncertainty, that often renders our beautiful plans useless. Also, in project work cost of under-utilization and cost of delay are factors that should be taken into consideration (2).<br />
<h3>
<span style="font-weight: normal;"><br /></span></h3>
<h3>
<span style="font-weight: normal;">
A fresh view on resource planning</span></h3>
Just to be clear: under-utilization of people and machines does matter, because it can lead to lost opportunities: When a highly skilled expert is idle, she might do something of great value elsewhere instead. That‘s the reason why it seems totally normal to us to come up with plans that make sure this person wil never be idle. What we ignore, though, is the fact that costs also occur when a project (or even a supposedly small milestone) is blocked, due to an expert, who is not instantly available.<br />
If we would have more clarity on these two different types of costs, we would certainly make different decisions and our resource planning would appear in a different light. For instance, in some contexts it now might make a lot of sense to build and keep stable, cross-functional product teams, consisting of developers, testers, analysts and designers. There might be times when a designer or a tester is not fully utilized. But when she is needed, she will be there to help the team immediately (just like the soccer player when a ball is passed to him). This is a major advantage and solves a lot of problems we witness in our daily project work: low quality due to frequent context switches; rework due to long feedback loops; poor transparency on our project‘s progress, because all work packages are "80% done", just to name a few.<br />
It‘s true in project work as much as in soccer: We must keep the ball rolling (3)! If we manage to do this, it‘s way less relevant, how many players are moving at which pace. This, by the way, is the difference between <i>resource efficiency</i> and <i>flow efficiency</i>: When we focus on resource efficiency, we make sure that everyone is busy; when we focus on flow efficiency, we make sure that we make progress on the most important tasks at any time. For several decades now, we only took resource efficiency into account. It‘s time to give flow efficiency priority now (4)!<br />
<br />
P.S. I‘ve just learned that there‘s an old song called "Keep the Ball Rollin‘" by a band called Jay & the Techniques. Looking at the lyrics, I don‘t think the song has much in common with this blog post;-)<br />
<br />
(1) Funny enough, I‘ve just finished reading the book <a href="https://www.amazon.com/Team-Teams-Rules-Engagement-Complex/dp/1591847486/ref=sr_1_1?ie=UTF8&qid=1486394018&sr=8-1&keywords=team+of+teams" target="_blank">Team of Teams by General Stanley McChrystal</a>. To illustrate one of his points, McChrystal
describes, how the coach of a fictional basketball team tries exactly
this level of detailed planning and fails miserably, despite the fact that the team comprises of
the world‘s finest athletes.<br />
(2) For more details on cost of delay, look into <a href="http://reinertsenassociates.com/videos/" target="_blank">see the brilliant analyses of Don Reinertsen</a>.<br />
(3) The idea is not new, neither is explaining it with sports
metaphors:-) Years ago, Don Reinersen coined the phrase: "Watch the
baton, not the runner!"<br />
(4) Niklas Modig brilliantly illustrates the difference between resource efficiency and flow efficiency in his book <a href="https://www.amazon.com/This-Lean-Resolving-Efficiency-Paradox/dp/9187791153/ref=sr_1_1?ie=UTF8&qid=1486393775&sr=8-1&keywords=niklas+modig" target="_blank">This is Lean: Resolving the Efficiency Paradox</a> and in <a href="https://www.youtube.com/watch?v=hGJpez7rvc0" target="_blank">this Ted Talk</a>.<br />
<br />
_______________________<br />
<br />
<i>Like this post? Then you should check out my post <a href="http://www.software-kanban.de/2012/06/utilization-as-proxy.html" target="_blank">Utilization as a proxy</a> and my more recent post <a href="http://www.software-kanban.de/2017/02/seriously-what-is-pull-system.html" target="_blank">Seriously, what is a Pull System?</a></i>Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com13tag:blogger.com,1999:blog-1423003429632694999.post-4973339884216715842016-11-20T17:38:00.000+01:002017-09-23T18:10:59.241+02:00Thoughts on Groupthink<span style="background-color: rgba(255 , 255 , 255 , 0.882353); color: #333332; font-family: "arimo" , sans-serif , "google"; font-size: 16px;">During the past couple of months I‘ve done quite some reading on cognitive biases. </span><a href="https://en.wikipedia.org/wiki/Cognitive_bias" style="background-color: rgba(255, 255, 255, 0.882353); color: #3986a0; font-family: Arimo, sans-serif, google; font-size: 16px; transition: color 0.3s ease-in;" target="_blank" title="https://en.wikipedia.org/wiki/Cognitive_bias">Wikipedia states</a><span style="background-color: rgba(255 , 255 , 255 , 0.882353); color: #333332; font-family: "arimo" , sans-serif , "google"; font-size: 16px;"> that “[a] cognitive bias refers to a systematic pattern of deviation from norm or rationality in judgment, whereby inferences about other people and situations may be drawn in an illogical fashion.” As I read more about biases and how our brain works, I had to realize that humans are incredibly bad in making rational decisions. We often believe that we analyze a situation carefully, then evaluate the pros and cons of a decision and decide for the option with the best cost-benefit-ratio. In fact, that‘s not true. And even worse: Our brain tricks us into thinking that it is true! If we can believe the many findings of neuroscience and social psychology, our decisions are heavily influenced by factors that we are not even aware of.</span><br />
<span style="background-color: rgba(255 , 255 , 255 , 0.882353); color: #333332; font-family: "arimo" , sans-serif , "google"; font-size: 16px;"><br /></span>
<br />
<div>
<div class="j-module n j-text " id="cc-m-12693649388" style="background-color: rgba(255, 255, 255, 0.882353); color: #333332; font-family: Arimo, sans-serif, google; font-size: 16px; padding: 5px; word-wrap: break-word;">
<h3>
What is groupthink?</h3>
One of these factors is the very strong human need of relatedness. When people feel that their belonging to a group is in danger, it‘s very threatening to them. In fact, our brain works pretty much in the same way it did 10,000 years ago. And back then, it actually was a death threat when someone was excluded from a group. The thing is: When we feel threatened, a couple of very archaic mechanisms kick in, which tend to overrule all rational reasoning.<br />
So humans have a very strong tendency to conform with a group. This leads to groupthink, where “the desire for harmony or conformity in the group results in an irrational or dysfunctional decision-making outcome. Group members try to minimize conflict and reach a consensus decision without critical evaluation of alternative viewpoints, by actively suppressing dissenting viewpoints, and by isolating themselves from outside influences."</div>
<div class="j-module n j-text " id="cc-m-12693567888" style="background-color: rgba(255, 255, 255, 0.882353); color: #333332; font-family: Arimo, sans-serif, google; font-size: 16px; padding: 5px; word-wrap: break-word;">
Groupthink is also called the <em>Bay-of-pigs-effect</em>, because the disaster of the invasion to Cuba is believed to be caused by groupthink: People self-censored their doubts about the plan, because they felt it was not appropriate to contradict the predominant opinion in the group. Fortunately, Kennedy learned his lesson and - less than one year later - had mechanisms in place to avoid groupthink and make much smarter decisions during the Cuban Missile Crisis. Other really severe incidents like the explosion of the Challenger Space Shuttle have also been linked to poor decision making based on groupthink.<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiymhCLtQBOU2-jE2NZu5_5xNAxH7vglvcX6IBSy1EdOHR0Mdrejr4HI1Box1tg07fTcN5e9jRsdyuZ8h6tvvxx8UYz0TJYXLR9Ngfo1-i-qL1kDH6H6ah2tVyBqgDZZDEWVwl24XT1UY/s1600/6950946876_39c536a74e_z.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="270" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiiymhCLtQBOU2-jE2NZu5_5xNAxH7vglvcX6IBSy1EdOHR0Mdrejr4HI1Box1tg07fTcN5e9jRsdyuZ8h6tvvxx8UYz0TJYXLR9Ngfo1-i-qL1kDH6H6ah2tVyBqgDZZDEWVwl24XT1UY/s400/6950946876_39c536a74e_z.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Some people say that World War III has been avoided during the Cuban Missile Crisis, because Kennedy had learned how to avoid groupthink and embrace dissent. Image credit: doe-oakridge on flickr</td></tr>
</tbody></table>
<span style="font-family: "arimo" , sans-serif , "google";">Now think about a group in the context of knowledge work - could be a team at a planning meeting or retrospective; could be a management group talking about strategy; could be a committee organizing the next christmas party. When you use the same approach I used to use in my role as a moderator, chances are that the decisions of these groups are flawed. Why is that? Common moderation techniques rely on writing topics on cards, clustering them and eventually having the group dot voting the topic they want to tackle. Nothing wrong with this, but the devil‘s in the details!</span><br />
<span style="font-family: "arimo" , sans-serif , "google";"><br /></span>
<br />
<h3>
<span style="font-family: "arimo" , sans-serif , "google";">A real-life example</span></h3>
<span style="font-family: "arimo" , sans-serif , "google";">Let‘s look at a real-life example of a workshop I was observing. The group had been talking about areas for improvement and how good they thought they already were (from 1=excellent to 5=very bad). You can clearly see big clusters and very little variation.</span><br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0qv8G0xF_PyZlviECTC3_kkH4iPZ11iBcmMNXXlzI7DvTy22jkckXe0ewi3EH9Rs-IfmnityLzIZEwCNXTBcygJMRABnyNuugAq7tbi_LQqXIvj6XfspBGGIIC6R4At-diHWLZWomE7U/s1600/Poster.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="115" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0qv8G0xF_PyZlviECTC3_kkH4iPZ11iBcmMNXXlzI7DvTy22jkckXe0ewi3EH9Rs-IfmnityLzIZEwCNXTBcygJMRABnyNuugAq7tbi_LQqXIvj6XfspBGGIIC6R4At-diHWLZWomE7U/s400/Poster.jpg" width="400" /></a></div>
<div class="j-module n j-text " id="cc-m-12693604088" style="font-family: Arimo, sans-serif, google; padding: 5px; word-wrap: break-word;">
When the moderator saw this, he said something like: “Excellent, you are all very aligned here. Let‘s go on with the topic you‘ve rated worst.”<br />
The problem was that people dot-voted one after the other or in small groups. So the later a person voted, the more votes were already visible. In such a situation, according to neuroscience, it becomes more and more difficult to give a completely different vote. In this context it‘s extremely interesting to look at <a href="https://en.wikipedia.org/wiki/Asch_conformity_experiments" style="color: #3986a0; transition: color 0.3s ease-in;" target="_blank" title="https://en.wikipedia.org/wiki/Asch_conformity_experiments">Asch‘s Conformity Experiment</a>, where people gave obviously wrong answers to a simple task, because they wanted to conform with the group.<br />
When I think back to the moderations I did, I did not take this much into consideration (and probably others don‘t, as well). So what can we do about it? I think first it‘s important to acknowledge that groupthink (like all cognitive biases) is not a bad thing in itself. It serves an extremely important purpose. But in many of our modern contexts, it becomes an obstacle.<br />
<br /></div>
<h3 style="font-family: Arimo, Helvetica, Arial, sans-serif; padding: 5px; word-wrap: break-word;">
What can we do about it?</h3>
<div class="j-module n j-spacing " id="cc-m-12693643988" style="font-family: Arimo, Helvetica, Arial, sans-serif; padding: 5px; word-wrap: break-word;">
<span style="font-family: "arimo" , sans-serif , "google";">Because of their evolutionary importance, biases seem to be hard-wired into our brains. Therefore it‘s of little help to tell people not to groupthink. Here‘re some things I think are more useful to reduce the effects of groupthink:</span></div>
<div class="j-module n j-spacing " id="cc-m-12693643988" style="font-family: Arimo, Helvetica, Arial, sans-serif; padding: 5px; word-wrap: break-word;">
<ul style="font-family: Arimo, sans-serif, google;">
<li>Let people vote simultaneously, if possible.</li>
<li>Let people think about the topic individually or in small groups. Let them write down their opinions/votes and only after that collect all the individual votes. This gives them the space to think about the issue with very little influence from the big group. Also, if people have written down their preference on a piece of paper one minute ago, it‘s quite hard for them to deviate from this preference shortly after.</li>
<li>When you decide to do a circle, where every group member voices his/her opinion, make sure that the boss and obvious opinion leaders speak last.</li>
<li>Try to make the group as diverse as possible. Diverse groups have proved to be less vulnerable to groupthink.</li>
<li>Try to add people to the group, who are likely to have a different opinion than the majority of the group.</li>
<li>Invite an outside expert to the group. Outsiders are less vulnerable to groupthink (especially when they know they are only temporarily a member of this group). This is one big advantage of consultants, especially when you tell them they are paid, because they are less likely to conform with the group.</li>
<li>Observe closely, which members are quiet during a workshop or meeting and explicitly encourage them to voice their opinion, even if it‘s controversial. Usually we assume that the quiet ones agree with the group. But what if they are the ones who disagree but are afraid of isolating themselves from the group? Think about what would help those people to gain confidence and openly disagree.</li>
<li>Explain the role of <a href="https://en.wikipedia.org/wiki/Devil%27s_advocate" style="color: #3986a0; transition: color 0.3s ease-in;" target="_blank" title="https://en.wikipedia.org/wiki/Devil%27s_advocate">devil‘s advocate</a> to the group and assign this role to one person. The explicit role makes it much easier to speak up, because people know it‘s “the role” speaking, not necessarily the person (and people might dislike the role, but they won‘t dislike the person who disagrees). Actually I think the “10th Man Doctrine” was the one cool thing in the movie World War Z. It says: “whenever 9 people looking at the same information come to the same conclusion, it's the 10th's duty to disagree and actively look for evidence to the contrary.” Although this doctrine is not a real thing, I was surprised to learn that the Israeli military seems to have a devil‘s advocate office, which task it is to ensure that “intelligence assessments are creative and do not fall prey to group think.” (see <a href="https://www.quora.com/World-War-Z-2013-movie-Do-the-Israelis-really-have-a-10th-man-doctrine" style="color: #3986a0; transition: color 0.3s ease-in;" target="_blank" title="https://www.quora.com/World-War-Z-2013-movie-Do-the-Israelis-really-have-a-10th-man-doctrine">this thread on Quora</a>).</li>
<li>Think about rules and processes that help dealing better with groupthink. One such rule could be: “If everyone in the group agrees, we assume we have overlooked something and we should actively look for different angles.”</li>
<li>Be very aware of signs of pressuring dissenters. Phrases like “Are you with us or not?”, “Are you a team player or not?”, “You‘re either in or out!” should get all alarm bells ringing.</li>
<li>Brief someone to wear the clown suit. I stole this metaphor from <a href="http://lesswrong.com/lw/mb/lonely_dissent/" style="color: #3986a0; transition: color 0.3s ease-in;" target="_blank" title="http://lesswrong.com/lw/mb/lonely_dissent/">this blog post about lonely dissent</a>. The author states that “[l]onely dissent doesn't feel like going to school dressed in black. It feels like going to school wearing a clown suit.” Modifications of Asch‘s experiment have shown that chances to disagree with the group grow dramatically as soon as at least one other person has disagreed before. This first person is the one with the clown suit. Look for someone with enough confidence and standing to wear the clown suit. And if you consider yourself a leader, think about wearing the suit yourself.</li>
<li>As a leader, reward deviating from the group‘s opinion. I am not talking about monetary incentives here. I think it can be extremely powerful to praise someone in front of the group for wearing the clown suit.</li>
</ul>
<div style="font-family: Arimo, sans-serif, google;">
What are your experiences with groupthink? I am happy to read your comments below!<br />
<br />
P.S. If you find cognitive biases interesting, you might like my posts <a href="http://www.software-kanban.de/2017/08/thoughts-on-survivor-bias.html" target="_blank">Thoughts on survivor bias</a> and <a href="http://www.software-kanban.de/2017/09/thoughts-on-confirmation-bias.html" target="_blank">Thoughts on confirmation bias</a></div>
</div>
</div>
<br /></div>
Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com0tag:blogger.com,1999:blog-1423003429632694999.post-64698845704236692842016-04-19T12:23:00.001+02:002017-02-21T18:09:34.790+01:00An Alternative View on Company Structures<div dir="ltr" id="docs-internal-guid-849ca74c-2e02-ef6d-ccea-c1eb72a58144" style="line-height: 1.38; margin-bottom: 3pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38;">For years my thinking about company structures went like this: “The more structure a company has, the more it sucks.” So I was arguing against putting new structures in place, whenever I heard of such ideas. Of course I knew, that no company could exist without any sort of structures. So my credo was: Let‘s only have structures, where it is absolutely necessary. And in my mind it only became necessary when we were growing and the new size made it necessary to come up with new structures, because otherwise things break down..</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;">Potential downsides of rigid org structures are well known: Less freedom for the workforce, and hence less engagement and less innovation; Dilbertesque policies that might make sense for some part of the organization but not for the rest of it; single points of failure due to hierarchical pyramid structures etc.</span></div>
<br />
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;">Back to my credo: “Let‘s only have structures, where it is absolutely necessary”. I still think it‘s valid, but here comes the catch: I‘ve realized that there are other things than sheer growth in headcount that can make it necessary to add more structure! Here are three things I think are worth taking into consideration: <i>Diversity</i>, <i>Fairness</i> and <i>Health</i>.</span></div>
<br />
<div style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;"><b>Diversity</b></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;">There‘s plenty of research (see <a href="http://www.scientificamerican.com/article/how-diversity-makes-us-smarter/" target="_blank">this article</a> for more resources) that shows how more diverse groups make better decisions. When people think about diversity, they mostly think about gender. While gender is very important and there is a lot to improve, especially in the tech industry, we should also think of diversity in terms of age, race, cultural and economic background, sexual orientation, political preferences, family situation, etc.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;">When I talk about diversity with my colleagues, we very often end up with the idea that we should have more structures. There are two reasons for this:</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
</div>
<ol>
<li><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;">If we want to have a more diverse workforce, we have to change the way we recruit and hire people. For a long time the way I did job interviews went something like: Let‘s have a coffee together and afterwards we do a thumb vote if we want to work with this person or not. If you use a process like this, you can be 100% sure, that your decision is affected by all sorts of cognitive biases and that you are biased </span><span style="font-family: "arial"; font-size: 14.6667px; font-style: italic; vertical-align: baseline;">against</span><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;"> diversity. Like one of my colleagues put it nicely: “Having more diversity in a group feels like a grain of sand in the gear.” It feels uncomfortable. Humans are hard-wired to prefer being with people who are like them. And this is exactly what we want to avoid when we talk about diversity. One countermeasure for this are structured job interviews. Google does this rigidly, as Lazlo Bock (Head of People Operations at Google) presents in <a href="http://www.amazon.com/Work-Rules-Insights-Inside-Transform/dp/1455554790/ref=sr_1_1?ie=UTF8&qid=1461061001&sr=8-1&keywords=work+rules" target="_blank">his book</a> and <a href="http://www.wired.com/2015/04/hire-like-google/" target="_blank">this article</a>. What are structures interviews? Not only are the questions for a job interview formulated beforehand, but there‘s also a definition of the types of answers that are considered to be good/mediocre/bad. Or, as Bock puts it, a structured interview is “a consistent set of questions with clear criteria to assess the quality of responses”. </span><span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38;">And Google even goes one step further: The hiring decision is not made by the people, who did the interview, but by an separated committee. Sounds like a lot of structure, right? It certainly does to me and I was terrified, when I heard this for the first time. But if we take diversity and de-biasing seriously, this might be the (or at least one) way out.</span></li>
<li><span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38;">As soon as we become more diverse in our workforce, we might also need more structure. My colleague Boris just shared his thoughts on this with me: “If we were all clones of each other, we wouldn‘t need any structures. Everyone knew exactly what the others think, how things work and what the next steps are. But this would be zero diversity. If we have people with different backgrounds, we need more explicit structures, otherwise people get lost.” This totally makes sense to me. If all your employees are 30-year old, left-winged white male surfer dudes without kids, you probably don‘t need much structure, because their thinking might be very aligned. And if they face a problem, they will find a way to work around it easily, because every evening they‘re drinking beer together. So this scenario is very comfortable, and although it‘s intentionally exaggerated, I think a lot of start-ups work in a similar way. It might be okay, or even necessary for a small company to operate in such a way, but if the company is growing, and especially if it‘s critical to improve the quality of decisions, increasing diversity becomes very important. And that increased diversity comes with the need for more structures.</span></li>
</ol>
<div style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38;"><b>Fairness</b></span><br />
<span style="font-family: "arial"; font-size: 14.6667px; line-height: 1.38;">Every organization has implicit and explicit structures. And probably it‘s a good heuristic to say that the less explicit structures you have, the more important the implicit structures become. That can be considered unfair, because it favours those who are good in navigating through blurry structures. Often the best (or even the only) way to get things done in such a context might be having good personal relationships with the most influential people in the company. For new people it can be really hard to join this game, because the rules are...implicit. And it gets even worse, as soon as you get more diversity. Imagine that, for the first time, a single mother joins the company. She probably does not have the time nor the interest to hang out every other evening with her colleagues.</span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;">In </span><a href="http://www.jofreeman.com/joreen/tyranny.htm" style="text-decoration: none;"><span style="color: #1155cc; font-family: "arial"; font-size: 14.6667px; text-decoration: underline; vertical-align: baseline;">this classic feminist article</span></a><span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;"> from the 1970s, Jo Freeman argues that so-called structure-less groups are undemocratic, because they tend to be dominated by elites, who are not accountable to the larger group: “For everyone to have the opportunity to be involved in a given group and to participate in its activities the structure must be explicit, not implicit.” </span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;">I am not very familiar with the feminist movement, and the groups Freeman talks about are political groups, not companies. Still the argument makes a lot of sense to me and made me think.</span></div>
<br />
<div style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;"><b>Health</b></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;">While organizations with little (explicit) structure provide a lot of opportunities, they also might make it easy for people to jeopardize their health. The reason for both, the good and the bad aspect of little structures, is what I would call “anything goes”. If responsibilities, decision-making-mechanisms, team structures, career paths etc. are unclear, the organization might be able to exploit the advantages of fast decision-making (“if it‘s not clear, who makes this decision, let‘s just decide in this group - right now”) and fluid teams (“let‘s team up and build this thing”). On the other hand, the same context might encourage people to work in an unhealthy way. By this I not only mean the sheer amount of hours they work, but also the effect of over-commitment and mental overload. Because it‘s unclear, where my responsibility ends and what the company expects from me, I might take on everything I find interesting or important. Of course I can only do so many things, but I am very ambitious, and nobody stops me from starting all these exciting things. So maybe I should start working a little bit longer every day and think about all the interesting problems at the weekends and during my holidays?</span></div>
<br />
<div style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;"><b>What now?</b></span></div>
<div dir="ltr" style="line-height: 1.38; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;">I think it‘s important to realize that structures in itself are neither good nor bad. And I am not making the case for excessive structures. Like with many things, it‘s a permanent trade-off decision we have to make. Instead of falling in the trap of binary thinking (“all structures are good/bad”) we should think about the pros and cons of adding more structure and then find a healthy balance for our context. My impression is that in the Agile/Lean community we have very much focused on the downsides of structures in the past. Maybe it‘s time now to take the upsides into consideration a little bit more.</span><br />
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;"><br /></span>
<span style="font-family: "arial"; font-size: 14.6667px; vertical-align: baseline;"><span style="background-color: white; color: #727272; font-family: "arial" , "tahoma" , "helvetica" , "freesans" , sans-serif; font-size: 13px;">_______________________</span><br style="background-color: white; color: #727272; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px;" /><br style="background-color: white; color: #727272; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px;" /><i style="background-color: white; color: #727272; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px;">Like this post? Then you should check out my previous post <a href="http://www.software-kanban.de/2015/09/radical-transparency.html" target="_blank">Radical Transparency?</a> and one of my newer posts <a href="http://www.software-kanban.de/2017/02/seriously-what-is-pull-system.html" target="_blank">Seriously, what is a Pull System?</a></i></span></div>
Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com9tag:blogger.com,1999:blog-1423003429632694999.post-26709986223059101272015-09-21T13:09:00.002+02:002015-09-21T13:09:46.577+02:00Learning Track at LKCE15<div class="p1">
At this year‘s LKCE15 conference (<a href="http://www.lkce15.com/" target="_blank">Lean Kanban Central Europe 2015</a>) I will be chairing the learning track. Without exaggeration I can say I am more than satisfied with the five sessions in the track. What I especially like is the diversity amongst the speakers and the topics - we managed to go beyond “the usual suspects” and the well-known topics. Also most of the sessions are really hands-on from practitioners, who present their real-life experiences.</div>
<div class="p1">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY-Po6zNcfccfBPIQaBSMUatHcWRWNf9Y46JP6bs_T7yka1RmvhRsgi8Od0l9pPfMtcsxDzMWMWcCw-_HQGJrk9eAomA0LrxXtS7YVPB7hrk3oityVpQnp0KsUUs_dNiit9wgu1zZLGRI/s1600/lkce+15+vertical+logo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img alt="" border="0" height="184" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgY-Po6zNcfccfBPIQaBSMUatHcWRWNf9Y46JP6bs_T7yka1RmvhRsgi8Od0l9pPfMtcsxDzMWMWcCw-_HQGJrk9eAomA0LrxXtS7YVPB7hrk3oityVpQnp0KsUUs_dNiit9wgu1zZLGRI/s200/lkce+15+vertical+logo.png" title="LKCE15 Logo" width="200" /></a></div>
<div class="p1">
<br /></div>
<div class="p1">
<br /></div>
<div class="p1">
Wendy Robinson from <a href="http://www.etsy.com/" target="_blank">Etsy</a> will kick off the track. I met Wendy in New York this year, where we exchanged ideas and experences about how to best train managers. Wendy holds a Harvard degree in adult education, and she‘s awesome! Esty created a program for education 200 managers. It includes e-learning, studio groups and coaching sessions, and I‘ve rarely heard of such a sophisticated effort when it comes to in-house education. Wendy will give deeper insights on how the program works and share her experiences with the program.</div>
<div class="p2">
<span class="s1"><a href="http://lkce15.com/sessions#cop">Using Communities of Practice to Strengthen Manager Learning and Development<span class="s2"></span></a></span></div>
<div class="p1">
<br /></div>
<div class="p1">
The second speaker is Marian Willeke, who also has a background in adult education. In her session <a href="http://lkce15.com/sessions#mindset"><span class="s3">Cultivating the Learning Mindset</span></a> she will talk about the learning needs of adults and how we can foster a learning mindset.</div>
<div class="p1">
<br /></div>
<div class="p1">
After lunch my colleague Eike-Marie Eiting will continue with her talk <a href="http://www.lkce15.com/sessions#desks"><span class="s3">Moving desks to facilitate the in-house cultural dialogue at Jimdo</span></a> Eike works as Head of Global Support at Jimdo, and she‘s totally into the Kaizen mindset. She will present her experiences with splitting a huge team into four smaller ones and relocating the teams to different floors, in order to foster inter-team communication and continuous improvement</div>
<div class="p1">
<br /></div>
<div class="p1">
After Eike it‘s my turn, and in my session <a href="http://lkce15.com/sessions#Salary"><span class="s4">A Salary Experiment</span></a> I will talk about two experiments on remuneration we did earlier this year. We wanted to learn more about fair salary setting, transparent salaries and self-managing teams. I would say this was one of the most sophisticated things I was part of, and I am quite thrilled about what we‘ve learned - both regarding salaries and designing experiments.</div>
<div class="p3">
<span class="s5"><br /></span></div>
<div class="p3">
<span class="s5">Last but not least, Håkan Forss, who now is with King Games, will give his talk <a href="http://lkce15.com/sessions#king"><span class="s6">Experimentation is King</span></a></span><span class="s6">,</span> in which he shares his experiences on how to create a culture, which enables both continuous improvement and disruptive innovation.</div>
<div class="p4">
<br /></div>
<div class="p3">
The learning track is just one track, besides other tracks like leadership, strategy, and (of course) Kanban. Also I am very thrilled about the main stage sessions and the keynotes (especially the one by Chet Richard, author of <a href="http://www.amazon.com/Certain-Win-Strategy-Applied-Business/dp/1413453767/ref=sr_1_1?ie=UTF8&qid=1442833629&sr=8-1&keywords=certain+to+win" target="_blank">Certain to Win</a>). If you haven‘t purchased your ticket until now, I strongly recommend that you do it quickly, as fees will go up soon: <a href="http://www.lkce15.com/register/" target="_blank">Register for LKCE15</a></div>
<br />
<div class="p4">
<br /></div>
Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com0tag:blogger.com,1999:blog-1423003429632694999.post-38692894428671711352015-09-11T15:33:00.001+02:002017-02-21T18:07:07.835+01:00Radical Transparency?<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif;">In the Lean and Agile community, there’s a lot of talk about
the value of transparency. Often the takeaway is „the more transparency, the
better“, followed by the advice to provide more transparency inside of your
company: Make business numbers transparent, make salaries transparent,
videotape all meetings and make them available to the whole company etc. I see
all the advantages transparency brings and I agree that companies could and
should be more transparent in certain areas. I disagree, however, with the
notion that we should aim for radical transparency in all areas. <o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif;">My main argument (of course I haven’t come up with it
myself) for this is: <o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span></div>
<div class="MsoNormal" style="text-align: center;">
<span style="font-family: "georgia" , "times new roman" , serif;"><i>While transparency breeds trust, it tends to hinder
innovation. </i><o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif; mso-ascii-font-family: Cambria; mso-bidi-font-family: "Times New Roman"; mso-hansi-font-family: Cambria;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif;"><span style="mso-ascii-font-family: Cambria; mso-bidi-font-family: "Times New Roman"; mso-hansi-font-family: Cambria;">Real innovation (and I am not
talking about optimizing an existing thing, but coming up with a very different
thing) requires secrecy. You need to</span><span style="mso-ascii-font-family: Cambria; mso-hansi-font-family: Cambria;"> </span><span style="mso-ascii-font-family: Cambria; mso-bidi-font-family: "Times New Roman"; mso-hansi-font-family: Cambria;">try
crazy things, throw things away, and iterate on the</span><span style="mso-ascii-font-family: Cambria; mso-hansi-font-family: Cambria;"> </span><span style="mso-ascii-font-family: Cambria; mso-bidi-font-family: "Times New Roman"; mso-hansi-font-family: Cambria;">same problem over and over again. This is a very wasteful
process, the efficiency is extremely low. On the other hand, the operating
system of an organization (eg most software development teams) are optimized
for velocity, efficiency and high quality. Innovation and optimization can
really be considered as two different worlds, they operate by different rules.
Rules like „you build it, you run it“, „if you break it, will you notice?“ or
„build quality in“ are proven to be really useful in the world of optimization,
but they are poisonous to the world of innovation. We don’t want to write high
quality code here, we don’t want to write code at all. We only use it to learn
things – and only if we don’t find a way to do it cheaper than writing code.
The code should be written in a quick-and-dirty-manner, and nobody should expect that it’s tested
and monitored and maintained afterwards. (It should, however, be removed after
the testing is over).<o:p></o:p></span></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif; mso-ascii-font-family: Cambria; mso-bidi-font-family: "Times New Roman"; mso-hansi-font-family: Cambria;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif; mso-ascii-font-family: Cambria; mso-bidi-font-family: "Times New Roman"; mso-hansi-font-family: Cambria;">Now let’s look at transparency.
In the world of optimization, transparency is oftentimes really helpful,
because it fosters communication and collaboration and breeds trust („Oh, they
have that much on their plate. I wasn’t aware of this and was wondering what
they were doing the whole day.“) It also creates a certain (often healthy)
tension towards accountability and getting stuff done. And this is exactly the
problem in the world of innovation. You don’t want this tension here. You don’t
want people focusing on getting stuff out of the door quickly. Instead, they
need to feel comfortable playing around with seemingly stupid ideas, and it’s
not helping when people tell them: „That’s not working, everybody knows that“
all the time. <o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif; mso-ascii-font-family: Cambria; mso-bidi-font-family: "Times New Roman"; mso-hansi-font-family: Cambria;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif; mso-ascii-font-family: Cambria; mso-bidi-font-family: "Times New Roman"; mso-hansi-font-family: Cambria;">What does this mean? The world
of innovation is very different from the world of optimization – neither one is
better than the other. Companies need both, but they need to be treated
differently. Transparency is one of many examples where we tend to throw out
the baby with the bathwater when we demand things like radical transparency. We
should think about how to create healthy environments for optimization and
innovation – and be aware of the fact that they will look very different.
Unfortunately this comes with a tradeoff: In many cases you will trade trust
for innovation. You can certainly minimize the negative effects of this, but
you cannot eliminate them completely. <o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif; mso-ascii-font-family: Cambria; mso-bidi-font-family: "Times New Roman"; mso-hansi-font-family: Cambria;">Another thing we need to think about
is how we bridge the two worlds, because at a certain point we need to transfer
innovation into the operating system of the company. And we should not do this
by throwing our brilliant innovation over the fence to those who now have to
implement and maintain it. <o:p></o:p></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif; mso-ascii-font-family: Cambria; mso-bidi-font-family: "Times New Roman"; mso-hansi-font-family: Cambria;"><br /></span></div>
<div class="MsoNormal">
<span style="font-family: "georgia" , "times new roman" , serif;">This all is not very new. </span></div>
<div class="MsoNormal">
</div>
<ul>
<li><span style="font-family: "georgia" , "times new roman" , serif;">My
friend Markus Andrezak talks about it for years, for example in <a href="https://vimeo.com/80373205" target="_blank">this great talk from LKCE13</a>. </span></li>
<li><span style="font-family: "georgia" , "times new roman" , serif;">Nonaka/Takeuchi wrote the book <a href="http://www.amazon.com/Knowledge-Creating-Company-Japanese-Companies-Innovation/dp/0195092694/ref=sr_1_1?ie=UTF8&qid=1441791390&sr=8-1&keywords=the+knowledge+creating+company" target="_blank">The Knowledge-Creating Company</a>, which deals with the differences between the two worlds 20 years ago (thanks to <a href="http://www.stefanroock.de/" target="_blank">Stefan Roock</a> for pointing me to this). </span></li>
<li><span style="font-family: "georgia" , "times new roman" , serif;">The concept of <a href="https://en.wikipedia.org/wiki/Skunk_Works" target="_blank">Skunk Works</a> is 70
years old and does very similar things to what I was describing: Creating an
environment that’s decoupled from the rest of the organization and operates by
different rules. </span></li>
<li><span style="font-family: "georgia" , "times new roman" , serif;">In 2004, Charles O’Reilly and Michael Tushman published an HBR
article named <a href="https://hbr.org/2004/04/the-ambidextrous-organization/ar/1" target="_blank">The Ambidextrous Organization</a>, which is – again – about the differences
between the two worlds and ideas how to bridge them.</span></li>
<li><span style="font-family: "georgia" , "times new roman" , serif;">And there’s scientific evidence that the statement „the more
transparency the better“ is plain wrong. Read for example the HBR article <a href="https://hbr.org/2014/10/the-transparency-trap" target="_blank">TheTransparency Trap</a> by Ethan Bernstein (yes, he studied other areas than
software development)</span></li>
</ul>
<span style="font-family: "georgia" , "times new roman" , serif;">Again, I am not saying transparency is bad or we
should have less transparency. What I am advocating is that we should have a
closer look at different contexts and evaluate transparency according to these
contexts, instead of beating the same „transparency is good“ drum over and over
again.</span><br />
<span style="font-family: "georgia" , "times new roman" , serif;"><br /></span>
<span style="font-family: "georgia" , "times new roman" , serif;">Addendum: Christoph Poyault pointed me to this interesting (German) article <a href="https://www.xing.com/news/klartext/so-wirkt-sich-lohntransparenz-auf-die-zufriedenheit-aus-176" target="_blank">So wirkt sich Lohntransparenz auf die Zufriedenheit aus</a></span><br />
<br />
<span style="background-color: white; color: #727272; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px;">_______________________</span><br style="background-color: white; color: #727272; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px;" /><br style="background-color: white; color: #727272; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px;" /><i style="background-color: white; color: #727272; font-family: Arial, Tahoma, Helvetica, FreeSans, sans-serif; font-size: 13px;">Like this post? Then you should check out one of my newer posts <a href="http://www.software-kanban.de/2016/04/an-alternative-view-on-company.html" target="_blank">An Alternative View on Company Structures</a></i><br />
<br />Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com2tag:blogger.com,1999:blog-1423003429632694999.post-91503217532698120282014-12-22T11:14:00.000+01:002017-02-21T18:11:43.917+01:00The Salary DilemmaThe last couple of months my colleagues and I have been
evaluating different alternatives for „Personalverantwortung“ (I’ve asked
several native English speakers and it seems like there is no appropriate
translation, so I will use the German term).<br />
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
We’ve talked about what exactly we mean by referring to
Personalverantwortung at Jimdo and we came up with seven different elements.
One of these elements is, obviously, remuneration. People want to get salaries,
and there needs to be some kind of mechanism in place to decide upon the salary
level. The „traditional“ mechanism for doing this is some kind of line manager
who does (mostly annual) performance reviews with individual salary
negotiations. Perhaps that’s the best (or the least bad) solution in many
contexts, but as I mentioned, we wanted to evaluate other options. So what we
did was 1) read different articles on this topic (eg [1],[2],[3]), 2) talk to a
lot of our teams about this topic. The conversations were very insightful in
many different respects. What I found most interesting was a thought that was
expressed in almost every conversation. It goes like this: <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
„The person/group who decides on my salary need to be very
close to me, so that they can evaluate the quality of my work. At the same time
this person/group cannot be on my team, because my behaviour towards this
person/group will be different as soon as he/she sets my salary. Oh wait a
minute...“<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
This is what I call the salary dilemma: <i style="mso-bidi-font-style: normal;">Whoever decides on the salary of a person needs to be close and not
close to this person at the same time.</i><o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
A line manager has to deal with exactly this problem: He/she
is supposed to evaluate people. In most cases he/she is either very close to
the team and therefore might cause disfunctional behavior (eg people not asking
for help when their annual review is close) or he/she is far enough from the
team to avoid this kind of disfunction. But then the remuneration will most
likely become very similar to roulette („Haven’t heard anything bad about you.
What about a 3% raise?“) Both options don’t look very promising. I am not
saying that it’s impossible to find a good balance, and I have seen very good
managers doing a great job in creating a high-trust environment with their
teams. But I believe it’s <i>very</i> challenging.<o:p></o:p></div>
<div class="MsoNormal">
Of course we can replace the line manager with a different
person or some kind of committee, eg a peer group. This might be better in some
respect, but the dilemma stays in place.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
I am aware that there are many very different models for
renumeration like self-selected salaries, uniform salaries, salary formulas
etc. And we’ve been thinking about ways to avoid or minimize the effects of the
salary dilemma. At this point we are close to run a couple of experiments to
learn more about not only remuneration, but the whole topic of
Personalverantwortung. I might blog about this (and all the other insighst I’ve
had so far) later.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
But for now I am asking for your input: <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<i>How do you deal with
the salary dilemma? </i><b><o:p></o:p></b></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
Please leave a comment or send me an email to arne[døt]roock[ät]jimdo[døt]com<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]-->
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:HyphenationZone>21</w:HyphenationZone>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>DE</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
<w:UseFELayout/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="276">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]-->
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Normale Tabelle";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:Cambria;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;}
</style>
<![endif]-->
<!--StartFragment-->
<!--EndFragment--><br />
<div class="MsoNormal">
P.S. I would like to thank all the smart people with whom
I’ve had the opportunity to discuss this topic: Not only my great colleagues
from Jimdo, but also Russell Healy, Simon Marcus, and Jim Benson. You guys
rock! <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
References</div>
<div class="MsoNormal">
[1] <a href="http://open.bufferapp.com/introducing-open-salaries-at-buffer-including-our-transparent-formula-and-all-individual-salaries/" target="_blank">Open Salaries at Buffer</a></div>
<div class="MsoNormal">
[2] <a href="http://de.slideshare.net/jurgenappelo/merit-money" target="_blank">Merit Money</a></div>
<div class="MsoNormal">
[3] <a href="http://ryancarson.com/post/62104586894/how-salaries-career-progression-and-reviews-work" target="_blank">How salaries, career progression and reviews work in a #NoManager company</a><br />
<span style="background-color: white; color: #727272; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13px;"><br /></span>
<span style="background-color: white; color: #727272; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13px;"><br /></span>
<span style="background-color: white; color: #727272; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13px;">_______________________</span><br />
<span style="background-color: white; color: #727272; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13px;"><br /></span>
<i style="background-color: white; color: #727272; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13px;">Like this post? Then you should check out my previous post <a href="http://www.software-kanban.de/2014/05/stop-bashing-managers.html" target="_blank">Stop bashing managers!</a> and one of my newer posts </i><i style="background-color: white; color: #727272; font-family: arial, tahoma, helvetica, freesans, sans-serif; font-size: 13px;"><a href="http://www.software-kanban.de/2015/09/radical-transparency.html" target="_blank">Radical Transparency?</a></i></div>
<div class="MsoNormal">
<br /></div>
Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com13tag:blogger.com,1999:blog-1423003429632694999.post-66627606070231478512014-10-20T09:24:00.000+02:002014-10-20T09:24:49.527+02:00Lean Kanban Central Europe 2014Only three weeks to go before the 4th edition of Lean Kanban Central Europe takes place! Although I am not involved in the organization any more, I am still part of the Board (and proud of it). As Pawel mentioned in <a href="http://brodzinski.com/2014/09/lkce-leadership-track.html" target="_blank">this blog post</a>, we are constantly experimenting with some elements of the program. This year‘s biggest change will be that we will have dedicated tracks for different topics: Kanban, Leadership, Learning, Management, and Project Management.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWO1Oaph-Fiyx9U2bsBUcdY1zHq-czzvVfhjKZP9j7HCPGrnI9O5vKvIMi7CH7xYdHLqgJ9YDQ9h-bQgDvWpHt8xW3FVmQuATFmfkip5tZLQlPfLslUxq_MCiJ_P6hxwZwplbvBok7JIA/s1600/Quotes.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgWO1Oaph-Fiyx9U2bsBUcdY1zHq-czzvVfhjKZP9j7HCPGrnI9O5vKvIMi7CH7xYdHLqgJ9YDQ9h-bQgDvWpHt8xW3FVmQuATFmfkip5tZLQlPfLslUxq_MCiJ_P6hxwZwplbvBok7JIA/s1600/Quotes.jpg" height="360" width="540" /></a></div>
<br />
<br />
I chose to organize the project management track. The reason for this is that I have met many project managers who realize that the traditional way of managing projects is not sufficient any more. With LKCE we want to show them new perspectives on project managements, provide them with new tools to experiment with and create a forum for sharing experiences with their peers.<br />
<br />
I will kick the track off with my talk <a href="http://www.lkce14.com/sessions#problems" target="_blank">The Beauty of Problems</a> where I will show that problems are so much more than nasty things we need to get rid of. They are great opportunities for learning and improving the system. The talk will be heavily influenced by the work of Russell Ackoff and contain some of my own experiences.<br />
After the Pecha Kuchas (Keynote style as last year), Martin Jensen will argue that <a href="http://www.lkce14.com/sessions#advantage" target="_blank">Culture is THE Competetive Advantage</a> Martin is a smart guy with a great deal of experience with change in large enterprises like Tui.com. He is also a very entertaining speaker. If you haven‘t done already, you should definitely watch his talk from last year.<br />
<br />
<iframe allowfullscreen="" frameborder="0" height="281" mozallowfullscreen="" src="//player.vimeo.com/video/80390769" webkitallowfullscreen="" width="500"></iframe>
<br />
<br />
<br />
Joshua Arnold will continue with his talk <a href="http://www.lkce14.com/sessions#cod" target="_blank">Value and Urgency: The Power of Quantifying the Cost of Delay</a> Anyone who has ever heard The Don (Don Reinertsen) talk will know a little bit about the concept of Cost of Delay. Unfortunately, few people have really first-hand experience with it. Joshua is one of them. Check out his great <a href="http://blackswanfarming.com/experience-report-maersk-line/" target="_blank">experience report from Maersk Line</a>.<br />
After his fabulous <a href="http://www.lkce13.com/videos/magennis/" target="_blank">keynote from last year</a>, Troy Magennis agreed to speak again at this year‘s edition. His topic is <a href="http://www.lkce14.com/sessions#risk" target="_blank">Risk Management and Forecasting Using Un-reliable Data</a> Troy is the guy who not only understands statistics, but also is very capable to explain it to others and to show them how it can be used in daily work without being a statistician.<br />
Conference days are long and it can be hard to maintain attention. Shorter talks might do the trick at the end of the day, and therefore I decided to close the track with a couple of Lightning Talks (10 minutes each). Tim Lossen will talk about the <a href="http://www.lkce14.com/sessions#failure" target="_blank">Failure Culture</a> at Wooga, and my brother Stefan will share his experiences with <a href="http://www.lkce14.com/sessions#decision" target="_blank">participatory decision making models</a>.<br />
<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEie6kdl5Q141dl1NO8nc7LxJl6PNoqq67T210I6rfIwmJjY1g_Nf1gPdhEJCp6RKaG0sc8GBg6T7eTgMbLV-D3N478DIY7h0Q5oy_lWZ2hZIEMJMErmKRFWm3a4Vk5Vz_VhrkhMbAi5bqk/s1600/Board.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEie6kdl5Q141dl1NO8nc7LxJl6PNoqq67T210I6rfIwmJjY1g_Nf1gPdhEJCp6RKaG0sc8GBg6T7eTgMbLV-D3N478DIY7h0Q5oy_lWZ2hZIEMJMErmKRFWm3a4Vk5Vz_VhrkhMbAi5bqk/s1600/Board.jpg" height="360" width="540" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Pawel, Klaus, and Markus grabbing their well-deserved Whisky ;-)</td></tr>
</tbody></table>
<br />
Looking at the talks I think we‘ve managed to put together a great variety of good speakers and interesting topics. Thanks to the rest of the board: Pawel, Klaus, Wolfgang, Karl and Markus. You guys rock!<br />
<br />
See all of you in Hamburg. If you haven‘t done yet, register today: <a href="http://www.lkce14.com/register">www.lkce14.com/register</a><br />
<br />
<br />
P.S. In case you wonder about this year‘s keynotes: After trying for the last three years, we finally managed to get Henrik Kniberg as well as Tom and Mary Poppendieck. No further introduction required:-) The third one will be Don Reinertsen who will speak about Robustness this year.Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com1tag:blogger.com,1999:blog-1423003429632694999.post-57314466177307816982014-05-22T16:21:00.002+02:002014-05-22T16:21:36.826+02:00Stop bashing managers!<div class="MsoNormal">
Recently I‘ve heard people say things like: „If we only could
get rid of all managers, life would be good.“ Or „A truly agile organization
does not have any managers.“ While I agree that many organizations do need a
different <i style="mso-bidi-font-style: normal;">kind</i> of management, I
deeply disagree with the notion of getting rid of all managers. Here’re some
reasons why.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>It’s insulting</b><o:p></o:p></div>
<div class="MsoNormal">
At the Lean Software and Systems Conference 2012 (before being renamed
to Lean Kanban North America) I saw a great Lightning Talk which startet with
the following, made-up, pie chart (and as you know, I like made-up charts):<o:p></o:p></div>
<div class="MsoNormal">
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjguOv75YTw4H8GjdgkkEOROIxpm5j8MM6V5rRKFLW3mG1B5VEA3dUzIiAkhLoueAYGRsLoPvrA7KAukqM4mwGEWcJKhtFMox8cmSH3AK7KBwlZm_gbOZOWWDzOdZcI0paJnm7WXjvkW2c/s1600/PieChartManagers.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjguOv75YTw4H8GjdgkkEOROIxpm5j8MM6V5rRKFLW3mG1B5VEA3dUzIiAkhLoueAYGRsLoPvrA7KAukqM4mwGEWcJKhtFMox8cmSH3AK7KBwlZm_gbOZOWWDzOdZcI0paJnm7WXjvkW2c/s1600/PieChartManagers.png" height="322" width="400" /></a></div>
<br /></div>
<div class="MsoNormal">
<div class="separator" style="clear: both; text-align: center;">
</div>
<br /></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
What the chart basically says is that in reality we have
very much managers, like it or not. And my experience is: Most of the managers
are good people. If they do what we consider bad management, it is mostly due
to strange policies and bonus systems that were in place and influenced their
behavior.<o:p></o:p></div>
<div class="MsoNormal">
If we say that we need to get rid of management, we will
most likely insult all these people – no matter if we intend to do so or not. They
will hear things like: „These guys think that I have done a bad job in the last
10 years.“ I don’t thing this is the way to go if we want to change the world
of work.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Setting missions and aligning teams</b><o:p></o:p></div>
<div class="MsoNormal">
Although I consider myself a pacifist, I am a big fan of the
concept of Auftragstaktik and its implications for business. If you haven’t
done already, I really recommend reading the book <a href="http://www.amazon.com/The-Art-Action-Leaders-between/dp/1857885597/ref=sr_1_1?ie=UTF8&qid=1400762812&sr=8-1&keywords=the+art+of+action" target="_blank">The Art of Action by StephenBungay</a>. You can also find a free interview with him <a href="http://www.lkce13.com/2013/09/12/i-m-afraid-that-some-leaders-do-actually-think-they-are-god-interview-with-stephen-bungay/" target="_blank">here</a>. <o:p></o:p></div>
<div class="MsoNormal">
We like autonomous teams that figure out how to accomplish
their mission for themselves. They experiment their way forward through unknown
territory and they will figure out how to do it. But where do the missions come
from? And how do we make sure the missions of our different teams are aligned
with each other? Sure, in theory the teams could set their own missions and
coordinate them with other teams. My experience just tells me that this is very
hard (if not impossible) for teams to do. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Managing interactions<span style="mso-spacerun: yes;">
</span>and (re-)designing the system</b><o:p></o:p></div>
<div class="MsoNormal">
According to Russell Ackoff, „The performance of a system is never
the sum of the performances of its parts. It’s the product of their
interactions.“ If we agree with Ackoff’s statement (and I’ve seen a lot of
evidence for this at different occasions) then someone has to manage the
interactions of our system’s parts. In the Agile world teams are probably the
most important parts of an organization. Who is responsible for managing how
the teams interact with each other? Again, theoretically it could be the teams
themselves. In practice I doubt that this will work very well (and I will argue
why in the section about local optimization).<o:p></o:p></div>
<div class="MsoNormal">
Another aspect that’s relevant when talking about Ackoff and
Systems Thinking is the design and re-design of our system. As far as I can
tell, Ackoff was not convinced that continuous improvement is always the best
solution. My friend Markus Andrezak likes this quote by Ackoff very much: „To
be ahead of the competition you need o leapfrog them.“ What is true for product
development is also true for our processes. Ackoff’s examples of how to improve
organizations contain a lot of major re-designs. Deming argues in a similar
way: Because it’s the system that causes the biggest part of the performance
(Hi, Pawel<span style="font-family: Wingdings; mso-ascii-font-family: Cambria; mso-ascii-theme-font: minor-latin; mso-char-type: symbol; mso-hansi-font-family: Cambria; mso-hansi-theme-font: minor-latin; mso-symbol-font-family: Wingdings;"><span style="mso-char-type: symbol; mso-symbol-font-family: Wingdings;">J</span></span> I
think Deming talks not only about variability here, but also about
performance!), and not the individuals, we need to change the system if we want
real improvement. According to Deming, this is exactly what (good) managers are there
for.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Recognizing local optimization<span style="mso-spacerun: yes;"> </span></b><o:p></o:p></div>
<div class="MsoNormal">
Agile teams are supposed to work on accomplishing their
mission with a laser-focus, and thereby with great speed. That’s one of the
main reasons why we set them in place. But this focus comes with a price: local
optimization. The Don of Lean (Don Reinertsen) argues that we will most likely
see local optimization when the benefits and the costs of an action occur at
different places in the system (see <a href="http://vimeo.com/45947817" target="_blank">this great talk by Don</a> for deeper insights). This
fits my observations with autonomous teams: They tend to sub-optimize the whole
in order to optimize their team’s outcomes. Nothing to complain about here. We
cannot expect teams to focus on their missions and take care of the whole
company at the same time. And, again, it’s exactly what Systems Thinking tells
us (you can probably tell by this post that I’ve been reading a lot of Ackoff’s
stuff recently:-): „If you optimize the parts, you will sub-optimize the
whole.“ If I get this right, one conclusion of this is that someone needs to
have a bird’s eye view on the system to recognize when local optimization is
about to happen. Yes, I do think the big picture is important (although it has
become a kind of a bad word).<o:p></o:p></div>
<div class="MsoNormal">
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhdeh2FUlvh30RndmQmkE5sQJDpcyzoYjB4hHQGSN76L9gPP7C0lFy-2OxzQw9OKp2nLxUlSrG1vV_F7zZ3yJpXJSVHVbMln8WEVfW26TB6kGtP6sq-NWceRPC4N2uNMdMnd0bphrAWMyY/s1600/RussellAckoff_web.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhdeh2FUlvh30RndmQmkE5sQJDpcyzoYjB4hHQGSN76L9gPP7C0lFy-2OxzQw9OKp2nLxUlSrG1vV_F7zZ3yJpXJSVHVbMln8WEVfW26TB6kGtP6sq-NWceRPC4N2uNMdMnd0bphrAWMyY/s1600/RussellAckoff_web.png" height="400" width="287" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Russell Ackoff - read his books!</td></tr>
</tbody></table>
<br />
<br /></div>
<div class="MsoNormal">
<b>Changing the team setup</b><o:p></o:p></div>
<div class="MsoNormal">
Teams are capable of doing remarkable things. I’ve seen
teams that were considered to be the worst performers in the company improve
dramatically and perform really well after some of their boundaries were
changed. At the same time it’s true that sometimes teams are highly
dysfunctional and that they won’t change without external influence. As a last
resort, taking people out of the team, adding new people to an existing team,
or even abolishing a team completely can be the right thing to do. Teams have a
<i>very</i> hard time doing this without external help. In many cases they will
not even realize that there is a dysfunction or, when they do, they won’t talk
about it to anyone. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Conclusion</b><o:p></o:p></div>
<div class="MsoNormal">
First of all we should not offend all the people with
management titles out there. <o:p></o:p></div>
<div class="MsoNormal">
Further more I’ve argued that we need people who are not part
of our autonomous teams. They need a good standing in the organization and mus
have a good understanding of our systems. They are responsible for managing the
team’s interactions, re-designing the system and observing and acting upon
local optimization. And sometimes they need to change the setup of a team. For me, that’s exactly what a good manager does. So let’s
stop bashing managers and start working on establishing another understanding
of management!</div>
<div class="MsoNormal">
<o:p></o:p></div>
Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com2tag:blogger.com,1999:blog-1423003429632694999.post-65037504798055195432014-01-02T18:28:00.000+01:002014-01-02T18:28:57.138+01:00Why I work with Jimdo nowToday was my first day with my new employer <a href="http://www.jimdo.com/" target="_blank">Jimdo</a>. For the last nine years I worked with <a href="http://www.it-agile.de/" target="_blank">it-agile</a> in different positions, the last three years as a coach/consultant and trainer for Kanban. I‘ve learned so much during this time and and got to know so many different companies - small startups and agencies as well as medium sized companies and some large multinational corporations. I still think it-agile is one of the coolest companies on the planet, and I am really grateful to my colleagues, especially <a href="http://www.henningwolf.de/" target="_blank">Henning</a> and my brother <a href="http://www.stefanroock.de/" target="_blank">Stefan</a>. And if you are into Agile and like to coach and train people, I strongly recommend that you consider applying for a job there!<br />
<br />
So why did I decide to leave it-agile then? As you can imagine, it was a very tough decision. The main reason is: I am really curious what it feels like to go to the "other side of the fence" and work with a product company long term. For me, one of the biggest upsides of working as a consultant can also be a big downside: You see a lot of different organizations and talk to so many interesting people. At the same time chances are that you leave an organization and start a new engagement when the first steps are taken (and starts becoming really interesting). And even if you are involved for a longer period of time, you will always stay an outsider - you can participate in the successes of your client, but still you are always the external consultant. So I decided that it‘s time for me to move on and start a new career as an embedded person in a product company.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjwn_IPvYFWDS2R573nxCZ3AC4IteFUWngFIXYaux7bMDfabFYNVSTbhFS8cpyLdnVJ1ywjycYhB718zGoUJb_knMbKCyW_FMgXWJWpI2-uR0OzeTeRW6vZ3YyARR6DU8a4jemcmFomOXU/s1600/jimdo_logo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="105" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjwn_IPvYFWDS2R573nxCZ3AC4IteFUWngFIXYaux7bMDfabFYNVSTbhFS8cpyLdnVJ1ywjycYhB718zGoUJb_knMbKCyW_FMgXWJWpI2-uR0OzeTeRW6vZ3YyARR6DU8a4jemcmFomOXU/s320/jimdo_logo.png" width="320" /></a></div>
<br />
Why Jimdo? I first met the Jimdo guys back in 2010. Since then we always stayed in touch and one day they asked me to do some coaching with them. So they have been my client for the last three years, and many Jimdudes became my friends quite quickly. When I first visited their office, I felt immediately that this company is special, and there were so many situations where this impression was renewed. Here are just a few examples: Having a Feelgood Manager (<a href="http://de.jimdo.com/presse/pressemitteilungen/feelgood-und-kultur/" target="_blank">watch this video about Feelgood Management (German)</a>), an architect (and I am not talking about a software architect here) and a chef working at Jimdo; a napping room and a fancy aquarium room everyone can use when he/she needs to rest; no time tracking; really self-organized and empowered teams etc.<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBwGLofmOBHV3daviivUsaW5WfYMmJ-k0WlQtSRUdwJAaKWpyuBmKfc8NkPfRpEOvGB99K3QCdl99kVziNGOVTbWb8MuwAdQ-f3n_Oew1hk4xawoAdLWA3xjllFgBiGB80rFBToFAKtvg/s1600/Jimdo_Pics.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiBwGLofmOBHV3daviivUsaW5WfYMmJ-k0WlQtSRUdwJAaKWpyuBmKfc8NkPfRpEOvGB99K3QCdl99kVziNGOVTbWb8MuwAdQ-f3n_Oew1hk4xawoAdLWA3xjllFgBiGB80rFBToFAKtvg/s1600/Jimdo_Pics.jpg" /></a></div>
<br />
<br />
And these are only the obvious, observable things. Even more important is the really amazing company culture! And of course a great product with a great deal of innovations to come in the future! You might have noticed, that I am quite excited about my new employer;-)<br />
<br />
<br />
What will I do at Jimdo? Here you can see a clipping from my contract of labor.<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhw55m5G7RTtUKBL3Qu8mVDZLLcwpRKQz3MJ5mhTYW9xTVu4DrgtPcZtCTBMcUC0mM4AGn1pYrOZaJ7KsKkJcxChurGZL6v2bTrBQJ9B9qZQZNOXfYeonC_mc6vq487ch3KgZQkuO0kLTo/s1600/Vertrag.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhw55m5G7RTtUKBL3Qu8mVDZLLcwpRKQz3MJ5mhTYW9xTVu4DrgtPcZtCTBMcUC0mM4AGn1pYrOZaJ7KsKkJcxChurGZL6v2bTrBQJ9B9qZQZNOXfYeonC_mc6vq487ch3KgZQkuO0kLTo/s1600/Vertrag.jpg" /></a></div>
<br />
<br />
For those of you who don‘t understand German: It says that I will be employed in my role as "Dr. Rock" from January 2014 on. What does it mean to work as "Dr. Rock?" I don‘t know exactly, and neither do the founders who hired me:-) The important thing for both parties was that we wanted to work with each other and that there was a huge amount of mutual trust. So we decided to sign the contract and figure out later what exactly my tasks would be. Now you might understand why I wrote that Jimdo is special.<br />
<br />
And what did I do on my first day? Started my two day internship at the awesome support team. And as expected, I learned really much about our customers!<br />
<br />
P.S. If you are interested in Jimdo, check out the blog post I wrote about the <a href="http://www.software-kanban.de/2013/11/open-prioritization-meeting.html" target="_blank">Open-Prioritization-Meeting</a>, the <a href="http://www.software-kanban.de/2013/10/supporters-to-teams.html" target="_blank">support</a> and our <a href="http://www.software-kanban.de/2013/03/coffee-beer-and-taxi-rides-or-visiting.html" target="_blank">trip to Stockholm</a>Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com3tag:blogger.com,1999:blog-1423003429632694999.post-57954027461945563912013-12-16T16:08:00.002+01:002013-12-17T12:42:20.768+01:00Reviewing Lean Kanban Central Europe 2013Exactly six weeks ago the Conference <a href="http://www.lkce13.com/" target="_blank">Lean Kanban Central Europe 2013</a> took place. After Munich in 2011 and Vienna in 2012, it was Hamburg this time - not only my home town but also one of the best places in the world:-)<br />
My involvement was threefold: As organizer, board member and speaker. Here are my thoughts from these three different perspectives.<br />
<br />
<h2>
The organizer‘s perspective</h2>
What we try to do with LKCE is to create a special atmosphere. Therefore the venue is critical for us. We avoid typical conference hotels etc., which makes the organization more challenging and also more expensive, but I am confident that it‘s worth it.<br />
This year we choose the Curio Haus as the venue, and it turned out really well. An old building with great atmosphere, plenty of space for socializing, two prestigious ball rooms and great staff!<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8DcXMRaRgNyV-cX8GhNOnPzWIYESMZ30_KJN9inWclno9vo4MRyRUCtGWBMRDARbn5Jn1l0dIS5fBHP4gf3d1OdTz9W0V-yOJoPd6jUD7sCfxbDUudAQuu4xful7978RN6SDbBthnOCQ/s1600/20131104-DSC_8535.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEj8DcXMRaRgNyV-cX8GhNOnPzWIYESMZ30_KJN9inWclno9vo4MRyRUCtGWBMRDARbn5Jn1l0dIS5fBHP4gf3d1OdTz9W0V-yOJoPd6jUD7sCfxbDUudAQuu4xful7978RN6SDbBthnOCQ/s400/20131104-DSC_8535.jpg" width="400" /></a></div>
<br />
In my opinion the only real downside was that the third rooms was too small. I didn‘t see that coming as I thought the attendees would behave differently - one big learning for next year!<br />
Experience has told me that there are two very important things when organizing a conference (besides the venue and the program): Stable Wi-Fi and good coffee supply. Both worked great this time:-)<br />
What I like about old buildings is that they provide great opportunities for extras. This year we used the big cartridges in the hallways for exhibiting 16 great quotes. When David Anderson saw this, he tweeted them one by one with the hash tag #EssenceOfKanban. <a href="http://jasnawittmann.de/" target="_blank">Jasna Wittmann</a> is the artist who did the great calligraphy!<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilkIrgGc9FAVqz0ahiXslRRgnNrKDnW1X8X5wOi96q2KXKI8pkOD0XDYrLqbDs2lefhmexZj1ls7SQuzUC7lFpnDvt6w1PPiyfdTvDgPC8g2p2_Foi8_1X4G4Vvz3oWROApxQ5A7ioR14/s1600/20131104-DSC_8558.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEilkIrgGc9FAVqz0ahiXslRRgnNrKDnW1X8X5wOi96q2KXKI8pkOD0XDYrLqbDs2lefhmexZj1ls7SQuzUC7lFpnDvt6w1PPiyfdTvDgPC8g2p2_Foi8_1X4G4Vvz3oWROApxQ5A7ioR14/s400/20131104-DSC_8558.jpg" width="400" /></a></div>
<br />
Another thing we lay emphasis on is to have a great social event on the first evening. This is, again, a costy thing to do, but we see great value in attendees chatting with each other over a beer in an exciting atmosphere. This year we booked the <a href="http://www.miniatur-wunderland.com/" target="_blank">Miniatur Wunderland</a>, which is the world‘s biggest model railway with its 900 trains + 12,000 wagons traveling several hundreds of kilometers is brought to
live. Over 200,000 figures in different parts of the world like Scandinavia and the North-East Sea with its 30,000 liters of water, Germany or America.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEileZbUWrim8Os5oOLPlc-mYCjzuLjyQ5-RInh6lyHqb0Prj3oH6nMqoFW9Uyr2kYI3fPCAqYimJAkMPnQ-vXXypR5iW-yhNoT_SJyVT4nkY10iDvLFVJB5TXnkaU3pklxm6KBIleInilQ/s1600/20131104-DSC_9168.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEileZbUWrim8Os5oOLPlc-mYCjzuLjyQ5-RInh6lyHqb0Prj3oH6nMqoFW9Uyr2kYI3fPCAqYimJAkMPnQ-vXXypR5iW-yhNoT_SJyVT4nkY10iDvLFVJB5TXnkaU3pklxm6KBIleInilQ/s400/20131104-DSC_9168.jpg" width="400" /></a></div>
<br />
All in all I am very happy how the organization went and I want to say thank you to my colleagues who organized all this!<br />
<br />
<h2>
The board member‘s perspective</h2>
For the third time in a row we had the great board with Markus Andrezak, Pawel Brodzinski, Karl Scotland, Klaus Leopold an me (Hermanni Hyytiälä couldn‘t make it this time). These guys are not only really knowledgeable, but it‘s also a lot of fun to work with them!<br />
<br />
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbvJbuXDwovH9GxfjzH9vs2v-ok92SNG38YrUyhdmOcPf3nrRAVWv84oW1Gc4Z9CoOTNgOFKIcjY67lcBkvb70E2Aq936-D3k0_zmH-fmUP7-vARojYhYvpy7mFok58oTZqmQ5Yg9t8kM/s1600/20131105-DSC_9338.jpg" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhbvJbuXDwovH9GxfjzH9vs2v-ok92SNG38YrUyhdmOcPf3nrRAVWv84oW1Gc4Z9CoOTNgOFKIcjY67lcBkvb70E2Aq936-D3k0_zmH-fmUP7-vARojYhYvpy7mFok58oTZqmQ5Yg9t8kM/s400/20131105-DSC_9338.jpg" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">The board members get a bottle of the Whisky "Work in Progress", which needs to be limited:-)</td></tr>
</tbody></table>
We choose to have a mixture between invited sessions and sessions choosen from our open review process. The <a href="http://www.lkce13.com/program/" target="_blank">program</a> worked well for me. What we took away from the feedback was that there is demand for more practical sessions like experience reports and that we need to create even more opportunities for the attendees to get in touch with the speakers and other attendees. We already started a discussion how to do this...<br />
I couldn‘t attend too many sessions, but my personal highlight was Stephen Bungay‘s keynote on The Executive‘s Trinity. Stephen is an expert on military history and strategy and the most eloquent speaker I have ever witnessed. Although I consider myself to be a pacifist, I find the concept of Auftragstaktik etc. really enlightening for business (and I am happy Stephen said in his talk people should do better things than slaughter each other!) I really recommend reading his book <a href="http://www.amazon.com/The-Art-Action-Leaders-between/dp/1857885597/ref=sr_1_1?ie=UTF8&qid=1387202459&sr=8-1&keywords=the+art+of+action" target="_blank">The Art of Action</a>. His keynote from lkce13 is not publicly available on video, but if you are interested in leadership and management, you should read <a href="http://www.lkce13.com/app/download/8243863695/Executives+Trinity%2C+360+Summer2011.pdf?t=1384275269" target="_blank">this free article</a>.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0qsM-gw_74OtX93YqEAG9qpH8lRruQquEebVawpkueDX0PqLVDlwRdxJr2RVQuNpww_cwxwwoA4S8L8PevagHO162NzFfOCP7wGWs7qc0IQWPcU-FcegEOTC2TZgeTml8WkxgLVmDdLc/s1600/20131105-DSC_9378.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="266" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEh0qsM-gw_74OtX93YqEAG9qpH8lRruQquEebVawpkueDX0PqLVDlwRdxJr2RVQuNpww_cwxwwoA4S8L8PevagHO162NzFfOCP7wGWs7qc0IQWPcU-FcegEOTC2TZgeTml8WkxgLVmDdLc/s400/20131105-DSC_9378.jpg" width="400" /></a></div>
<br />
<br />
The second talk I want to point you to is Troy Magennis‘ keynote on cycle time forecasting. Especially if you are working in a big project environment, predictability is important for you and you are not satisfied with your estimates, you should definitely check out his presentation! As far as I can tell, his stuff is rock solid and it contains a lot of surprising news. And it increased my interest in statistics:-) You can <a href="http://www.lkce13.com/videos/magennis" target="_blank">watch his keynote here</a>.<br />
<br />
Almost all presentations, including Pecha Kuchas, Lightning Talks and experience reports from companies like Ericsson, Siemens, Spotify, SAP, Jimdo have been videotaped and are <a href="http://www.lkce13.com/videos" target="_blank">available here</a>.<br />
<br />
<h2>
The speaker‘s perspective</h2>
I had a full blown presentation about <a href="http://www.lkce13.com/sessions#jimdo" target="_blank">Kanban, Leadership and Alignment with Jimdo</a> together with my dear fellow Fridtjof Detzner which went quite well.<br />
In addition I gave a Pecha Kucha talk (20 slides on auto pilot, each 20 seconds). The Pecha Kuchas were well-received the last two years, so we decided to do them keynote-style this time (i.e. no parallel sessions). That was quite an amazing feeling to speak in front of 300 people in a big old ballroom! My topic was "Learning from Fake Charts". I wanted to talk about some things that puzzle me regarding things like Toyota, Complexity or Lean Startup, without taking myself too serious. So I came up with 12 fake charts to make my points. The preparation was really fun, and I was quite satisfied with the outcome. But once again I had to learn the hard way how much effort it takes to create and practice a smooth Pecha Kucha! If you have 6 minutes and 40 seconds, you should have a look at the video: <br />
<iframe allowfullscreen="" frameborder="0" height="281" mozallowfullscreen="" src="//player.vimeo.com/video/80365303" webkitallowfullscreen="" width="500"></iframe>
<br />
<br />
<h2>
Next year</h2>
As I will leave it-agile and start working with <a href="http://www.jimdo.com/" target="_blank">Jimdo</a> from January on, it-agile will loose some knowledge and experience about the conference‘s organization (although I am sure that most people over-rate my personal contribution to the success of the event). Therefore decision was made to simplify next year‘s organization and do it in Hamburg again. I think it‘s a good choice! LKCE14 will take place in the Curio Haus again (with a bigger third room, we promise!). The date is already set: Nov 11-12 2014. Check out <a href="http://www.lkce14.com/">www.lkce14.com</a><br />
I will stay involved in the conference as a member of the board and by sharing ideas and experiences with the <a href="http://www.it-agile.de/" target="_blank">it-agile</a> guys.<br />
I am absolutely sure that the best LKCE conference is always the next one, so stay tuned!<br />
<br />
<br />
P.S. We‘ve invented the KanBanana at the conference:-)<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbHWMZGtlA0GBF1_1-LjPjHXQ74X5XbUIaZxTL5K-pJL1hrIFdBikVQSrFbJwDshiRMx-vjlf1IOFAvxMq6A6h_s9PQWNPFg5VQFSzV29fPDFA27bn3eZUdtUMiwLmgXq1QG4jLDs_BYc/s1600/BYTNgQRIYAA_jeA.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="253" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjbHWMZGtlA0GBF1_1-LjPjHXQ74X5XbUIaZxTL5K-pJL1hrIFdBikVQSrFbJwDshiRMx-vjlf1IOFAvxMq6A6h_s9PQWNPFg5VQFSzV29fPDFA27bn3eZUdtUMiwLmgXq1QG4jLDs_BYc/s400/BYTNgQRIYAA_jeA.jpg" width="400" /></a></div>
Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com0tag:blogger.com,1999:blog-1423003429632694999.post-50482956890918504492013-11-12T17:48:00.000+01:002013-11-12T17:48:06.220+01:00Open Prioritization Meeting<div dir="ltr" id="docs-internal-guid-16ecbc25-482c-7c75-ba2b-a1beca18b827" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;">When I first visited</span><a href="http://www.jimdo.com/" style="text-decoration: none;"><span style="color: black; font-family: Arial; font-size: 16px; vertical-align: baseline;"> </span><span style="color: #1155cc; font-family: Arial; font-size: 16px; text-decoration: underline; vertical-align: baseline;">Jimdo</span></a><span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"> back in 2010, I saw a thing called “Team Wall” - a big wall painted in black, magnetic paint. The idea behind it was simply to use all the creativity of all the great people who work at Jimdo. So everyone who had an idea on how to improve the product, took a piece of paper, wrote down his suggestion, and attached it to the wall. This seemed to work out very well, because not long after starting, the wall was dotted with paper. However, what seemed to be a huge success, turned out to also yield a couple of problems. Many of the ideas hung on the wall for weeks or months - and many of them were never followed up at all. They were good, but did not fit within the business strategy. Or - they were good, but too many other ideas were even better. Nadja, the Flow Manager at Jimdo, often said: “This is not a black wall; It‘s a black hole!” This state created a lot of frustration. They were asked to share their ideas, but most of them were not pursued. And the reasons for this never became clear to them, so the idea wall was abolished again.</span></div>
<div dir="ltr" id="docs-internal-guid-16ecbc25-46de-6b37-881a-55a8c2f5bb7e" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<br />
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;">The team wall story is another example of a huge problem that occurs over and over again when companies create (or even just allow) big queues. These queues are almost always seen as a “place of unloading”, but without a common understanding of what happens to all the items after they are put in the queue. Furthermore, queues have this really annoying habit of growing and growing. So when items are not being removed, it becomes less and less likely that the things in the queue will ever be completed at all. The bigger the queue, the more effort it takes to manage it. This means that things will be overseen, duplicates sneak in, etc.</span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><br /></span></div>
<table align="center" cellpadding="0" cellspacing="0" class="tr-caption-container" style="margin-left: auto; margin-right: auto; text-align: center;"><tbody>
<tr><td style="text-align: center;"><a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLEM0W_Kp5puQdp1uZtNjULyulPHcAVYHHH5XebDKt89jEOK4nLbYlKtSw3oV0bQ6kciasEE9HxYHI9Rhk5KYTCUYfNbbl668HeK7SZA7e1qCVEY-faJDmQzQVPfStBssJhGE7nSwyu3k/s1600/Zettelstapel.png" imageanchor="1" style="margin-left: auto; margin-right: auto;"><img border="0" height="326" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEjLEM0W_Kp5puQdp1uZtNjULyulPHcAVYHHH5XebDKt89jEOK4nLbYlKtSw3oV0bQ6kciasEE9HxYHI9Rhk5KYTCUYfNbbl668HeK7SZA7e1qCVEY-faJDmQzQVPfStBssJhGE7nSwyu3k/s400/Zettelstapel.png" width="400" /></a></td></tr>
<tr><td class="tr-caption" style="text-align: center;">Queues lead to overburdening (stress, poor quality, frustration)</td></tr>
</tbody></table>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><br /></span></div>
<br />
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"></span>
<br />
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<div dir="ltr" id="docs-internal-guid-16ecbc25-482c-b8db-b946-61d93a14b1ac" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;">Jimdo’s experience with the team wall was one major reason for introducing a concept which they call </span><span style="font-family: Arial; font-size: 16px; font-style: italic; vertical-align: baseline;">Open Prioritization Meetings</span><span style="font-family: Arial; font-size: 16px; vertical-align: baseline;">. The first team to start this meeting was the Feature Team, which is called “Captain Feature”. The mission of this team is to maintain and improve the Jimdo CMS, which is pretty much the core of the whole Jimdo application. Besides the end users, the Feature Team has a couple of internal customers: The Shop Team, the Payment Team, the Support Team, the Country Teams, etc. So, the Feature Team can also be seen as a service provider for their colleagues. This again led to a huge queue, although this time, a digital one. Over time the different teams had created tickets for each of their requests, and put them into the issue-tracking system. Very often, the expectation was: “Now that I have placed my order, I just have to wait until it is finished.” But the Feature Team’s capability was less than the overall demand. So the queue (in this case, it was called “Backlog”), grew and grew. And again: dissatisfaction was the result. The Feature Team wanted both to help their colleagues, and to build new features for the end users. This turned out to be impossible, and led to stress and frustration, aware that the queue was constantly growing. The other teams realized that their requests were not being processed, but there was no transparency with the reasons behind this. The Jimdo founders, yet another group of important stakeholders, couldn’t understand why it took so long to build new, strategic features.</span></div>
<div dir="ltr" id="docs-internal-guid-16ecbc25-46de-c0ca-3f84-cd622b9bcec3" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<br />
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;">Since introducing the Open-Prioritization-Meeting, many of these problems have been solved. This is how it works: On a bi-weekly basis, everyone who has a request for the Feature Team is invited to come to their room and bring his ticket(s). The different stakeholders then pitch their ticket, explaining why they think that this particular ticket has a high business value for the company, and should be done next. After this, the team, together with Fridtjof (one of the founders), decides which tickets they will accept for the next two weeks, and which ones they reject. The principle behind this meeting is: “Never make promises you can’t keep!” A prerequisite for this is that the team must know its capability: How many new tickets can they manage? How big can these tickets be?</span></div>
</div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg44_4UVQJFuImXcoVM0VMSeEFOqgQ5WCFct4Vdxd9PEgoDUpkMWNJ-d5YwHrJu1aZ9aN3uArRC5EPEYI8VvqHggSa_WPz5QfmaQAat5Mp27yFpDBvupO0Zmp4XBhAbuNhV71YC34IcijE/s1600/DiscussionBoard.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="326" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg44_4UVQJFuImXcoVM0VMSeEFOqgQ5WCFct4Vdxd9PEgoDUpkMWNJ-d5YwHrJu1aZ9aN3uArRC5EPEYI8VvqHggSa_WPz5QfmaQAat5Mp27yFpDBvupO0Zmp4XBhAbuNhV71YC34IcijE/s400/DiscussionBoard.png" width="400" /></a></div>
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<div dir="ltr" id="docs-internal-guid-16ecbc25-482c-f7f0-cac9-ecd95d78aadd" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;">The tickets that are not accepted at this time, are returned to the stakeholders immediately. Sometimes people are told: “Please come back with this request in 8 weeks.” And sometimes it is decided that a request won‘t be done at all. Of course it is frustrating for the person whose ticket is rejected - but it‘s better having this initial frustration, than having false hope that cannot be fulfilled. In that case, the frustration would kick in later - and much harder. The Open-Prioritization-Meetings ensure that there is no Backlog of stakeholder requests. In our experience, this is the best kind of expectation management!</span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;">And, by the way, the Open-Prioritization-Meeting usually only takes 30-45 minutes.</span></div>
<br />
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"></span>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;">Although this format is quite new, we’re already seeing a couple of positive effects:</span></div>
<ul style="margin-bottom: 0pt; margin-top: 0pt;">
<li dir="ltr" style="font-family: Arial; font-size: 16px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="vertical-align: baseline;">The team’s capability is more visible. Now it’s possible to avoid overloading the team - and at the same time, measures are taken to increase the capability.</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 16px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="vertical-align: baseline;">Queues lead to stress. (“Look at all the work we have to finish! We can never do this!”) By abolishing the queue, the stress level decreased.</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 16px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="vertical-align: baseline;">During the meetings, the stakeholders communicate directly, as opposed to the ticket system before. This prevents misunderstandings and builds trust.</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 16px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="vertical-align: baseline;">The different teams have valuable discussions about what their most important request is, because they know that only 1-2 items will be accepted.</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 16px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="vertical-align: baseline;">Everyone who is present at the meeting learns the reasons why certain things are worked on, and others aren‘t. Fridtjof is forced to lay out the company strategy on a regular basis (“Your idea is good. But this year we want to focus on another target group. The reasons for this are X, Y and Z. So we won‘t do your thing this year.”) In this case, Open-Prioritization-Meeting is a means of educating the employees, with respect to understanding and improving the company strategy.</span></div>
</li>
<li dir="ltr" style="font-family: Arial; font-size: 16px; list-style-type: disc; vertical-align: baseline;"><div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="vertical-align: baseline;">In the duration of the meeting, there is an incredible amount of knowledge and experience from different disciplines gathered in this one room. So it‘s possible to find simple and creative solutions immediately: “I have an idea how we could do this with very little effort. Would you be satisfied with an 80% solution?” or “Can you do this by yourself, if we give you access to this system?”</span></div>
</li>
</ul>
<br />
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"></span>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span id="docs-internal-guid-16ecbc25-482d-3834-3f5a-0e1f006a075a" style="font-family: Arial; font-size: 16px; vertical-align: baseline;">The Feature Team was the first team to experiment with Open-Prioritization-Meetings. The positive outcomes have encouraged others to do a similar thing. Right now, more and more other teams are starting to figure out how this meeting should look in their environment.</span></div>
<br />
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"></span></div>
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><br /></span>
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><br /></span>
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJXMHqKg2fA5iq5wXSjZlOAUGzyNOgFMUXlOEobrxYtBUouPyS1PDl8u9zHvWV8aEKmK_dtOCvubobziL9wX4EYAhJSrb6KsUuYZPJSEzcn496Pebzi7nb6d75AN8MkOlNGqmpjJHWOTY/s1600/Cover_JimdoBroschuere.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="320" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiJXMHqKg2fA5iq5wXSjZlOAUGzyNOgFMUXlOEobrxYtBUouPyS1PDl8u9zHvWV8aEKmK_dtOCvubobziL9wX4EYAhJSrb6KsUuYZPJSEzcn496Pebzi7nb6d75AN8MkOlNGqmpjJHWOTY/s320/Cover_JimdoBroschuere.jpg" width="312" /></a></div>
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><i>This story is part of a free ebook about Jimdo which is called "Doing things differently. Leadership, Management and Alignment with Jimdo." <a href="http://bit.ly/jimdostory" target="_blank">You can download it here.</a></i></span><br />
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><br /></span>
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><br /></span>
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;">P.S. Eleven (!) years ago, Ron Jeffries wrote a blog post about what he calls "Petition the king" We did not know about this when we started the Open Prioritization Meeting, but both formats are very similar (unless there is no King at Jimdo:-) Thanks, <a href="http://jchyip.blogspot.de/" target="_blank">Yason Yip</a> for pointing us to this! And as an answer to Ron‘s question in the last paragraph: "No, it‘s not madness!"</span><br />
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><a href="http://xprogramming.com/articles/petitiontheking/" target="_blank">Read Ron Jeffries Post</a></span><br />
<span style="font-family: Arial; font-size: 16px; vertical-align: baseline;"><br /></span>Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com0tag:blogger.com,1999:blog-1423003429632694999.post-91169110854664893922013-10-24T19:13:00.000+02:002013-11-23T15:35:21.806+01:00Supporters to the teams!<div dir="ltr" id="docs-internal-guid-18b279ef-e60c-7187-2778-da389edc935b" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Yesterday I wrote about customer support and how it is separated from the rest of the organization in many cases. (<a href="http://t.co/ZbWXs2Qiax" target="_blank">Read Blog Pos</a>t).</span></div>
<div dir="ltr" id="docs-internal-guid-18b279ef-e60c-7187-2778-da389edc935b" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" id="docs-internal-guid-18b279ef-e60c-7187-2778-da389edc935b" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">At </span><a href="http://www.jimdo.com/" style="text-decoration: none;"><span style="color: #1155cc; font-family: Arial; font-size: 15px; text-decoration: underline; vertical-align: baseline;">Jimdo</span></a><span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">, one of my clients, we discussed this topic quite often, and Jimdo (once again) is doing things differently when it comes to support work. Here are some details which might be worth sharing.</span></div>
<div dir="ltr" id="docs-internal-guid-18b279ef-e60c-7187-2778-da389edc935b" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="http://bracki.github.io/cukeup/file/about/logo.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="252" src="http://bracki.github.io/cukeup/file/about/logo.png" width="320" /></a></div>
<div dir="ltr" id="docs-internal-guid-18b279ef-e60c-7187-2778-da389edc935b" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" id="docs-internal-guid-18b279ef-e60c-7187-2778-da389edc935b" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">Quite some time ago, there was a whole lot of support tickets that were directly related to the work of the payment team (or „painment team“ how they used to call it at that time). Everyone who has ever tried to provide credit card payment for his services knows that everything related to payment is a big pain in the a...</span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">So at this point it felt natural to have a support person directly in the team. This was a huge lever! The developers could understand better what problems the customers were facing, and the supporter got a better impression of what was going on in the payment team and shared this knowledge with the other supporters. They were so satisfied that they never thought about releasing the supporter from the team again. The opposite was true - they conducted an experiment: What would happen if we pair-program with the supporter? Sounds silly? Again, it was a big success! They gained an even better understanding of the „other world“ (development and support). And something else happened: Not only were they pair-programming, but also pair-supporting. So the developers were „forced“ to deal with real support tickets and use the same tools the supporters use day by day. Here again the very simple trick paid off: Bring together the people who are facing a problem with those who can solve the problem! It turned out that sometimes a developer could simplify support work with rather little effort (e.g. writing a script to automate things), while the support person did not even know that this was possible! So it was no question that the experiment was successful, and know paring with the supporter has become a kind of standard in this team.</span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"> </span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">The payment team might be the perfect fit for pulling a support person in. But why shouldn’t the same principle work for other teams as well? So kind of the next logical step was to do this for all other development teams as well.</span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"> </span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">P.S. When it comes to support, there is another interesting thing going on at Jimdo, which is called Support </span><span style="font-family: Arial; font-size: 15px; text-decoration: line-through; vertical-align: baseline;">Alarm</span><span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"> Party. But that is worth a future blog post...</span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"><br /></span></div>
<div dir="ltr" style="line-height: 1.15; margin-bottom: 0pt; margin-top: 0pt;">
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;"> </span></div>
<span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">P.P.S. Jimdo is one of the the most fascinating company I have ever seen. Fridtjof (one of the founders) and I will present the Jimdo Story at </span><a href="http://www.lkce13.com/" style="text-decoration: none;"><span style="color: #1155cc; font-family: Arial; font-size: 15px; text-decoration: underline; vertical-align: baseline;">Lean Kanban Central Europe 2013 in Hamburg, Nov 4-5</span></a><span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">. Also we have written a small online booklet called „Management, Alignment and Leadership at Jimdo“. You can </span><a href="http://www.google.de/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&ved=0CEAQFjAA&url=http%3A%2F%2Fwww.software-kanban.de%2F2013%2F07%2Fwir-konnen-auch-anders-so-tickt-jimdo.html&ei=JbVmUueMOYnftAa5toGIAg&usg=AFQjCNF7uOpcHdD3F1FhxA7Z3AcYMYZ_2w&bvm=bv.55123115,d.Yms" style="text-decoration: none;"><span style="color: #1155cc; font-family: Arial; font-size: 15px; text-decoration: underline; vertical-align: baseline;">find the German version here</span></a><span style="font-family: Arial; font-size: 15px; vertical-align: baseline;">. And this is the <a href="http://bit.ly/jimdostory" target="_blank">English version</a></span>Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com0tag:blogger.com,1999:blog-1423003429632694999.post-3348846077915439232013-10-23T17:59:00.000+02:002013-10-24T19:14:46.297+02:00Support – shield and sword of the company!During the past couple of years I happened to see a lot of different teams and organizations. Although every organization is unique, there seem to exist some common patterns. The one I find most disturbing is the complete separation of the support department from other parts of the organization! What do I mean by this? There are a couple of development teams (no matter what kind of product or service they are providing). And then there is a support <strike>team</strike> department which deals with customer requests. And there is almost no connection between those two. Often they are located in different buildings, cities or even countries. And in big enterprises it is quite common to even outsource the customer support to a separate company. This is a disaster! The support people are usually the ones with the most customer contact. They know very well who uses the product we are developing (whereas sometimes the developers, project managers etc. seem to not know this); they know very well how our customers use our product, what they like and what they don’t like about it, where they’re facing problems when using our product etc. So they are very, very valuable when it comes to feeding the things we are developing back into the development teams. But usually organizations don’t do that. Or they do a survey once a year to ask the support department what features were requested most often by the customers. Even organizations which are quite mature when it comes to agile software development rarely do so. This strikes me to be absurd, because customer feedback plays such an important role in the agile world. But instead of bringing together the people who have the problems (as represented by the supporters) and those who can solve the problems (the developers, admins etc.), we separate them carefully. This leads to dissatisfied customers and therefore more requests for support. And what do we do? We hire more and more support people and train them to deal very efficient with customer requests. And sometimes we hire other people who should bring the customer perspective back into the teams.<br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoD6SRyFw22WPywVHQIiVkew33KjBreg-63m5FcU30GjL9RCe1YdidqKcmobkFi2qdYpDz3H39Ua-ter699plp-cmAEV5-K9Za37hXl98z5deyjscjTUjChXyroJ0RJYMGybt2wHTbXWM/s1600/Justin12.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="449" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEhoD6SRyFw22WPywVHQIiVkew33KjBreg-63m5FcU30GjL9RCe1YdidqKcmobkFi2qdYpDz3H39Ua-ter699plp-cmAEV5-K9Za37hXl98z5deyjscjTUjChXyroJ0RJYMGybt2wHTbXWM/s640/Justin12.png" width="640" /></a></div>
<br />
<br />
And there is another perspective to this pattern, which makes it even worse. Not only don’t the developers know what the customers want. But the supporters don’t really know what the developers are developing. But the support is the first (and mostly the only) direct contact our customer has with our company. How can the supporters deliver an excellent customer service if they have no clue which features will be developed (and when), which ones are already in progress, which ones won’t be developed at all etc.?<br />
<br />
I hope now it has become clear why I see supporters as the „shield and sword of the company“. But instead of respecting this and using this huge potential, very often organizations treat them as cheap resources. I suggest we start thinking about the role and the value of support and how we can use this potential to deliver better products/services to our customers.<br />
<br />
<i>Stay tuned: Tomorrow I will publish a second post on this topic with an example of how companies can do it differently.</i><br />
<i><br /></i>
<i><a href="http://www.software-kanban.de/2013/10/supporters-to-teams.html" target="_blank">-> Read the follow-up: Supporters to the teams!</a></i>Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com2tag:blogger.com,1999:blog-1423003429632694999.post-71391833658482599952013-09-08T13:44:00.000+02:002013-09-08T13:45:16.964+02:00Let‘s stop talking about waste<div class="MsoNormal">
Recently I‘ve been re-reading a Blog Post on Scrum and Kanban.
Two things struck me: 1) The author seems to believe that one piece flow should
be the goal in knowledge work, and 2) He talked a lot about waste and how to
avoid/eliminate it. <o:p></o:p></div>
<div class="MsoNormal">
I think bothe points are at least debatable. Here are my
thoughts on waste (I will write about one piece flow in another blog post).<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
The distinction between value-adding activities and non
value-adding activities is known from the Toyota Production System, where it is
known to be quite valuable and led to many improvements. During the past
decades there have been plenty of approaches to transfer the concept of
value/waste into knowledge work. The thinking behind this is quite simple:
Gather activities, put them in one of the two buckets and then keep eliminating
the wasteful activities. When I first heard this, it felt totally reasonable to
me. But today I think the concept of waste isn’t useful at all in our domain.
Here are the reasons why (most of them are taken from other people who are
smarter than me. I will reference them).<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
1) It can be insulting<o:p></o:p></div>
<div class="MsoNormal">
If you collect „wasteful“ activities in software
development, you might end up with things like planning, writing documents,
sitting in meetings etc. And as David Anderson points out, you might end up
with a perfect job description of a project manager. It might or might not be
true that these activities are always useful, but by calling them waste, we damage
the self esteem of the people who are performing these activities day by day.
And this doesn’t go together very well with „Respect for people“.<o:p></o:p></div>
<div class="MsoNormal">
Actually, we have experiences exactly this ourselves! At one
of our major clients, we were quite successful with implementing Scrum, and we were
convinced that Lean should be the next step. So we gave a presentation in front
of a group of middle managers. And guess what? They did not like it at all!
From their perspective it sounded as if we wanted to eliminate their jobs and
fire them on the spot. No real discussion about process improvement was
possible, because they were resisting everything we suggesting.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
2) It misses the point<o:p></o:p></div>
<div class="MsoNormal">
The original concept of waste talks about wasteful
activities. But as Don Reinertsen points out in the keynote from last year‘s <a href="http://www.leankanban.eu/" target="_blank">Lean Kanban Central Europe conference</a>,
most often the biggest problems are not the activities, but the non-activities! (Watch the video of Don‘s talk below) We should focus on queues, where tasks sit and wait. Now you might say: „But
waiting is considered waste in Lean!“ That’s correct. But this makes it even
worse! When we consider waiting as waste and eliminate this kind of waste, we
might end up utilizing people with 100% and make them perform (value-adding)
activities all the time. But this is is a desaster in our industry! We don’t
want people to be fully utilized, we want tasks to be utilized! It’s better
that peopel wait for work than the other way around! So instead of looking for
non value-adding activities we should focus on finding and working on the
non-activities – and very often that means we need to utilize people <i style="mso-bidi-font-style: normal;">less</i> than before..<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<iframe allowfullscreen="" frameborder="0" height="281" mozallowfullscreen="" src="//player.vimeo.com/video/53321681" webkitallowfullscreen="" width="500"></iframe> <br />
<br />
<div class="MsoNormal">
<o:p><br /></o:p></div>
<div class="MsoNormal">
<br />
3) It is often simplistic or almost useless<o:p></o:p></div>
<div class="MsoNormal">
Sorting activities into the two buckets „waste“ and
„value-add“ has almost no sense in knowledge work, because you often end up
with truisms. Building features that nobody uses is waste, and we should stop
doing this, right? Yes it is. But this is so obvious, why do we need the
category „waste“ for this? If you just tell people that nobody uses their
featurs, they will immediately understand that they have a problem. And if they
won’t, calling it „waste“ won’t help anyways.<o:p></o:p></div>
<div class="MsoNormal">
So the dichotomy between „value“ and „waste“ is not
sufficient. Let’s introduce a third category, which is quite common. Now we
have „value-add“, „waste“ and „necessary waste“. Again: If you can categorize
something as waste you should just stop doing it. If it is value-adding, then
do more of it. This is trivial. The only interesting category is „necessary
waste“. There have been lots of discussions about things like estimating,
meetings or testing. Are they waste? Not really. Are the value-adding? This
would mean that our customers would pay us more if we did more of this. Would
they pay for more tests? Maybe. Would they pay for more estimates? Probably
not. Would they pay us for doing more standup meetings? Definitely not! But
still we feel that it is a good idea to keep our standup meetings. And I think
we are right (in most contexts)! But the concept of „waste“ and „necessary
waste“ does not help us understand why.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
4) It is binary thinking<o:p></o:p></div>
<div class="MsoNormal">
This thought is, again, taken from Don Reinertsen. Don keeps
saying that we as technically-trained people tend to think in a binary way:
It’s either yes or no, either black or white. This binary thinking is
dangerous, because it prevents us from making good decisions. In most cases it
is not either/or, but a little bit more or a little bit less. Value/waste is a
good example of binary thinking: Something is either value-adding or wasteful
(and if it’s wasteful we might sub-categorize it as necessary or not necessary).
If it’s wasteful, we must eliminate it. I have rarely witnessed a situation
where this thinking was useful and led to new insights and better decisions. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
5) Innovation needs waste<o:p></o:p></div>
<div class="MsoNormal">
This week my friend Henning Wolf pointed me to another
interesting point: Innovation needs waste! Why is that? Let’s have a look at
things like rework, wait times and building things that nobody uses. From a
traditional Lean perspective they must be considered as pure waste and
therefore be eliminated. This might be true in a manufacturing context, but it
is desastrous in an environment where innovation is key. If you have a look at
innovation techniques like Design Thinking, you will find, that they are
celebrating waste! You are building things over and over again, you are
re-building them, you are building completely useless things etc. This is
another example of how important the context of our work is. <o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<b>Thinking about Costs</b><o:p></o:p></div>
<div class="MsoNormal">
So there are many reasons for not using the concept of. But
what should we do instead? I think, it is much more useful to think about costs
that are associated with certain activities. And again it is Don Reinertsen who
advocates this idea the most! So if you haven’t done so, <a href="http://www.amazon.com/The-Principles-Product-Development-Flow/dp/1935401009/ref=sr_1_1?ie=UTF8&qid=1378640201&sr=8-1&keywords=don+reinertsen" target="_blank">buy this book</a> and read
it now! The basic idea is very simple: There is a cost associated
with every activity (and also non-acitivity) we perform. At the same time we
are hoping to get a benefit out of this activity. If the costs exceed the
benefits, it’s not a good investment. The problem is of course how to determine
the costs. The good news is that in many cases we do not need exact
calculations. It’s sufficient to find the sweet spot with the lowest overall
costs. To get an impression what I am talking about, you can <a href="http://vimeo.com/53921412" target="_blank">watch this presentation</a> by Markus Andrezak and me
where we examine the costs for continuous deployment. Thinking about real costs (we are not talking about simplistic
approaches like cutting costs by all means here) is the opposite of binary
thinking – because it’s almost never either/or. In my experience it leads to
very fruitful discussions, and it is very accessible to managers.</div>
<div class="MsoNormal">
<o:p></o:p></div>
Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com2tag:blogger.com,1999:blog-1423003429632694999.post-7222368229652029542013-08-13T08:46:00.000+02:002013-08-13T08:46:23.896+02:00cross-funktionale Teams<br />
<b>-> Want to read the English article? <a href="http://www.lkce13.com/blog/" target="_blank">Click here</a></b><br />
<br />
Wenn wir agil sein wollen, benötigen wir cross-funktionale Teams. Punkt. Oder ist es doch nicht ganz so einfach? Ich habe mich imme rgefragt, was genau ein cross-funktionales Team ist. Vor einer Weile habe ich mich darüber mit meinem Bruder <a href="http://www.stefanroock.de/" target="_blank">Stefan</a> unterhalten. Dabei ist ein Artikel herausgekommen, den wir in der Zeitschrift <a href="http://shopitagile.de/shop/article_18/agile-review-2013_01.html?sessid=YTR0A59X9DrptUxnBsY9WfoNu3xlx5hzF6skw7r0iRDNsmbmmwXwKiQEVCSAJ3Mf&shop_param=cid%3D1%26aid%3D18%26" target="_blank">agile review</a> veröffentlicht haben. Jetzt haben wir uns entscheiden, den Artikel auch online zur Verfügung zu stellen.<br />
Diese Themen werden im Artikel behandelt:<br />
<ul>
<li>Wann kann man von einem cross-funktionalen Team sprechen?</li>
<li>Wie verhält sich Cross-Funktionalität zu Innovation, Geschwindigkeit und Effizienz?</li>
<li>Die Kosten-Seite</li>
<li>Wie können Teams cross-funktionaler werden?</li>
<li>Was haben das A-team und Ocean‘s Eleven mit dem Ganzen zu tun?</li>
</ul>
<a href="http://goo.gl/vVccle" target="_blank">Hier gibt es den Artikel als PDF</a><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgywQUjIrs6kb6yBfA9VYcyjNPKs0Ep74FkoQTjSoVwkGInTkdGBndU6EquGcEJUK-YftL2oOM4eXovTUo46qX-l07XB0_VMdyhSqkX25dVRZcPZoIQDxfViM_Vn5kAuECkJs4ozB2kGGY/s1600/Justin15.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="226" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgywQUjIrs6kb6yBfA9VYcyjNPKs0Ep74FkoQTjSoVwkGInTkdGBndU6EquGcEJUK-YftL2oOM4eXovTUo46qX-l07XB0_VMdyhSqkX25dVRZcPZoIQDxfViM_Vn5kAuECkJs4ozB2kGGY/s400/Justin15.png" width="400" /></a></div>
<span id="goog_1455898406"></span><span id="goog_1455898407"></span><br />
<br />Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com0tag:blogger.com,1999:blog-1423003429632694999.post-55095121350938874322013-07-09T18:00:00.001+02:002013-07-09T18:04:29.746+02:00Wir können auch anders! So tickt JimdoIn den letzten Jahren habe ich mit den unterschiedlichsten Firmen zusammengearbeitet: Von kleinen Startups bis zu multinationalen Konzernen: von Automotive über Elektronik bis zur chemischen Industrie (Herstellung von Farben und Oberflächenbeschichtungen). So unterschiedlich diese Unternehmen auch waren, so lässt sich doch beobachten, dass es einige Probleme gibt, die sehr allgemeiner Natur sind und früher oder später überall auftreten. Die Probleme entstehen meiner Meinung nach durch die Skalierung eines funktionierenden Geschäftsmodells. Was mit einer 20-Personen-Firma funktioniert, klappt dann eben bei 40, 50 und erst recht 100 Mitarbeitern nicht mehr. Also baut man Hierarchien und Abteilungen auf und versucht der wachsenden Komplexität mit detaillierteren Anweisungen und mehr Dokumentation Herr zu werden. Dass man sich damit oft neue Probleme ins Haus holt, dürfte der eine oder die andere schon am eigenen Leib erfahren haben. Aber wie sieht die Alternative aus?<br />
<br />
Ich habe das Glück, dass ich die Hamburger Firma <a href="http://www.jimdo.com/" target="_blank">Jimdo</a> seit fast 3 Jahren begleiten darf. In dieser Zeit ist Jimdo von ca. 50 auf inzwischen 170 Mitarbeiter gewachsen. Weltweit gibt es über 9 Millionen Webseiten, die mit Jimdo erstellt wurden - in jedem Land auf dieser Erde mindestens eine. Man kann sich vorstellen, dass Skalierung auch bei Jimdo ein großes Thema war und immer noch ist. Aber die Lösungen, die bei Jimdo entstanden sind, sehen oft ganz anders aus, als in anderen Unternehmen. Und Dafür gibt es Gründe.<br />
<br />
Zusammen mit Fridtjof, einem der drei Gründer von Jimdo, habe ich habe ich ein kleines Büchlein verfasst, in dem wir einige wichtige Aspekte der Jimdo-Story aufgeschrieben haben. <a href="http://bit.ly/JimdoStory" target="_blank">Das Büchlein ist jetzt kostenlos als PDF erhältlich. </a><br />
<br />
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
</div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi06hizDdT0Y5tcobD7e_xjSIEeS6b6pz3X-GhE4ePg09pTsXnq5Q3VDAuizhCLVrliRjvppeut5eSbzBlTs2oCo10LDOR2WOBr9skqzQ4c1HbA3gdn0FF7wUE5M0yxIPQc5Mvd3Qtdo2s/s1600/Jimdo_Cover.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="400" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEi06hizDdT0Y5tcobD7e_xjSIEeS6b6pz3X-GhE4ePg09pTsXnq5Q3VDAuizhCLVrliRjvppeut5eSbzBlTs2oCo10LDOR2WOBr9skqzQ4c1HbA3gdn0FF7wUE5M0yxIPQc5Mvd3Qtdo2s/s400/Jimdo_Cover.jpg" width="390" /></a></div>
<br />
<br />
P.S. Fridtjof und ich werden auf der Konferenz <a href="http://www.lkce13.com/" target="_blank">Lean Kanban Central Europe am 04./05.11.2013 in Hamburg</a> einen Vortrag halten, in dem es um dasselbe Thema geht.<br />
<br />Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com0tag:blogger.com,1999:blog-1423003429632694999.post-88729847843365901242013-06-30T18:02:00.002+02:002013-06-30T18:02:27.846+02:00Kanban and Understanding
<!--[if gte mso 9]><xml>
<o:OfficeDocumentSettings>
<o:AllowPNG/>
</o:OfficeDocumentSettings>
</xml><![endif]-->
<!--[if gte mso 9]><xml>
<w:WordDocument>
<w:View>Normal</w:View>
<w:Zoom>0</w:Zoom>
<w:TrackMoves/>
<w:TrackFormatting/>
<w:HyphenationZone>21</w:HyphenationZone>
<w:PunctuationKerning/>
<w:ValidateAgainstSchemas/>
<w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
<w:IgnoreMixedContent>false</w:IgnoreMixedContent>
<w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
<w:DoNotPromoteQF/>
<w:LidThemeOther>DE</w:LidThemeOther>
<w:LidThemeAsian>JA</w:LidThemeAsian>
<w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
<w:Compatibility>
<w:BreakWrappedTables/>
<w:SnapToGridInCell/>
<w:WrapTextWithPunct/>
<w:UseAsianBreakRules/>
<w:DontGrowAutofit/>
<w:SplitPgBreakAndParaMark/>
<w:EnableOpenTypeKerning/>
<w:DontFlipMirrorIndents/>
<w:OverrideTableStyleHps/>
<w:UseFELayout/>
</w:Compatibility>
<m:mathPr>
<m:mathFont m:val="Cambria Math"/>
<m:brkBin m:val="before"/>
<m:brkBinSub m:val="--"/>
<m:smallFrac m:val="off"/>
<m:dispDef/>
<m:lMargin m:val="0"/>
<m:rMargin m:val="0"/>
<m:defJc m:val="centerGroup"/>
<m:wrapIndent m:val="1440"/>
<m:intLim m:val="subSup"/>
<m:naryLim m:val="undOvr"/>
</m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
<w:LatentStyles DefLockedState="false" DefUnhideWhenUsed="true"
DefSemiHidden="true" DefQFormat="false" DefPriority="99"
LatentStyleCount="276">
<w:LsdException Locked="false" Priority="0" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Normal"/>
<w:LsdException Locked="false" Priority="9" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="heading 1"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 2"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 3"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 4"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 5"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 6"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 7"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 8"/>
<w:LsdException Locked="false" Priority="9" QFormat="true" Name="heading 9"/>
<w:LsdException Locked="false" Priority="39" Name="toc 1"/>
<w:LsdException Locked="false" Priority="39" Name="toc 2"/>
<w:LsdException Locked="false" Priority="39" Name="toc 3"/>
<w:LsdException Locked="false" Priority="39" Name="toc 4"/>
<w:LsdException Locked="false" Priority="39" Name="toc 5"/>
<w:LsdException Locked="false" Priority="39" Name="toc 6"/>
<w:LsdException Locked="false" Priority="39" Name="toc 7"/>
<w:LsdException Locked="false" Priority="39" Name="toc 8"/>
<w:LsdException Locked="false" Priority="39" Name="toc 9"/>
<w:LsdException Locked="false" Priority="35" QFormat="true" Name="caption"/>
<w:LsdException Locked="false" Priority="10" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Title"/>
<w:LsdException Locked="false" Priority="1" Name="Default Paragraph Font"/>
<w:LsdException Locked="false" Priority="11" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtitle"/>
<w:LsdException Locked="false" Priority="22" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Strong"/>
<w:LsdException Locked="false" Priority="20" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Emphasis"/>
<w:LsdException Locked="false" Priority="59" SemiHidden="false"
UnhideWhenUsed="false" Name="Table Grid"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Placeholder Text"/>
<w:LsdException Locked="false" Priority="1" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="No Spacing"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 1"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 1"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 1"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 1"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 1"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 1"/>
<w:LsdException Locked="false" UnhideWhenUsed="false" Name="Revision"/>
<w:LsdException Locked="false" Priority="34" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="List Paragraph"/>
<w:LsdException Locked="false" Priority="29" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Quote"/>
<w:LsdException Locked="false" Priority="30" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Quote"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 1"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 1"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 1"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 1"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 1"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 1"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 1"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 1"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 2"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 2"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 2"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 2"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 2"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 2"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 2"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 2"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 2"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 2"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 2"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 2"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 2"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 2"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 3"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 3"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 3"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 3"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 3"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 3"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 3"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 3"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 3"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 3"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 3"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 3"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 3"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 3"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 4"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 4"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 4"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 4"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 4"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 4"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 4"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 4"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 4"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 4"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 4"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 4"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 4"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 4"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 5"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 5"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 5"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 5"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 5"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 5"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 5"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 5"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 5"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 5"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 5"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 5"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 5"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 5"/>
<w:LsdException Locked="false" Priority="60" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Shading Accent 6"/>
<w:LsdException Locked="false" Priority="61" SemiHidden="false"
UnhideWhenUsed="false" Name="Light List Accent 6"/>
<w:LsdException Locked="false" Priority="62" SemiHidden="false"
UnhideWhenUsed="false" Name="Light Grid Accent 6"/>
<w:LsdException Locked="false" Priority="63" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 1 Accent 6"/>
<w:LsdException Locked="false" Priority="64" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Shading 2 Accent 6"/>
<w:LsdException Locked="false" Priority="65" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 1 Accent 6"/>
<w:LsdException Locked="false" Priority="66" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium List 2 Accent 6"/>
<w:LsdException Locked="false" Priority="67" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 1 Accent 6"/>
<w:LsdException Locked="false" Priority="68" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 2 Accent 6"/>
<w:LsdException Locked="false" Priority="69" SemiHidden="false"
UnhideWhenUsed="false" Name="Medium Grid 3 Accent 6"/>
<w:LsdException Locked="false" Priority="70" SemiHidden="false"
UnhideWhenUsed="false" Name="Dark List Accent 6"/>
<w:LsdException Locked="false" Priority="71" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Shading Accent 6"/>
<w:LsdException Locked="false" Priority="72" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful List Accent 6"/>
<w:LsdException Locked="false" Priority="73" SemiHidden="false"
UnhideWhenUsed="false" Name="Colorful Grid Accent 6"/>
<w:LsdException Locked="false" Priority="19" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Emphasis"/>
<w:LsdException Locked="false" Priority="21" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Emphasis"/>
<w:LsdException Locked="false" Priority="31" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Subtle Reference"/>
<w:LsdException Locked="false" Priority="32" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Intense Reference"/>
<w:LsdException Locked="false" Priority="33" SemiHidden="false"
UnhideWhenUsed="false" QFormat="true" Name="Book Title"/>
<w:LsdException Locked="false" Priority="37" Name="Bibliography"/>
<w:LsdException Locked="false" Priority="39" QFormat="true" Name="TOC Heading"/>
</w:LatentStyles>
</xml><![endif]-->
<!--[if gte mso 10]>
<style>
/* Style Definitions */
table.MsoNormalTable
{mso-style-name:"Normale Tabelle";
mso-tstyle-rowband-size:0;
mso-tstyle-colband-size:0;
mso-style-noshow:yes;
mso-style-priority:99;
mso-style-parent:"";
mso-padding-alt:0cm 5.4pt 0cm 5.4pt;
mso-para-margin:0cm;
mso-para-margin-bottom:.0001pt;
mso-pagination:widow-orphan;
font-size:12.0pt;
font-family:Cambria;
mso-ascii-font-family:Cambria;
mso-ascii-theme-font:minor-latin;
mso-hansi-font-family:Cambria;
mso-hansi-theme-font:minor-latin;}
</style>
<![endif]-->
<!--StartFragment-->
<br />
<div class="MsoNormal">
Thanks to <a href="http://positiveincline.com/" target="_blank">Mike Burrows</a> and his work on the values of Kanban
(see <a href="http://positiveincline.com/index.php/2013/01/introducing-kanban-through-its-values/" target="_blank">this excellent Blog Post</a>) I am more and more aware how important <i>understanding</i> is and
how deep it is rooted in Kanban.<o:p></o:p></div>
<div class="MsoNormal">
Let me give you some examples:<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<h3>
Understanding our work</h3>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
Why is it so important that we visualize our work? And why
do we do demand analysis in Kanban? Because we want to understand our work! How
much demand do we have? What are the sources of our demand? Do we have seasonal
variance in demand? What are the risk profiles that are attached to different
types of work (that’s why we might want to introduce different classes of
service)? What skills are required for different types of demand? etc. If we
don’t understand our work, how can we possibly balance demand against capability
to improve flow? We can’t. And we will sooner or later end up with cargo cult
solutions. Of course it’s a long way to understand our work completely, and
maybe we will never manage to. But the more we understand it, the better we can
manage our system. And even a small bit of understanding is probably better
than no understanding at all.<o:p></o:p></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKV5me5BqeXSvBa1e0wiVG6qqQaaJ-6E9lmDovcgDsZdhwuwcA5swJIT_UBDRzTuEZ3shiJ8_APNY3Ii9oujiskO0DzUmF7Z8n63ST_CsQ9WiK-kqtgaBdO8Rx5Igs22rqIubowPE-eig/s945/Papierhaufen_klein.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="326" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEiKV5me5BqeXSvBa1e0wiVG6qqQaaJ-6E9lmDovcgDsZdhwuwcA5swJIT_UBDRzTuEZ3shiJ8_APNY3Ii9oujiskO0DzUmF7Z8n63ST_CsQ9WiK-kqtgaBdO8Rx5Igs22rqIubowPE-eig/s400/Papierhaufen_klein.png" width="400" /></a></div>
<div class="MsoNormal">
<br /></div>
<h3>
Understanding problems</h3>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
My observation is that in most contexts we don’t understand
our problems – and we don’t really try to do so. My main takeaway from many
different contexts in many different organizations: The problem is almost never
what we thought it is at first glance! And for me, that’s one major reason why
models are so important in Kanban (and not only in Kanban). If we use them
wisely, they can guide us in understanding our problems and finding good
countermeasures. Reading <a href="http://www.amazon.com/Managing-Learn-Management-Problems-Agreement/dp/1934109207/ref=sr_1_2?s=books&ie=UTF8&qid=1372607323&sr=1-2" target="_blank">John Shook’s great book on A3 Thinking</a> really
was enlightening for me in this respect. When we discover a problem and start
dealing with it, there is most often a mix up between symptoms of the problem
(„What can we observe that we don’t like?“), deeper roots of this problem
(„What are the reasons for this symptoms?“) and possible countermeasures („What
do we think is a good idea to do in order to make the symptoms go away, as well
as the roots of the problem?“) So it is a good idea to think these things
through, have structured discussions, talk to people who are involved and might
know more than we about the problem, do observations and experiments etc. <o:p></o:p></div>
<div class="MsoNormal">
And then there is another issue with the way we usually
encounter problems: Jumping to conclusions. I thik that agile retrospctives are
very powerful for avoiding this behaviour. Let’s look into the „classical“ schema for
retrospectives as suggested by Diana Larsson and Ester Derby (look into the book <a href="http://www.amazon.com/Agile-Retrospectives-Making-Teams-Great/dp/0977616649/ref=sr_1_sc_1?s=books&ie=UTF8&qid=1372607444&sr=1-1-spell&keywords=agile+retrospctives" target="_blank">Agile Retrospctives</a>):<o:p></o:p></div>
<div class="MsoNormal">
</div>
<ol>
<li>Set the Stage</li>
<li>Gather data</li>
<li>Generate insights</li>
<li>Determine actions</li>
<li>Close the Retrospective </li>
</ol>
<br />
<div class="MsoNormal">
There s a reason why the third step exists: When we have
gathered our data and identified a problem, we should not directly determine
actions, but generate insights first. And this generation of insights means to
understand our problem better (no matter what practices we use to do this). This
step ist often the hardest one in a retrospective, and teams as well as facilitators
tend to skip it. But it is very valuable! (example Henning)<o:p></o:p></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMzf8Eiy3afEUvYZXcRGFuxyTewDQKkTpzijRvJVaH_XZcOo9DKMj28aqMw6N-kg7qmh6xUJNwbYHLw9IptKlelhFSGR10aHs5IOr4_uNYppQESX-KVzgDOlptcNZ3UfIl2AH9g4-TgLE/s1600/Justin19.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="298" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEgMzf8Eiy3afEUvYZXcRGFuxyTewDQKkTpzijRvJVaH_XZcOo9DKMj28aqMw6N-kg7qmh6xUJNwbYHLw9IptKlelhFSGR10aHs5IOr4_uNYppQESX-KVzgDOlptcNZ3UfIl2AH9g4-TgLE/s400/Justin19.png" width="400" /></a></div>
<div class="MsoNormal">
<br /></div>
<h3>
Understanding people</h3>
<div class="MsoNormal">
<o:p></o:p></div>
<div class="MsoNormal">
Of course we will never understand a person completely. What
I mean here is the following: If we observe a behaviour that seems to be stupid
to us, what do we do? Do we ignore this? Do we tell the person "Stop it!" ? Or do we assume that there is a good reason behind his behaviour and
try to understand this reason? Everyone who ever played <a href="http://www.getkanban.com/" target="_blank">GetKanban</a> knows the
devastating effects that are caused by Carlos the test manager and his policies.
Any team playing GetKanban hates Carlos, yells at him and desperately waits for Alison to fire him. But if
we step back for a while and ask ourselved why he set up the policies, we can
find very good reasons for this. If we did this, it could be easier to deal with him. Here is another example, this time from real life: I trained a team, including a project
manager in Kanban. Of course we talked about the advantages of WIP limits and having a pull
system in place. They all agreed that they wanted to introduce this. But after a couple
of weeks it became clear that the project manager kept pushing work into the
system without regard to the WIP limits. My first reaction was „What a moron!“
Luckily, I did not day that loudly. After having talked to him, the picture looked
differently. It turned out that he was totally aware of the problems his behaviour was
causing. But he had a reason for this: „Look, I am responsible for the
on-time delivery and quality of our small projects. I totally get this
pull-stuff. But I know that our team members have very different skills and
experience. So I don’t have faith in a system where an inexperienced person
pulls an item he cannot master. This puts the commitments towards our clients
at risk. So I bypass the pull-system by assigning tickets to specific persons
and putting them on their desks.“ Now we had a better perspective on the
problem. It was not the „stupid project manager“ but maybe a problem of too
little training for new people. Or maybe it was only a problem of showing the
project manager that the skill level was much higher than he thought. In both
cases the way we had to approach the problem was different from getting rid of
the project manager.<o:p></o:p></div>
<div class="MsoNormal">
So the bottom line here is: Let’s not jump to conclusions
when it comes to strange behaviour either! When we observe bad behaviour, let’s ask questions like: „Assuming
this person is a good guy, what might the reasons for his behaviour be?“, „What
does this person see that I cannot see?“, „What are his fears?“ etc. This helps
us improving by showing respect for people.<o:p></o:p></div>
<div class="MsoNormal">
<br /></div>
<div class="separator" style="clear: both; text-align: center;">
<a href="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg33JkER890rwo1YtHEHSJYxa-ZbJPJhlcuRDOKWCUWMattAdJkSF2zp8iubh2pFbHxYHNWPdnh0FxVKLU8kXjccjcdT0X-bMvOY8HV_-qMWv3goOZD1BJguFbbqSEybycB0K5dyDSNVAA/s1034/FrageTeam.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="312" src="https://blogger.googleusercontent.com/img/b/R29vZ2xl/AVvXsEg33JkER890rwo1YtHEHSJYxa-ZbJPJhlcuRDOKWCUWMattAdJkSF2zp8iubh2pFbHxYHNWPdnh0FxVKLU8kXjccjcdT0X-bMvOY8HV_-qMWv3goOZD1BJguFbbqSEybycB0K5dyDSNVAA/s400/FrageTeam.jpg" width="400" /></a></div>
<div class="MsoNormal">
<br /></div>
<div class="MsoNormal">
<br /></div>
<!--EndFragment-->Arnehttp://www.blogger.com/profile/15740341452041610643noreply@blogger.com2