Seriously, what is a Pull System?

Almost 5 years ago, I‘ve published a blog post called What the F*** is Pull? The distinction between Pull System and Pull Behavior, that we‘d come up with earlier at the Kanban Leadership Retreat 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.

Definition of Push vs. Pull

In a Push System, new input is determined by a plan or event. Output has to be adjusted accordingly.

In a Pull System, new input is determined by the system‘s capacity/capability. Input has to be adjusted to the output.

Pull Systems and WIP Limits

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 Understanding as one of Kanban‘s core values); 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 Stop Starting, Start Finishing! 

Pure Pull Systems?

It‘s worth mentioning that pure Pull Systems probably do not exist. As Don Reinertsen points out in his brilliant presentation The Science of WIP Constraints, 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.
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...

_______________________

Like this post? Then you should check out my previous post Keep the Ball Rollin‘

Lean Kanban Central Europe 2014

Only 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 this blog post, 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.

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.

I will kick the track off with my talk The Beauty of Problems 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.
After the Pecha Kuchas (Keynote style as last year), Martin Jensen will argue that Culture is THE Competetive Advantage 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.




Joshua Arnold will continue with his talk Value and Urgency: The Power of Quantifying the Cost of Delay 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 experience report from Maersk Line.
After his fabulous keynote from last year, Troy Magennis agreed to speak again at this year‘s edition. His topic is Risk Management and Forecasting Using Un-reliable Data 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.
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 Failure Culture at Wooga, and my brother Stefan will share his experiences with participatory decision making models.

Pawel, Klaus, and Markus grabbing their well-deserved Whisky ;-)

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!

See all of you in Hamburg. If you haven‘t done yet, register today: www.lkce14.com/register


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.

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.

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

Das war Lean Kanban Central Europe 2012

Vom 22.-23.11.2012 fand wieder die Konferenz Lean Kanban Central Europe statt - diesmal in Wien, und gemeinsam organisiert von LEANability und it-agile

Knapp 200 Teilnehmer aus 15 Ländern und 5 Kontinenten informierten sich unter dem Motto "Stop starting, start finishing!" zwei Tage lang über die verschiedensten Themen rund um Lean und Kanban. An Speakern waren neben den "üblichen Verdächtigen" wie David Anderson oder Jim Benson auch neue Gesichter gekommen, z.B. Steve Medland, der Toyota Kata als Ansatz zur kontinuierlichen Verbesserung in der Fertigung vorstellte.
Was mich persönlich an der Lean-Kanban-Community fasziniert, ist ihre Offenheit gegenüber neuen und auch durchaus kontroversen Ansätzen. Auf der LESS 2011 in Finnland hielt Jurgen Appelo einen Vortrag, in dem er dem Einen oder Anderen Anwesenden kräftig auf den Schlips trat - und er wurde hinterher für den besten Vortrag der Konferenz ausgezeichnet. Auf der LKCE 2011 in München erklärte John Seddon in seiner Keynote den staunenden Zuhörern, dass Lean so ziemlich das Dämlichste sei, was in den letzten 50 Jahren entstanden ist. Dieses Jahr übernahmen Dave Snowden und Don Reinertsen die Rolle der "Aufrührer".

Dave Snowden meinte, dass Komplexität nach wie vor weit gehend unverstanden ist und die allermeisten Leute in unserer Domäne in diesem Bereich allenfalls dillettieren würden. Und Don Reinertsen erklärte in seiner Keynote in der ihm eigenen ruhigen und messerscharfen Art, dass wir in der Kanban-Community die Implikationen von WIP-Limits und Pull keineswegs vollständig durchdrungen haben, sondern nach wie vor zu häufig an Mythen festhalten. Reinertsens Keynote und der Talk von David Joyce sind übrigens zwei meiner drei Highlights dieses Jahres.

