Monday, December 16, 2013

Reviewing Lean Kanban Central Europe 2013

Exactly six weeks ago the Conference Lean Kanban Central Europe 2013 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:-)
My involvement was threefold: As organizer, board member and speaker. Here are my thoughts from these three different perspectives.

The organizer‘s perspective

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

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!
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:-)
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. Jasna Wittmann is the artist who did the great calligraphy!

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 Miniatur Wunderland, 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.

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!

The board member‘s perspective

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!

The board members get a bottle of the Whisky "Work in Progress", which needs to be limited:-)
We choose to have a mixture between invited sessions and sessions choosen from our open review process. The program 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...
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 The Art of Action. His keynote from lkce13 is not publicly available on video, but if you are interested in leadership and management, you should read this free article.

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 watch his keynote here.

Almost all presentations, including Pecha Kuchas, Lightning Talks and experience reports from companies like Ericsson, Siemens, Spotify, SAP, Jimdo have been videotaped and are available here.

The speaker‘s perspective

I had a full blown presentation about Kanban, Leadership and Alignment with Jimdo together with my dear fellow Fridtjof Detzner which went quite well.
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:

Next year

As I will leave it-agile and start working with Jimdo 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
I will stay involved in the conference as a member of the board and by sharing ideas and experiences with the it-agile guys.
I am absolutely sure that the best LKCE conference is always the next one, so stay tuned!

P.S. We‘ve invented the KanBanana at the conference:-)

Tuesday, November 12, 2013

Open Prioritization Meeting

When I first visited Jimdo 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.

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.

Queues lead to overburdening (stress, poor quality, frustration)

Jimdo’s experience with the team wall was one major reason for introducing a concept which they call Open Prioritization Meetings. 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.

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?

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!
And, by the way, the Open-Prioritization-Meeting usually only takes 30-45 minutes.

Although this format is quite new, we’re already seeing a couple of positive effects:
  • 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.
  • 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.
  • During the meetings, the stakeholders communicate directly, as opposed to the ticket system before. This prevents misunderstandings and builds trust.
  • The different teams have valuable discussions about what their most important request is, because they know that only 1-2 items will be accepted.
  • 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.
  • 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?”

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.

This story is part of a free ebook about Jimdo which is called "Doing things differently. Leadership, Management and Alignment with Jimdo." You can download it here.

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, Yason Yip for pointing us to this! And as an answer to Ron‘s question in the last paragraph: "No, it‘s not madness!"
Read Ron Jeffries Post

Thursday, October 24, 2013

Supporters to the teams!

Yesterday I wrote about customer support and how it is separated from the rest of the organization in many cases. (Read Blog Post).

At Jimdo, 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.

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

P.S. When it comes to support, there is another interesting thing going on at Jimdo, which is called Support Alarm Party. But that is worth a future blog post...

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 Lean Kanban Central Europe 2013 in Hamburg, Nov 4-5. Also we have written a small online booklet called „Management, Alignment and Leadership at Jimdo“. You can find the German version here. And this is the English version

Wednesday, October 23, 2013

Support – 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 team 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.

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

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.

Stay tuned: Tomorrow I will publish a second post on this topic with an example of how companies can do it differently.

-> Read the follow-up: Supporters to the teams!

Sunday, September 8, 2013

Let‘s stop talking about waste

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

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

1) It can be insulting
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“.
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.

2) It misses the point
The original concept of waste talks about wasteful activities. But as Don Reinertsen points out in the keynote from last year‘s Lean Kanban Central Europe conference, 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 less than before..

3) It is often simplistic or almost useless
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.
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.

4) It is binary thinking
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.

5) Innovation needs waste
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.

Thinking about Costs
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, buy this book 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 watch this presentation 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.

Tuesday, August 13, 2013

cross-funktionale Teams

-> Want to read the English article? Click here

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 Stefan unterhalten. Dabei ist ein Artikel herausgekommen, den wir in der Zeitschrift agile review veröffentlicht haben. Jetzt haben wir uns entscheiden, den Artikel auch online zur Verfügung zu stellen.
Diese Themen werden im Artikel behandelt:
  • Wann kann man von einem cross-funktionalen Team sprechen?
  • Wie verhält sich Cross-Funktionalität zu Innovation, Geschwindigkeit und Effizienz?
  • Die Kosten-Seite
  • Wie können Teams cross-funktionaler werden?
  • Was haben das A-team und Ocean‘s Eleven mit dem Ganzen zu tun?