Das dritte Highlight waren aus meiner Sicht (wieder einmal) die Pecha Kuchas - Kurzvorträge, in denen jedem Speaker genau 6 Minuten und 40 Sekunden zur Verfügung stehen, um sein Thema mit Laserfokus zu präsentieren. Und weil das noch nicht schwierig genug ist, wechseln die Folien alle 20 Sekunden automatisch.
Meine Kollegin Meike Mertsch präsentierte Personal Kanban und erfand dabei gleich ein neues Format. Denn in ihrem Vortrag wechselten nicht die Folien automatisch nach 20 Sekunden (sie hatte nämlich keine Folien), sondern es wurden (wunderbar selbst gezeichnete) Flipcharts umgebättert - Low-Tech-Pecha-Kucha also:-)
Danach war der Routinier Markus Andrezak an der Reihe, der in seinen "Irrational Rules" mehr als eine "Gewissheit" in Frage stellte, die sich in der Agilen Community festgesetzt haben - von der idealen Teamgröße bis zur Bewertung von Taylor.
Auch ich durfte wieder einen Pecha Kucha halten und habe einen kleinen Ausflug in die Welt der Schafe unternommen, um mehr über die "Art of Leadersheep" zu präsentieren.
Am Schluss kam der "Don of Lean", Don Reinertsen, mit seinem allerersten Pecha Kucha seines Lebens, zu dem Markus ihn mit sanftem Druck überredet hatte:-) Und zum ersten mal in meinem Leben  hatte ich den Eindruck, einen Hauch von Aufregung bei Don wahrzunehmen. Er sagte dann auch vorher "This is the first and the last time I will do a Pecha Kucha. This format is brutal!"Aber wie sollte es anderes sein? Genau so wie Kent Beck letztes Jahr lieferte er einen erstklassigen Pecha Kucha ab, der nicht nur durch seinen Inhalt überzeugte ("Making Money by buying information"), sondern auch zeitlich perfekt getaktet war. Hier gibt es die Videos aller vier Pecha Kuchas. Und die Leadersheep habe ich direkt hier eingebettet:


LKCE12: Arne Roock - The Art of Leadersheep from Lean Kanban Central Europe on Vimeo.

Neben den Talks selbst gab es noch so allerlei Anderes zu erleben: Der Buchstand mit der größten Auswahl an Lean- und Kanban-Büchern in Europa, einen Cowboy-Hut, Post-It-Kunst, einen Zeichner, der live die wichtigsten Punkte jedes Vortrags festhielt, so dass während der Konferenz eine große Collage entstand, eine große Party mit einem wirklich unglaublichen Zauberer, leckeres Wiener Essen und natürlich viele Gelegenheiten zum Austausch. Als einer der Organisatoren war ich natürlich bis zum Ende ziemlich angespannt, aber als Jim Benson und Tonianne DeMaria Barry hinterher sagten, das sei die beste Konferenz gewesen, an der sie jemals teilgenommen hatten und Don Reinertsen 10 von 10 möglichen Punkten auf dem Feedback-Bogen vergab, war ich dann endlich beruhigt:-) 

Hier noch die wichtigsten Links zur Konferenz Lean Kanban Central Europe 2012:

• Übersicht über die Sessions inkl. Slides und Videos
• Eine Auswahl an tollen Photos von Adrian Buturca und Jabe Bloom, inkl. der Visual Recordings
• Formular, auf dem man schon mal Interesse für nächstes Jahr bekunden kann (2013 wird die Konferenz in Deutschland stattfinden).
• Wer nicht mehr so lange warten möchte: Im Mai findet in Chicago die Konferenz Lean Kanban North America statt - wenn es nur halb so gut wird wie dieses Jahr in Boston, dann lohnt sich der Flug auf jeden Fall!
• Weitere Berichte zur Konferenz gibt es von Markus Andrezak (auf Heise Online), Klaus Leopold, Mike Burrows, Pawel Brodzinski und Peter Hundermark

Lean Kanban Central Europe 2012 - Call for Paper

After last year‘s success, the second edition of the international conference Lean Kanban Central Europe 2012 will take place in Vienna, October 22-23. The event is co-organized be LEANability, it-agile und the Lean Kanban University

The Call for Paper is out and I‘d like to encourage everyone to submit his/her story about Kanban or Lean before June 30th. Note: Submitting early increases the chance to be accepted. This is because we have an open review process which provides you with quick feedback so that you can improve your submission before the end of the deadline!

In addition, we‘d like as many people as possible to review the submissions and by doing so help us improve the quality of the conference!

-> Find more information about the submission and review process

P.S. Follow @leankanbance and #lkce12 on Twitter to keep track!

The Lean Kanban conference season starts...NOW!

The Lean Kanban conference season starts...NOW!

Do you want to learn more about Lean and Kanban? Did you hear people talking about Lean Kanban events you couldn’t attend? Do you like travelling? Do you want to meet all the experts you know from Twitter, Blogs, articles etc.?

Then I’ve good news for you: There are plenty of opportunities ahead this year!

For the first time ever, the conference Lean Kanban Southern Europe takes place, Madrid, May 09-10 The speaker line-up looks really awesome, and what a great opportunity to visit Madrid!

Only one week later, it’s party time in Boston (The Boston Lean Party)! This is the mother of all Lean and Kanban conferences – 6 days packed with the best speakers from all over the world! Lean Software & Systems Conference

In Autumn, the Kanban train goes through Switzerland, Scotland, Netherlands, Austria and France!

Lean, Agile & Scrum takes place in Zürich, Sep 12th. It’s a one-day event that will cover a couple of Kanban sessions as well as other Agile stuff.

Lean Agile Scotland takes place in Edinburg, Sep 21-22 - and they already announced a great set of speakers!

In October, there will be three events in a row – starting with

Lean Kanban France – for the first time ever. The date will most probably be Oct 18-19

Only one weekend to rest, since the second edition of Lean Kanban Central Europe takes place in Vienna, Oct 22-23 Because I‘m one of the organizers, I know that there are a couple of exciting news to announce soon!

Our friends from the Netherlands organize Lean Kanban Netherlands. This event will take place in Amsterdam, Oct 25-26

And Maarten, who organized Lean Kanban Benelux the past two years, is working on a whole new conference, called RE:THINK2012, that will take place in Brussels, Dec 14

So ask your boss, book your flights and pack your things...NOW!

Wichtige Termine in 2011

Schon Anfang des Jahres hat David Anderson getwittert "The Kanban Train is accelerating".  Wenn man sich ansieht, welche Events allein dieses Jahr noch anstehen, dann scheint er Recht zu behalten.

Ich habe hier mal zusammengestellt, welche hochkarätigen Ereignisse allein 2011 noch stattfinden:

• Lean Software & systems Conference, 03.-06.05. in Long Beach (Kalifornien): DIE Lean/Kanban-Konferenz überhaupt! Wer es irgendwie einrichten kann, sollte da unbedingt hin (ich kann es leider nicht einrichten). Konferenz bei Twitter folgen
• Kanban-Track auf der GOTO, 13.05. in Kopenhagen: David Anderson hostet einen eigenen Track zu Kanban. Markus Andrezak, Bernd Schiffer und ich werden eine Einführungs-Session als kleines Schauspiel halten. Konferenz bei Twitter folgen
• Lean Kanban Benelux, 03.-04.10.2011 in Antwerpen: Diese Konferenz ist - zusammen mit den beiden folgenden - die offizielle europäische Lean/Kanban-Konferenz des LSSC. Die Seite befindet sich im Aufbau, im Moment läuft der Call for Papers. Ich war letztes Jahr dort und kann nur sagen: Das war (zusammen mit den letzten beiden XP Days Germany) die beste Konferenz, auf der ich jemals war! Konferenz bei Twitter folgen
• Lean Kanban Central Europe, 17.-18.10.2011 in München: Bernd Schiffer und ich organisieren dieses Event, und man kann jetzt schon sagen, dass es sich lohnen wird! Also haltet euch diesen Termin frei! Der Call for Paper folgt in den nächsten Tagen. Konferenz bei Twitter folgen
• LESS Conference, 31.10.-01.11.2011 in Stockholm: Diese Konferenz hat - im Gegensatz zu Benelux und Central Europe einen akademischen Einschlag.
• XP Days Germany, 17.-19.11. in Karlsruhe: Diese Konferenz ist Legion! Bei keiner anderen Konferenz habe ich so viele innovative Session-Formate gesehen, und nirgendwo habe ich die Atmosphäre als so angenehm erlebt wie hier! Das Programm steht noch nicht fest, aber ich bin mir sicher, es wird auch dieses Jahr wieder etliche Sessions zu Lean und Kanban geben! Konferenz bei Twitter folgen
• Lean Agile Scrum Konferenz, 14.09. in Zürch. Eine eintägige Konferenz, die von der Fachgruppe Lean, Agile und Scrum der SwissICT organisiert wird. Auch hier läuft im Moment der Call for Paper.

Wir sehen uns im Kanban-ICE - egal in welchem Abteil:-)