Hier gibt es den Artikel als PDF

Tuesday, July 9, 2013

Wir können auch anders! So tickt Jimdo

In 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?

Ich habe das Glück, dass ich die Hamburger Firma Jimdo 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.

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. Das Büchlein ist jetzt kostenlos als PDF erhältlich. 

P.S. Fridtjof und ich werden auf der Konferenz Lean Kanban Central Europe am 04./05.11.2013 in Hamburg einen Vortrag halten, in dem es um dasselbe Thema geht.

Sunday, June 30, 2013

Kanban and Understanding

Thanks to Mike Burrows and his work on the values of Kanban (see this excellent Blog Post) I am more and more aware how important understanding is and how deep it is rooted in Kanban.
Let me give you some examples:

Understanding our work

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.

Understanding problems

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 John Shook’s great book on A3 Thinking 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.
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 Agile Retrospctives):
  1. Set the Stage
  2. Gather data
  3. Generate insights
  4. Determine actions
  5. Close the Retrospective 

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)

Understanding people

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

Wednesday, June 19, 2013

LKNA13 in Chicago

The Conference Lean Kanban North America (formerly known as Lean Software and Systems) is the mother of all Lean/Kanban Conferences. After a truly awesome event in Boston last year, it took place in Chicago, the Windy City, this year from April 28 – May 2. The tagline for this year was "Managing Flow, Complexity & Risk",
We (that is Naddel and Fridel from Jimdo and me) arrived on Saturday - after a great week in San Francisco where we visited the Jimdo US office as well as the two startups 99designs and foursquare. We took a walk around downtown and went to the great lake where a funny techno charity run took place.


Sunday started with two meetings of the Lean-Kanban University - the organization which is dealing with professional designations for Kanban trainers and coaches. This time we talked a lot about the market needs for Kanban trainings in different countries and continents as well as the freshly inaugurated coaching program (Kanban Coaching Professional, KCP). During the second meeting, Mike Burrows said something that made me think: "We don‘t want to teach teams tricks! We want to help them improve their learning capability."
The meetings were quite shorts, so I had time to meet Naddel, Fridel and Katrin and have a sandwich at Hannah‘s Bretzel - the über sandwich makers!

At the welcome reception on Sunday evening we met a lot of old friends and had a couple of beers - what a great start for a conference!


Monday I was track chairing the Kanban at Scale track. We had two speakers dropping out, but (once again) it was really easy to find very good replacements with Bill Foy and Dan Vacanti. Bill started the track with his talk "What is your best performance strategy?" He presented some of the results of the interviews he did with managers from different organizations. The one that resonated with me the most was "Managers have to switch from the big picture to details, back and forth. This leads to clearity, because we see something from one perspective and still have the other perspective in mind". After this, Joakim and Anders presented the scaling mechanism at Spotify. You can find the basics in this PDF document, but the presentation contains much more. So if you ever have the chance to meet them, don‘t miss it!

Dan Vacanti presented an case study from Siemens Healthcare. They reached impressive outcomes by understanding their system, measuring the flow and limiting WIP.

Another case study was presented by Ramon Tramontini and Marcelo Walter from Peru: "The Spice must Flow" They described some emerging practices that helped them and their team to manage their flow, gain more effectiveness and sustainable pace.

The last talk of the day was "Kanban, Leadership and Alignment at Jimdo" by Fridel and me. We presented the way Jimdo is working. Especially the importance of the company culture and different formats for structured communication. We will publish this material in more depth soon. Meanwhile you can have a look at our slides.
We received a lot of positive feedback, so it was time for a little bit of posing;-)

My main takeaway from the Kanban at Scale track: We shouldn‘t try to scale Kanban. First we need to understand the organization we are dealing with, its history and the problem it is facing. If we come to the conclusion that Kanban helps us deal with these problems, we have to develop our own Kanban implementation. There is no one right way to do this!