Lean bedeutet einen Perspektivenwechsel

Anfang November besuchte ich in Hamburg einen Vortrag von Kent Beck (der "Erfinder" von eXtreme Programming und testgetriebener Entwicklung). Das Thema lautete: Software G Forces and the Effects of Acceleration. Neben vielen anderen interessanten Punkten hat dabei vor allem ein Aspekt ein Aha-Erlebnis bei mir ausgelöst: Agiel/Lean (die für mich zwei Seiten derselben Medaille darstellen) bedeutet häufig, traditionelle Sichtweisen aufzugeben und eine zuerst ungewohnte, neue Perspektive einzunehmen.
Becks Vortrag handelte davon, was geschieht, wenn ein Team/eine Organisation dazu übergeht, ihren Release-Zyklus immer weiter zu verkürzen: von jährlich auf quartalsweise auf monatlich auf wöchentlich auf täglich auf stündlich (ja, so etwas funktioniert tatsächlich, wie beispielsweise flickr eindrucksvoll beweist). Für jeden dieser Rhythmen hat Beck auf einer Folie dargestellt, was jeweils dafür nötig ist, um auf diese Stufe zu gelangen und welche Dinge man sich auf der anderen seite nicht mehr erlauben kann. 

Was ist nötig für monatliche Releases (links), und was kann man sich nicht mehr erlauben (rechts)?

Beispielsweise ist es ab einem monatlichen Rhythmus nicht mehr möglich, eine eigene Q/A-Abteilung zu haben, weil die Arbeitsübergaben und die Kommunikationsaufwände dann zu hoch wären, um so ein schnelles Tempo zu erlauben. (Intessanterweise kann man ab einem bestimmten Tempo auch keinen Bugtracker mehr haben. Stattdessen muss man es hinbekommen, dass nur noch extrem wenige Bugs entstehen, und diese wenigen Bugs müssen sofort gefixt werden - oder man muss sie ignorieren und bis in alle Ewigkeit mit ihnen leben.) 

Auf der Seite der Dinge, die nötig sind, um schneller zu werden, waren alte Bekannte zu lesen wie automatisierte Akzeptanztests, Continuous Integration und Refactorings (und zwar schon bei quartalsweisen Releases). 

Das hat mich zuerst erstaunt, aber dann ist der Groschen gefallen: Bei all diesen Praktiken geht es gar nicht in erster Linie darum, sie einzusetzen, um ein bestimmtes Ziel zu erreichen. Ich hatte vorher immer viel zu sehr von den Praktiken her gedacht. 

"Warum macht Ihr TDD?" - "Weil sich dadurch ein schlankeres Design ergibt." 

"Warum arbeitet Ihr im Pair?" - "Weil wir dann weniger Fehler machen." 

Das sind natürlich nach wie vor sehr gute Gründe. Wenn man aber die Reihenfolge umdreht, wird aus der möglichen Argumentation eine zwingende. Und sie ist besonders zwingend, wenn es um kurze Durchlaufzeiten und häufige Releases geht (was ja tatsächlich für viele Organisationen die größten Herausforderungen darstellt). Die Unterhaltung könnte dann ungefähr so aussehen: 

"Wir möchten gern wöchentlich Releasen. Geht das?" "Ja, aber nur, wenn wir Pair Programming einsetzen und TDD praktizieren." "Dann sollten wir sofort damit anfangen." "Gern, aber vorher brauchen wir etwas Zeit und Geld für Weiterbildung, andere Schreibtische und und größere Monitore." 

Pair Programming und Co. sind also keine Hindernisse für hohes Tempo, sondern eine Voraussetzung!

Dasselbe gilt übrigens für den Zusammenhang zwischen Geschwindigkeit und Qualität (ein Umstand, auf den die Poppendiecks immer wieder hinweisen): Die Alternative lautet nicht Geschwindigkeit oder Qualität. Sondern sie lautet: Schnell werden durch hohe Qualität oder langsam bleiben, weil die schlechte Qualität kein höheres Tempo zulässt. Wie im TDD-Beispiel ist es natürlich auch hier einfacher gesagt als getan, denn die Qualität zu erhöhen, ist ja alles andere als trivial. Aber wenn man schneller werden will (oder muss) führt kein Weg daran vorbei. XP-Praktiken sind nichts, was man macht, weil es irgendwie cool wäre, sondern sie stellen Bedingungen dar, an denen man nicht vorbeikommt, wenn man bestimmte Ziele erreichen möchte.

Zum Weiterlesen

• Markus Gärtner hat mit seiner unvergleichbaren Live-Blogging-Technik den Vortrag von Kent Beck sehr schön zusammengefasst. Zur Zusammenfassung
  
• Mary und Tom Poppendieck (2006): "Implementing Lean Software Development." Buch bei Amazon
  

Lean und Kanban auf den XP Days Germany 2010

Vom 25.-27.11. fanden wieder die XP Days Germany statt - zum dritten Mal in Hamburg.
Holger Koschek hat schon einen sehr schönen Post mit seinen Eindrücken geschrieben. Deshalb beschränke ich mich hier auf meine Lieblingsthemen: Lean und Kanban.
Im "regulären" Programm Donnerstag und Freitag gab es insgesamt fünf Session zu Lean und Kanban. Den Anfang machte Traian Kaiser, der über Paradigmenwechsel im Projektmanagement auf dem Wege zur Lean Enterprise bei der XING AG sprach. An dieser Session konnte ich leider nicht teilnehmen, weil ich zeitgleich im Nebenraum eine Karata-Kata gelaufen bin (Foto).
Direkt danach führten Markus Andrezak und Stefan Roock ein kleines (sehr amüsantes) Rollenspiel auf, in dem sie gewissermaßen im Zeitraffer darstellten, wie das Portfolio-Management mit Kanban bei mobile.international funktioniert und welche Entwicklungsschritte bis heute durchlaufen wurden. Passende Folien hierzu gibt es auf Slideshare.
Nach dem Mittagessen haben dann Olaf Lewitz, Bernd Schiffer und ich eine Kanban-Einführung gehalten. Olaf hat zu Beginn die Prinzipien von Kanban dargestellt, und danach haben wir mit sechs parallelen Gruppen das Name Game gespielt, in dem man sehr schön die Auswirkungen von Multitasking in einem praktischen Beispiel selbst erleben kann. Die Teilnehmer produzieren Namensschilder - einmal acht Stück parallel, und einmal eins nach dem anderen. Andreas Schliep hat dazu eine sehr interessante Zahl genannt: Nach dem Putnam Model waren die Gruppen im zweiten Durchlauf bis zu 2.000% (!) produktiver als im ersten! Mir hat die Session riesigen Spaß gemacht. Vielen Dank an alle Teilnehmer insbesondere Olaf und Bernd!
Am Nachmittag gab es dann noch zwei Kurzvorträge zum Thema: Markus Andrezak berichtete von seinem Italien-Urlaub und wie eine Pasta-Fabrik ihn dazu brachte zu erkennen, dass die Lead Time nicht immer entscheidend ist. Hier die Folien bei Slideshare. Und hier der passende Blog-Eintrag von Markus dazu. Dann durfte ich in einem Pecha Kucha Justins Reise vom Wasserfall über Scrum zu Kanban nacherzählen.

Pecha kucha kanban_slideshare

View more presentations from arneroock.

Fast noch interessanter wurde es dann Samstag beim OpenSpace. Dort wurden gleich drei Sessions zu Kanban angeboten: Eine Einführung von Bernd und mir, eine Diskussion zu Scrum&Kanban und schließlich ein sehr interessanter Perspektivenwechsel darauf, unter welchen Bedingungen Kanban schlecht geeignet sein kann und welche Anzeichen darauf hindeuten, dass man es allenfalls mit einer leeren Kanban-Hülle zu tun hat. Vielen Dank an Jiri Lundak, der diese Session angeboten und moderiert hat. Die Ergebnisse wollen wir als Grundlage verwenden, um einige Antipatterns zu Kanban festzuhalten. Mehr dazu hoffentlich bald.

Die XP Days haben wie immer riesigen Spaß gemacht, ich habe eine Menge gelernt und viele interessante Menschen kennen gelernt! Und es bleibt die schöne Erkenntnis, dass Lean und Kanban ihren Platz in der Agilen Community finden und dazu beitragen, die Agile Gedankenwelt weiterzuentwickeln.

Hier finden sich die Fotos zu den XP Days

Was ist noch mal dieses Lean?