In the evening I gave an interview with infoQ about implementing and Scaling Kanban. You can find it here.

Later in the evening, Jim Benson facilitated an OpenSpace. I was sitting at the table with the topic "Military Doctrine". There were so many very smart people at this table, that I learned a whole lot in 90 minutes - and also wrote down four pages of notes and drank a couple of beers - all at the same time! Whoever wants to learn more about Auftragstaktik (which is really enlightening, even for pacifists like me), should read these two books: The Art of Action and Certain to win.


The day started with Stephen Parry‘s keynote. I had heard a lot of his stuff (i.e. climate model) before, but it was still interesting to hear it again.

After lunch the Brickell Key Award ceremony took place. I was lucky enough to hand over the Trophy to Troy Magennis for his amazing work with using Monte Carlo Simulations for forecasting with Kanban. This stuff will change the way projects are run in the future. So watch out for Troy! The second trophy was given to Yuval Yeret, Kanban Pioneer in Israel and a real practitioner and out-of-the-box thinker. Congratulations to both winners, well deserved!

After a sneak preview for Mary and Tom Poppendieck‘s new book in their talk, I was lucky to hear Simon Bennett speaking. His talk Rules, Reactance and Gaming was really entertaining and useful! I will not even try to summarize his great story about speed-detector-detector-detectors. One big main takeaway for me was: If we want people to follow rules, we must make clear that they understand (and agree with) the intent behind the rules. And it‘s more likely that they follow the rules when they were involved in the creation process.

In the evening it was Deep Dish Pizza time (a must-eat for every tourist in Chicago). Gaetano who knows a lot about Pizza said: "It tastes good, but it has nothing to do with Pizza!" We had a great evening with the awesome guys from The Library Corporation! Thanks for the conversations and the invitation.


Douglas Hubbard‘s keynote "How to measure anything" was mind-blowing! One thing I learned: "We have more data than we think. And we need less data than we think!" And: We can measure whatever we want - as long as we know what we are talking about and why we want to measure it. I strongly recommend reading his book!

After this, Jim Benson delivered, once again, a very insightful (and quite weird) presentation about "Orwellian Management". I loved it, but I cannot summarize it.

Wrap Up

The conference was absolutely worthwile! I learned a lot, met a lot of interesting people and had a lot of fun! Special thanks to Naddel and Fridel!
LKNA14 will take place in San Francisco - I will be there!

And by the way, Chicago can be quite beautiful, especially at night:-)

Lean Kanban Central Europe

For all the Europeans who missed the Chicago event: Lean Kanban Central Europe 2013 takes place in Hamburg, Nov 4-5. A lot of great speakers already agreed to come. Check out the website!

P.S. If you understand German, you should also read Naddel‘s blog posts about the chicago conference!
P.P.S. If you are waiting for the videos from the conference: This year they are only available for attendees, sorry.

Friday, March 15, 2013

Coffee, Beer and Taxi Rides. Or: Visiting Stockholm with Jimdo

I had the pleasure to give a presentation at the first StopStarting, Start Finishing Conference in Stockholm last Monday. I thought this might be a great opportunity to visit some interesting companies. So I planned an extended stay and asked Fridel from Jimdo if he wanted to join me. He well as Naddel (the Flow Manager)...and Matze (the second founder)...and Sönke (employee number 5 at Jimdo)...and Spring (the third  founder). 
So it hapened that the six of us entered the train in Hamburg Altona on Sunday morning 08:46. Only 13.5 hours later we arrived in Stockholm (I skip some interesting things about the train ride here). 

A train ride to Stockholm is not a petting zoo!

After a short taxi ride we arrived at our accomodation af Chapman – an old sailing ship which serves as a hostel now. This was a really good decision! If you ever have the opportunity to do so, book a couple of nights there!

The af Chapman