Lean hat jeder schon mal gehört. Und alle finden es irgendwie cool. Aber was genau Lean eigentlich ist, kann kaum jemand sagen. Das liegt allerdings nicht daran, dass die Leute zu blöd wären, um Lean zu verstehen. Vielmehr bin ich inzwischen überzeugt davon, dass es das eine Lean gar nicht gibt. Denn es werden unterschiedliche Vorstellungen und Konzepte unter der Bezeichung Lean zusammengefasst. Das reicht dann von der Kostenreduktion um jeden Preis über Einfachheit bis hin zur recht jungen Community der Lean Startups. Ich kann mich noch dunkel daran erinnern, dass wir das Thema Lean Production in der Oberstufe behandelt haben. Das Einzige, was daraus bei mir hängen geblieben ist: Durch die Just-in-Time-Produktion haben die Automobilhersteller ihre Lager auf die Straße verlegt. Also kann Lean offenbar auch bedeuten, die Kosten, die bei der eigenen Verbesserung entstehen, auf die Allgemeinheit abzuwälzen;-) 

Was ist Lean also: Eine Produktionsmethode? Eine Managementphilosophie? Oder doch nur ein (nicht mehr ganz so) neues Schlagwort, unter dem uns alte Kamellen als tolle Neuerungen verkauft werden sollen? Sicherlich ist überall etwas Wahres dran. Für mich liegt der Kern jedoch in etwas Anderem: Lean ist eine Blickweise, bei der konsequent die Perspektive des Kunden eingenommen wird! In Lean geht es darum, möglichst häufig möglichst viel Wert für den Kunden auszuliefern. Alles, was diesem Wert abträglich ist, sollte reduziert oder abgeschafft werden. Und wir wollen uns immer weiter verbessern. Punkt. So einfach ist die Sache. Dies ist der Kern von Lean. 

Worin dieser Wert besteht (und wer der Kunde ist), wird je nach Kontext variieren: Es kann sich ebenso um Geld handeln wie um Wissen, Zeit, Sicherheit oder vielleicht auch Spaß. Dieser Wert lässt sich oft nicht eindeutig quantifizieren, aber es muss ihn geben. Andenfalls sollte man sich ernsthaft fragen, womit man eigentlich seine Zeit verbringt, wenn dabei nichts herauskommt, was für irgend jemanden von Wert ist.

Nimmt man diese Sichtweise ein, dann ist Lean keineswegs auf die Geschäftswelt beschränkt, sondern lässt sich auch auf die Freizeit anwenden. Dann kann ich auch mein eigener "Kunde" sein, und der "Wert" z.B. eines Spaziergangs besteht in meiner Erholung. Aus einer Lean-Perspektive heraus könnte ich mich dann fragen, wie ich mich möglichst oft möglichst vollständig erholen kann. Vielleicht ist die lange Fahrt ans  Meer ein Hindernis für mich, und ich sollte mal nach einer netten Strecke in meiner Umgebung suchen? Oder ich brauche eine winddichte Jacke, damit ich mich auch im Herbst aus dem Haus traue? 

Wenn Lean aber tatsächlich so einfach ist, was hat es dann mit den vielen Schlagworten auf sich, die überall herumgeistern: Defer Commitments, Pull, Optimize the Whole, Build Quality in, Limit Work to Capacity und viele weitere? Hierbei handelt sich sich um Prinzipien, die sich als nützlich herausgestellt haben, um Strukturen und Prozesse in Richtung Lean zu verändern. Sie alle haben ihren festen Platz im Lean-Universum - aber keines dieser Prinzipien an sich macht Lean aus. Sie alle spielen eine "dienende Rolle" bei der Fokussierung auf den Wert für den Kunden. Und wenn wir uns in einer komplexen Domäne wie der Softwareentwicklung bewegen, ist es ja tatsächlich gar nicht so einfach zu entscheiden, wie genau so eine Fokussierung denn nun aussehen soll. Da sind solche Prinzipien dann sehr nützlich.
Unterhalb dieser Prinzipien wird es dann noch einmal konkreter, wenn wir uns die Praktiken ansehen, die allgemein hin als Lean angesehn werden: Stop the Line und Root Cause Analysis wären solche Praktiken. Und viele der agilen Managementtechniken und der Entwicklungspraktiken, die aus XP bekannt sind, ebenfalls. Doch dazu mehr in einem späteren Post.