Blue sky and sunny weather as we entered a taxi the next morning. First thing on our agenda: visit Ericsson in Kista. Our expectations hadn’t been too high. It’s a really huge enterprise, the sort of big oil tanker that needs ages to change direction, so what should we expect? But wow! It’s really impressive how far Erik’s team already has come – with the help of Håkan, their Flow Senssei, of course (he prefers to be referred to as a „plumber“:-) What we could observe was: cross-functional and co-located teams, high visibility of work, flow and problems as well as a leadership team that has accepted the challenge to change their way of working and act more and more as teachers and mentors. After a Gemba Walk we discussed end-to-end-flow at Ericsson and Jimdo. Of course the companies are different as can be. But some things are surprisingly similar: What exactly is the role of Managers in a truly Lean organization? Where are the boundaries of self-organization? And what can we do to keep alignment (in a growing company like Jimdo) or to re-create alignment (in a huge enterprise like Ericsson). And, once again, it became clear to me that the company culture plays a crital role in all change processes (imagine the impact of a value like "perseverance" if it it rooted deeply in your company DNA).

Checking Wifi at Ericsson

Some taxi rides later (from that morning on we had our own taxi driver) we arrived at the Spotify headquarter where we could talk to a couple of Lean/Agile coaches as well as a systems engineering guy. The first thing that you experience at Spotify is – of course – loud music. The second thing are some of the coolest offices I have ever seen! Spotify’s organizational structure is really interesting and described in this paper. We digged into some details. Spotify seems to have managed to cope with an extremely fast growth: If I remember it correctly, the grew from 30 to 300 engineers in less than 3 years with a total of roughly 800 employees (nobody seems to know the exact number, because it changes every day). How do you „manage“ a company of this size without implementing a classical hierarchical matrix structure? Spotify has some interesting answers to this question. From this discussion emerged an idea that could help with one big challenge that Jimdo is facing: Until now they have 3 founders, 140 employees and 6 dogs, that’s it, (almost) no formal leadership. As Jimdo is growing, this is not a sustainable structure, because the workload is way too high for the founders. Jimdo wants to scale leadership without setting classical managers or team leads in place. We’ve discussed this topic quite often during the past couple of months and the visit at Spotify might have brought the answer or at least a starting point for trying things. Other topics that day were self-selected teams with interesting boundary conditions (have at least one sceptic in every team), finding more female engineers and a lot of technical stuff I didn’t understand a word of. 
We were lucky that Spotify organized a community event later that evening. It was called „Scaling Agile“ and consisted of 5 Lightning Talks, good food and a lot of beer. This was a really nice occasion for reflecting our learnings.

Make sure you never run out of beer!

After another taxi ride and emptying some „Hülsenfrüchte“ as well as our bottle of Whisky we had a good but short sleep. The Jimdo guys flew out that morning and I had to prepare my talk about Alignment.
After the great conference (which is worth another blog post) I walked through the old town to my last visit: Crisp. Mattias Skarin showed me the office and told me about Crisp’s way of collaboration, culture and their business model. And he invited me to a great dinner! Crisp is a fascinating company and in many respects they are comparable to what we do at it-agile: Similar size, similar business, similar problems challenges, similar intent to be a "democratic" company and similar experiences with clients. The conversation with Mattias was insighful for me, because he has some great ideas about coaching, which made me think. I really think Crisp is doing a great job and if I lived in Stockholm, I would invite Mattias to dinner every evening to become a Crispare:-) And great news: Mattias is very close to join Twitter. He already opened the registration page but was distracted for some reason!

Crazy Matze

These are my main takeways from our visit in Stockholm:
  • Visiting companies is a great way of learning – even if the company seems to be very different from your own.
  • There are many ways to build cool companies beyond the classical structures. Unfortunately this comes with a price and takes a lot of effort and failures learning experiences. Lucky enough, there are so many smart people around the world we can learn from. We all should do this more often!
  • The Kanban community is absolutely amazing! All three visits were really easy to organize, because the locals very extraordinary helpful. And they all were very open to share their learnings. Tack så mycket Håkan, Erik, Joakim, Anders, Mattias and all the other people we talked to!!!
  • I have never drunken so much coffee and never had so many taxi rides (thanks, Fridel, for breaking your leg!) And I think we owe Spotify some beers...

P.S. Our next destination is San Francisco. Fridel, Naddel and I will be there in April. And I heard there might be a couple of interesting companies as well...

Yes wie Kanban Yes wie Kanban