• Develop service products.
• Develop and manufacture cars (e.g. Wikispeed, Johnson Controls)
• Manage enterprise transitions.
• Execute training classes.
• Manage consulting.
• Organize sales.
• Manage accounting.
• Organize scientific research.
• Schools (see Facebook)

Every area has its own specific challenges. But let’s start with some general observations.

When applying Scrum to non-IT it is in my experience helpful to start with the product concept. What is the created product (or service) we are talking about? When we try to develop and manufacture a car with Scrum this pretty obvious: it is the car. When it comes to more intangible areas we may have to spend some time thinking. Some examples:

• Sales: Is the product a set of orders? Or is the product a set of long-lasting customer relationships? The decision what the product is has a huge impact on the way we think about the work of sales.
• Training classes: One might guess the product is knowledge but that doesn’t cover the whole story. The knowledge was there before the training classes and wouldn’t need the class for creating it. For a CSM class one might think the product is a set of Certified Scrum Masters. That is a valid product and it would focus the training class on test preparation. Since I don’t want to do test preparation and prefer to prepare participants for work I prefer to think of the product as “more skilled participants” (or more specifically “more skilled Scrum Masters”).
• Enterprise transition: The product is an agile enterprise. This seems to be pretty easy but it has a significant impact on the work of the transition team: A set of Powerpoint presentations doesn’t make a valid product increment.
• Scientific research: Often the success of scientific research is measured in publications. Therefore one could think of these publications being the product. But I think this isn’t appropriate. The number of publications is a KPI (Key Performance Indicator) like the revenue for a software product. In the same way you wouldn’t see the revenue as the product you wouldn’t see the publications as the product. I think a more appropriate product is insights.

When the product concept is clear the next step is pretty easy: What are valid product increments and what does “potentially shippable” mean for these product increments. For scientific research an insights might be shippable if it is new to the world of science. In the case of enterprise transition the product increment usually is a more agile enterprise and it is already shipped (= implemented) when the Sprint Review happens. In the case of car development and manufacturing a drivable car may be a valid product increment. But parts of the car that can be inspected, assessed and as a part delivered may also be valid product increments. When you want to create a very fuel efficient car by developing an innovative fuel efficient motor the motor might be a valid product increment. How to produce a product increment like a more agile enterprise every Sprint (at least once a month) may be again very challenges. I will address that later.

Now that we have a concept for product and product increment I like to address the question of the Product Owner. How do we measure success and who is the right person to be the Product Owner for that product. To find an appropriate Product Owner two questions should be answered: Who is empowered to prioritize features (or who could be empowered to do so)? Who is accountable for the product (who is an appropriate “single wringable neck” for the product)?

• For a training class the trainer is the Product Owner. In my training classes we regularly have a discussion if the participants are the Product Owner. I then ask: “Imagine you are pissed off by the training class and leave it disappointed. Who is responsible? You as the participant or me the trainer?” The trainer is the “single wringable neck” and therefore is the Product Owner of the training class.
• For an enterprise transition the Product Owner is a top level manager, e.g. the CEO.

The Product Backlog is quite easy to build. What is necessary to create the product? It may be appropriate to fill the Product Backlog with goals (not features). In sales for example you typically would have goals like “win a deal of at least 100.000 USD at customer XYZ”. When applying Scrum for training classes the learning modules or learning objectives may provide the Product Backlog Items.

The next step is to form the Development Team. The team needs all the skills necessary to produce product increments. When we have a clear understanding of the product we want to deliver it is quite easy to decide who should be in the team. For an enterprise transition the team needs to have managers and leaders of the company (otherwise the team is not able to achieve changes).

As the Scrum Master you need an experienced Scrum Master (of course) but as a rule of thumb you a more experienced Scrum Master than for an average software development project. The body of knowledge about how to apply Scrum for non-IT is much smaller than for software development. That means that the Scrum Master needs a more solid understanding of the Scrum principles and he needs to facilitate insights about how to apply Scrum in new ways.

When you have chosen an appropriate product the Sprint Review is easy. When you have problems demonstrating and inspecting product increments and gathering feedback about the product chances are high that your product concept is inappropriate.

During the Sprint Retrospective the Scrum Team (Product Owner, Development Team and Scrum Master) inspects its way of working and comes up with action items to improve their way of working.  I haven’t encountered any specific challenges here when applied to non-IT.

The mechanics of Sprint Planning and Sprint Backlog are easy to apply but during Sprint Planning a problem may become visible: The team has no idea how to create product increments at least every month:

• How could we possibly change the organization in just one month?
• How could we create a car in a month?
• How could we win a new customer in just a month?

The team has to find out how to create product increments every Sprint and we need to bear the tension that is created: We need to create product increments every Sprint and we don’t know how. Constraints like these create innovations. Just extending the Sprint length or faking the product concept (“Powerpoint presentations are the new product”) would kill this possibility to improve. We need to forge and apply new ways of working and there is no promise that we will succeed. In all the areas I listed at the beginning of this article teams have managed to find these new ways of working. I am confident that others can do it also.

In some cases we have to tweak the Sprints. A training class might last for two days. Since we want to gather feedback from the participants during the training we might end up with a Sprint length of 2 hours or a half-day. That might question the justification of the Daily Scrum. While there are ideas how to apply Daily Scrums in such a situation I generously skip them in training classes with a Sprint length of a half-day. (But I have applied four Daily Scrums per day for software development successfully).

Some domains require the team members to work highly distributed. Consultants may form a team but work at different clients. Sales people also normally work alone or in pairs when they work with clients. Still coordinating with the rest of the team to achieve a higher mission (create the product) is worthwhile. But is more challenging to apply appropriate mechanisms and the Scrum Master may have more work to do to make people cooperate that were used to work on their own for years or decades. Sometime it might be appropriate to transform the Daily Scrum into a Weekly Scrum.

When Scrum is not appropriate

The list of areas where Scrum is applied may suggest that Scrum could be applied everywhere. That may be true but it wouldn’t be efficient. Scrum needs teamwork. When teamwork isn’t necessary or teamwork isn’t achievable Scrum doesn’t make sense. When you just have routine work with low variability to do and there is nothing to lean, Scrum is inefficient (why would you talk so much during Planning, Review, Retrospective and Daily Scrum?).

But sometimes there are surprises. I would have thought that accounting is just routine work that doesn’t need a team. But I know of several accounting teams that say that teamwork is appropriate for them.

Summary

Scrum can be applied to a lot of knowledge work domains where teamwork is appropriate. For most areas outside IT there is only a small body of knowledge about how to apply Scrum. When trying to apply Scrum in a new area prepare to be challenged. I love to hear your experiences and of course I offer my help as a coach when you want to apply Scrum to areas outside IT.

Tagged: Scrum

The Scrum Sprint Planning incorporates the so-called pull principle. The pull principle origins from the Toyota Production System (at least it is he first occurrence I know of) and aims at creating flow while avoiding overload. A processing unit B pulls new work from an upstream processing unit A when B hast he capacity to process it. This is in contrast with the push principle where a planner defines how many items should be processed by time unit and results of upstream processing unit A are pushed into the downstream processing unit B.

In the Sprint Planning the team pulls work from the Product Backlog (the Scrum Guide says that the development team „selects“ Product Backlog Items for the Sprint).

One re-occurring question is whether the team is allowed to deviate from the prioritization – for example when a Product Backlog Item is too fuzzy or when the development team thinks an Product Backlog Item is just bullshit.

The answer is: it depends.

The very first reason fort he pull principle is to avoid overload with its negative consequences (lower quality, burnouts, developers quitting jobs etc.). Therefore it is totally valid to expect the team to pull work strictly according to the prioritization. While older literature is sometimes a bit ambiguous about the „selection“ of Product Backlog Items the current version of the Scrum Guide is pretty clear about that: „The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.“ (emphasis added by me)

But.

Kent Beck once told me that he likes to ask developers if they would invest their own money into the product they are working on. I use this question from time to time when working with teams and I will never forget a larger retrospective at a client where I asked the team exactly Kent’s question: „Would you invest your own money into the product you are developing?“ The team laughed and answered: „We think it would be more valuable to buy Greek government loans.“

That is great feedback for the Product Owner. The team isn’t convinced about the product but it should be (remember the Scrum value „commitment“). The Product Owner should start asking questions: Is the product idea bullshit? Does the prioritization of features lead to weak product while the product idea may be great? Does the team lack the information about the market and users needs to understand the product and the prioritization of features? Working with these questions provides the opportunity to enhance the product a lot. But it requires hard work on the side of the product owner.

A Product Owner who is open for these kinds of discussions may apply the pull principle not only for limiting the amount of work to the team’s capacity but also to the meaning of work. The team would only pull Product Backlog Items into the Sprint when it is convinced that these items are valuable fort he product.

I have seen a lot of confusion about these two types of the pull principle. To make clear what we are talking about we could call the original pull principle „workload pull“ since its motivation is to find the optimal workload. The extended pull principle could be called „purpose pull“.

The workload pull delegates the decision about how much work can be done to the team. The purpose pull delegates the decision about what should be done to the team.

How much?	Pull	Workload Pull	Purpose Pull
	Push	Traditional Project Management	X
		Push	Pull
		What?

Valve (a company famous for its computer games) applies purpose pull on a product level. Developers choose the products they are working on. If a Product Owner has an idea for a new game but is not able to motivate developers to join his project the game wouldn’t be implemented. (see http://assets.sbnation.com/assets/1074301/Valve_Handbook_LowRes.pdf)

Typical open source projects apply purpose pull on the product level as well as on the feature level. Everybody decides for himself on what product to work (and is free to quit whenever he is fed up) and within the product development the developers are free to choose the features to implement.

The following table summarizes the two pull principles:

Workload Pull	Purpose Pull
Create flow of work	Create better products
Avoid overload	Provide meaning for the development team
	Enhance work satisfaction of the development team
Avoid quality problems due to overload	Avoid quality problems due to decoupling of the team from the product

Scrum as a framework supports workload pull as well as purpose pull. (Applying purpose pull to the fullest possible extend would eliminate prioritization by the Product Owner completely and then you leave the Scrum framework). Every project has to determine the appropriate pull level.

Tagged: Scrum

There is a simple, yet powerful idea in Scrum: When every single Sprint has a positive ROI (return on investment) risk management becomes very easy and the need for accurate long term planning diminishes.

When every single Sprint has a positive ROI you can just plan from Sprint to Sprint. When a Sprint planning provides the information that this Sprint would not generate more value for the company than it costs, you just stop the development. You have created something with a positive ROI with the previous Sprint(s) and everything is fine.

Think about it. How cool is that!

Impossible? No. I have seen it working.

Hard to achieve? Of course. You need to resign from traditional project planning and really think about how to create small valuable software increments. And adapting a new perspective is always challenging.

P.S.: One may ask what I mean with ROI. For me a Sprint has a positive ROI when you could just stop after the Sprint and have created a value that is higher than the Sprint costs.

Tagged: Scrum

A train ride to Stockholm is not a petting zoo!

The af Chapman

Checking Wifi at Ericsson

Make sure you never run out of beer!

Crazy Matze

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

On my way back from the Agile Practitioners Conference 2013 in Tel Aviv, Isreal I digest lots of information and bar discussion content. After attending Dan North‘s tutorial on Tuesday, I have six sheets of paper on notes with me, that will probably fill my writing buffer for the next half year. Time to get started. Here I connect Dan’s model of the Three Ages to Software Testing.

What are the Three Ages? The Three Ages describe a model of growth for a product. The three different ages in short are Explore, Stabilize, and Commoditize. In these three different ages, you have different gaps to fill.

Explore

In the first, Explore, you focus on learning and discovery. In a software product sense, you start to learn about the problem that your customer has, ie. by interviewing him, by running minimal viable products, or by working in his context. At this point you want to find out as much as possible to make sure that you understand the problem well enough to do something about it, to solve it. Here you optimize for discovery.

In software testing you do the same thing in different ways. When doing Exploratory Testing, you are learning a lot. According to Wikipedia Exploratory Testing can

concisely [be] described as simultaneous learning, test design and test execution.

After executing one test, you can take the outcome of that test, to inform your next step. That might be to dive deeper into the system, to find out more about that possible bug you just observed, or to continue with your current mission.

And there is more. When doing session-based test management, you can use a touring approach to learn as much about a product as possible in a given time-box, to plan out more sessions to dive deeper. Here, you do the same exploration and learning loop on a broader level. You explore the application to inform the next step, that is to plan your test strategy for the next couple of sessions.

The same holds true for backlog grooming meetings that many teams nowadays seem to do. Here you try to explore the technical and business constraints. Why is this relevant for testing? This is relevant for testing that particular piece of software later, as you are able to consider different constraints for all the variables that you can find. Variables in short are anything that you can vary in a product or product domain. There are technical limitations like the amount of bits stored internally that you may vary, and there are business and domain constraints that you might want to explore. The specification workshop and the backlog grooming meeting is the place to find out more about these.

Stabilize

In the stabilization age you aim for repeatability. So far, your learning has proven that you can do it – once. Now is the time to prove a repeatable success with your product. Arguing from the Lean Startup model, you have analyzed the problems your customers are having, and now you start to evaluate whether your product solves the problem for your customer.

With regards to software testing, at this point I would consider the parts that I want to automate to free myself time to learn more about the product later. Usually, I aim for a trade-off between learning and repetition – fully aware of my second-order ignorance: the things I don’t know that I don’t know them. The stuff that I know, I can automate – but only to be able to learn more about the things I don’t know. This is where test automation is more useful than using my spare brain cells at boring repetitious stuff.

Commoditize

In the third age, you try to make your product a commodity. You have reached the point to scale your customer base, and should be able to constantly grow. In the Lean Startup sense, you have developed your customer base, and can now aim for the big market. You have proven that your product solves the business problem. Now is the time to scale, and make your business model more efficient to fit the target market.

Unfortunately I see a lot of software testing projects failing to realize that they need to make their test automation more efficient. In the model, they fail to understand the need to make automated tests as fast as possible – and to refactor existing automation code structures to be flexible in the near future.

The model in action

In retrospect I realized that I had used the underlying thought-process a few years back. One of my colleagues and I were called into a project which was half a year late. There were three weeks left, and no automated tests. My colleague and I sat together and identified different test charters, and different tests to run in the short timeframe.

For the first week we started with completely manual tests. That was hard, as the test setup times were quite long. Our goal here though was to learn more about the new business domain which we didn’t know at that time. By re-testing the bugfixes, we were able to conduct that learning. We were tackling with the first age.

At the end of the first week, I became impatient. We were doing the same tests over and over again. On that Friday we sat together, and identified what to automate first. We had reached the point where we learned enough, and it became time to enter the stabilization age. We lay out a plan to tackle the different use cases and come up with automation for all the bits. We focused on repeatability of those tests. Two weeks later, we were done with that, and had been able to support the on-going UAT in that time.

After that, the project continued, and we were able to enter the third age as well. We started to make the automated tests more convenient. We started to make the whole flow more efficient, cleaned up the test automation code, and updated the commonly used library that we had grown over time. This is the third age in Dan North’s model.

To me, the Three Ages appear to be a useful model to understand where you currently are, and what your current focus probably should be.

On Saturday I read this tweet by David Anderson:

One great thing about #lkna13 is the empowerment of track chairs. As conference chairman I like to get surprised by speaker selection
— David J Anderson (@agilemanager) 26. Januar 2013

I am one of the track chairs, and this tweet made me think about empowerment (again).

Empowerment is not that easy

No matter which concepts and models you dig into - nowadays almost all of them recommend empowerment. And who would ever argue against empowerment? So just empower everyone, and you‘ll be golden, right? The problem is: It is really hard to "do" empowerment right. In order to make empowerment successful, you need boundaries, trust, an appropriate environment, and leadership. As soon as you lack one of these ingredients, empowerment might not work as you want it to. I will walk through these points and use the conference Lean Kanban North America (LKNA) as an example.
The LKNA conference is split into 6 different tracks plus the main stage. Every single track has a track chair who is responsible for setting up the program for his track. Hillel Glazer is the program chair, so he‘s responsible for the overall program (watch this video with Hillel), of course he works closely together with David Anderson, who is the conference chairman (he pays the bill;-).

Boundaries

The first thing that Hillel did after he had found his track chairs was to organize a conference call where  we discussed some basic stuff about the conference. But what he basically did was setting the boundaries. Three of them (and the most obvious ones) are: Every track chair has a budget to compensate for travel expenses and a certain amount of nights in the speaker hotel. There are also deadlines for having the program ready. And the sessions should somehow be related to the topic of the track.

Trust

Environment

Leadership

An dieser Stelle möchte ich einen anderen Ansatz vorstellen. Dieser Ansatz legt gleich viel Gewicht auf die Kanban-Prinzipien, die meiner Meinung nach an erster Stelle kommen sollten (nicht umsonst heißen sie Grund-Prinzipien (foundational practices)) und die Kernpraktiken. Sowohl den Prinzipien als auch den Praktiken liegen Werte zugrunde. Wenn wir diese Werte identifizieren, behandeln wir automatisch alle Hauptelemente der Kanban-Methode. Vielleicht eignet sich dieses Vorgehen ja auch als Framework, um Kanban zu schulen?
Auf jeden Fall ist das Ergebnis holistisch (die Werte lassen sich auf ganz unterschiedlichen Ebenen anwenden), es entspricht dem grundlegenden Zweck von Kanban (Veränderung von Organisationen), und es hilft, mit den drei falschen Vorstellungen aufzuräumen, dass Kanban
i.         eine Methode für Softwareentwicklung sei;
ii.        keine Werte mitbringe, die Organisationen und Change-Agents vor Herausforderungen stellen;  
iii.        nur etwas für Tool-fixierte Zahlenfreaks sei, die in Kontroll-versessenen Organisationen arbeiten (diesen Punkt übertreibe ich nur ein wenig).
Darüber hinaus möchte ich zeigen, dass eine  Wert-basierte Beschreibung von Kanban auch aus anderen, konstruktiveren Gründen nützlich ist.

Mein Ausgangspunkt

Aus den Grund-Prinzipien von Kanban in ihrer gängigen Reihenfolge leite ich vier Werte ab: Verstehen, Einverständnis, Respekt, Leadership. Der erste Wert erfordert eine Erklärung, aber die anderen drei lassen sich direkt aus den Prinzipien ableiten, so wie sie üblicherweise formuliert werden.
Die Werte, die hinter den sechs Kernpraktiken stehen, sind hingegen etwas schwieriger. Nicht, weil sie nicht da wären, sondern weil es hier keine unmittebare 1:1-Beziehung gibt. Ich habe weitere vier Werte aus den Praktiken abgeleitet: Transparenz, Balance, Flow, Zusammenarbeit. Ich finde es allerdings sinnvoll, hier von der offensichtlichen Reihenfolge abzuweichen und außerdem einen weiteren Wert hinzuzufügen, so dass wir bei insgesamt neun Werten landen.
Wir werden uns diese Werte gleich einen nach dem anderen ansehen und dabei auf weitere mögliche Kandidaten stoßen. Ich werde durch Fett-Druck alles hervorheben, was für mich nach einem Wert aussieht (in erster Linie abtrakte Substantive). Mit einer Ausnahe (Fokus auf den Kunden), auf die ich bereits angespielt habe, sind sie jedoch nicht so wichtig, weniger grundsätzlich und weniger im Kern von Kanban als die dargestellten Grund-Werte.

Die neun Grund-Werte von Kanban

1. Verstehen

Verstehen bezieht sich auf die Sache, die wir gerade verändern – egal ob es sich um ein wichtiges Detail des Prozesses handelt, um die Art, wie unser Prozess unter Stress-Bedingungen funktioniert oder so etwas abstraktes wie der generelle Ansatz, nach dem Veränderung in unserer Organisation vorgenommen wird.

Insist on understanding because a healthy process that can’t defend itself is a sign that you’ve forgotten what you believe.
Zitat aus: The Process Myth, Rands in Repose

In unseren Kanban-Schulungen unterrichten wir einen Systems-Thinking-Ansatz, bei dem Verstehen sehr hohe Priorität genießt. Verstehen spielt also schon ganz am Anfang, bei den Kanban-Grundlagen, eine wichtige Rolle – von der ersten Übung an. Woher kommen unsere Aufgaben? Wodurch sind verschiedenen Arten von Aufgaben charakterisiert? Welche Ansätze, um Veränderungen herbeizuführen, haben eine große Wahrscheinlichkeit, erfolgreich zu sein oder zu scheitern – generell und in unserer eigenen Organisation? Woran könnte das liegen?
Wenn es kein Verstehen gibt, dann haben wir es per Definition mit Cargo-Kult-Implementierungen [http://de.wikipedia.org/wiki/Cargo-Kult] zu tun. Selbst wenn es aus dem besten Absichten geschieht: Wahrscheinlich wird es kein Verstehen geben, wenn Veränderungen top-down durchgeführt werden, wenn sie nicht ausreichend motiviert werden (zum Beispiel, indem immer wieder auf Best Practices [http://en.wikipedia.org/wiki/Best_practice#Critique] verwiesen wird) oder wenn Veränderungen ohne weitere Reflexion auf unterschiedliche Bereiche der Organisation angewendet werden. Es kann uns daher nicht wirklich überraschen, dass Veränderungsprojekte häufig zu Enttäuschungen führen. Zum Leidwesen von fauilen oder unfähigen Managern erfordert Verstehen (ebenso wie die verwandten Werte Lernen und Alignment) einige Anstrengung.


2.    Einverständnis
Einverständnis findet sich direkt im zweiten Grundprinzip: „Einige dich mit Anderen darauf, inkrementelle, evolutionäre Veränderungen durchzuführen“. Ich würde hier gern einmal die Perspektive umdrehen: Können wir wirklich davon ausgehen, dass Veränderungen ohne Einverständnis funktionieren kann? Könnte es sein, dass ein Mangel an Einverständnis unserem Erfolg im Wege steht? Oder vielleicht gibt es zwar Einverständnis, aber dieses ist nicht tief greifend genug – wir sind uns darüber einig, dass ein bestimmtes Problem vorliegt, aber wir sind uns uneinig, was die Ursachen sind und welche Auswirkungen es gibt (hier landen wir direkt bei Verstehen).

Dieses Prinzip könnte einen weiteren Wert beinhalten: Inkrementalismus. Ich sehe dies jedoch nicht als einen Kern-Wert an. Denn wir treten ja für inkrementelle, evolutionäre Veränderung ein, weil sich dadurch die Erfolgswahrscheinlichkeit erhöht – und nicht weil die Alternativen des Radikalismus bzw. Konservativismus grundsätzlich schlechter wären. Wir könnten natürlich auch Pragmatismus als weiteren Wert einbringen, aber dieser wäre schwer greifbar.

3. Respekt
„Respekt für die Menschen“ bildet eine der Säulen von Lean. Auf Veränderungen bezogen findet sich dieser Respekt im dritten Kanban-Prinzip wieder: „Respektiere zu Beginn die bestehenden Rollen, Verantwortlichkeiten und Berufsbezeichnungen.“

Genau so wie im übrigen Leben, ist Respektauch dann eine gute Idee, wenn es um Veränderungen geht. Erhöhen wir unsere Erfolgschancen, wenn wir andeuten, dass Menschen schlechte Arbeit leisten oder dass ihre Rollen nutzlos sind? Wahrscheinlich nicht! Ist es nützlich, Anderen schlechte Absichten zu unterstellen? Vermutlich auch nicht.!Aber bedeutet Respekt, dass wir immer nett sein müssen? Auch das nicht!

Respekt für Menschen zu zeigen, bedeutet nicht, dass wir jeden mögen müssen, mit allen Meinungen übereinstimmen müssen oder jedem halbgaren Argument zustimmen. 
Stephen Parry 

Wenn wir Respekt in dieser Weise verstehen, dann gehört auf jeden Fall auch Mut dazu. Und dies führt uns direkt zu unserem nächsten Wert.

4. Leadership
Leadership taucht in so gut wie jeder Erfolgsgeschichte auf, wurde aber erst 2012 als weiteres Kanban-Prinzip mit aufgenommen: „Sorge dafür, dass Leadership auf allen Ebenen der Organisation stattfindet – von einzelnen Mitarbeitern bis zum oberen Management.“

Über Leadership wurde bereits viel geschrieben, und ich möchte an dieser Stelle nur einige kurze Beobachtungen hinzufügen:
i.         Vielleicht wünschen wir uns manchmal einen Autokraten á la Steve Jobs (oder Steve Ballmer) – aber mit Leadership „auf allen Ebenen“ ist etwas anderes gemeint.
ii.         Leadership ist zu begrüßen, aber das bedeutet nicht, dass Management automatisch schlecht wäre (wir erinnern uns an Respekt?)
iii.         Weiterhin schließt weder Leadership noch Management Selbstorganisationaus – in dem Sinne, dass Einzelpersonen, Teams und Systeme sich weiterentwickeln dürfen, ohne dass ihnen dafür zentral eine Richtung vorgegeben wird. Ganz im Gegenteil: Gute Leadership und gutes Management sorgen für die Bedingungen, unter denen Selbstorganisation gedeihen kann.
iv.         Gute Leadership bedeutet immer auch Herausforderung (wir haben darüber schon kurz gesprochen). Wer Veränderungen vorantreibt, muss darauf gefasst sein, andere herauszufordern und selbst herausgefordert zu werden.

5. Flow
Wir wenden uns jetzt den Praktiken zu und beginnen mit Nummer drei: „Den Flow managen“. Der Management-Anteil dieser Praktik meint die taktische Organisation sowie Entscheidungen, die darauf abzielen, Aufgaben so gut wie möglich zu bearbeiten (Effektivität). Dies hat auf einem gewissen Abstraktionsniveau universelle Gültigkeit – allerdings mit sehr unterschiedlichem Erfolg.

Flow fügt dem noch etwas hinzu, das weit weniger offensichtlich ist: Gleichmäßigkeitund Vorhersagbarkeit. Sich systematisch um alles zu kümmern, was den Flow behindert, stellt ein mächtiges Werkzeug für Verbesserungen dar – so wie es in Lean angelegt ist.
Darüber hinaus schätzen wir Flow auch im Sinne von Csikszentmihalyi, also dieser positive Zustand, in dem wir komplett in unsere Aufgabe versinken. Dieses Art von Flow ist schwer zu erreichen, wenn wir ständig abgelenkt und unterbrochen werden und wenn häufig wechselnde Prioritäten unsere Arbeitsumgebung dominieren.

6. Fokus auf den Kunden
Wir sind noch nicht ganz fertig mit „den Flow managen“! Eine ausführlichere Version dieser Praktik könnte lauten:

Sorge dafür, dass es einen gleichmäßigen Flow gibt, in dem früh und regelmäßig Wert für den Kunden ausgeliefert wird.

Wert ist hier in dem Sinne von Zweck (also das Verstehen des „Warum“ des Kunden) gemeint, aber sehr wohl auch monetär (wobei wir Nützlichkeit nicht mit Kosten verwechseln sollten). Wenn wir uns wirklich darauf konzentrieren, Dinge für den Kunden fertig zu stellen (Completion), so geht dies sowohl über die reine Erledigung von Aufgaben als auch über die Produkt-zentrierte Sichtweise (potenziell auslieferbares Produktinkrement) hinaus. Meiner Erfahrung nach ist dieses Konzept überraschend herausfordern und hat oft dramatische Auswirkungen.
Wenn wir nur Aufgaben erledigen, von denen der Kunde nicht profitiert, so haben wir nichts weiter produziert als Kosten (sunk cost). Wir werden auf diesen Punkt später noch einmal zurückkehren und über den Aspekt „regelmäßig“ sprechen, wenn wir den Wert Balance behandeln.

7. Transparenz
Transparenz untermauert drei Kanban-Praktiken:  Die erste “Visualisierung [der Arbeit]”, die vierte “Regeln explizit machen” und die fünfte “Feedback-Schleifen einrichten”.

In Kanban wird Transparenz auf unterschiedlichen Ebenen hergestellt:
i.         Die Arbeit wird sichtbar gemacht
ii.         Der Workflow wird sichtbar gemacht: Welche Stationen durchlaufen Aufgaben? In welchen Prozessschritten befinden sich unsere Aufgaben gerade?
iii.         Die Einflussgrößen, Regeln und Grenzen, die unsere Entscheidungen beeinflussen und letztlich auch die Leistung unseres Systems bestimmen, werden sichbar gemacht.
iv.         Die Auswirkungen von i. – iii. werden durch Kunden-zentrierte Metriken sichtbar gemacht.

Die ersten beiden Arten der Transparenz ergeben sich automatisch aus kanban-Systemen (mit kleinem k), nach denen die Kanban-Methode ja benannt ist. Die ersten drei Punkte zusammen erzeugen wichtige Hebel – Stellen in unserem System, an denen bedeutende Veränderungen zu relativ geringen Kosten vorgenommen werden können. Die vierte Praktik (Feedback-Schleifen) stellt sicher, dass unsere Veränderungen in die gewünschte Richtung gehen.
Kanban stellt deshalb einen Weg dar, um Systeme entstehen zu lassen, die ständig lernen und sich anpassen – eine Strategie für Organisationen, bessere Fitness in einem von Konkurrenz geprägten Ökosystem zu erlangen.

8. Balance
Die zweite Praktik lautet: „Den Work-in-Progress (WIP) limitieren“. WIP-Limitierung eines Prozesses bietet verschiedene Vorteile:

• Wie durch Little’s Law dargestellt wird, verkürzen sich Durchlaufzeiten (und damit auch Feedback-Zyklen) tendenziell. Der Kunde wird früher zufrieden gestellt, und wir können schneller lernen. 
• Neue Arbeit wird nur dann begonnen, wenn es auch freie Kapazitäten dafür gibt. Dadurch entsteht Flow aus der Perspektive der Aufgaben. Und es entsteht Balance zwischen Bedarf und Versorgung aus Sicht der Teams und Einzelpersonen (Respekt).
• Wenn wir uns ein bisschen näher damit beschäftigen, dann wird klar, dass es auch zur Balance zwischen verschiedenen operativen Aufgaben sowie zwischen operativen Aufgaben und Verbesserungen kommt.

Der letzte Punkt legt ein weiteres Prinzip nahe: „Heiße Vielfalt willkommen“. Systeme, die gut mt Vielfat umgehen können, lassen sich als robust (resilient) beschreiben. Dies ist gut für die Kunden ebenso wie für die Angestellten und Organisationen – auch hier finden wir wieder Balance.
Zusammenarbeit findet sich in der sechsten (und letzten) Kernpraktik: “Sich gemeinsam verbessern und durch Experimente weiterentwickeln [indem man Modelle [und wissenschaftliche Methoden] verwendet]”.
Aufbauend auf den Werten Verständnis, Respekt und Fokus auf den Kunden formuliert Zusammenarbeit die Erwartung, dass wir über die Grenzen unseres eigenen Teams hinausgehen, um Hindernisse aus dem Weg zu räumen, die dem Flow im Wege stehen.
Wenn wir nun auch noch die zwei Teile dieser Praktik betrachten, die in Klammern stehen, so finden wir darin die Aufforderung, systematisch daran zu arbeiten, unser Verstehen zu verbessern, indem wir Beobachtungen anstellen und Modelle, Experimente sowie Messungen verwenden (Empirie).
Der Zusatz „Modelle verwenden“ hat außerdem noch eine weitere Bedeutung – nämlich dass wir die Werte Neugierund sogar Großzügigkeit ernst nehmen sollten. Kanban ermutigt alle Anwender ausdrücklich, sich außerhalb der eigentlichen Methode umzusehen, welches Wissen dort noch zu finden ist. Kanban erkennt an, dass viele seiner Wurzeln in anderen Bereichen liegen: Lean, Engpasstheorie, Agilität, Grundlagen der Warteschlangentheorie und der Komplexitätstheorie, Einflüsse aus Lean Startup und der Familientheraphie. Viele Kanban-Anwender verwenden die Modelle, die sie persönlich bevorzugen – ich zum Beispiel beziehe mich viel auf die Modelle A3, GROW und Influencer.

Warum nur neun?

Ich fand es schade, dass der Lean-Wert Fokus auf den Kunden sich nicht ohne weiteres aus den Standard-Formulierungen der Kanban-Prinzipien und –Praktiken ableiten ließ. Man könnte also sagen, dass ich an dieser Stelle geschummelt habe! Ich bin aber nach wie vor der Meinung, dass dieser Wert seinen Platz völlig zu Recht in Kanban findet.
Bei den anderen Werten, die ich herausgearbeitet habe, sieht es nicht ganz so klar aus:

• Lernenund Alignment sind stark mit Verstehen verbunden. Mir ist bewusst, dass es gute Argumente für jeden dieser drei Werte gibt. Ich habe mich für denjenigen entschieden, der meiner Meinung nach am besten die Wurzeln widerspiegelt, die Kanban im Systems Thinking hat. Derjenige meiner Artikel, der am häufigsten referenziert wird (http://positiveincline.com/index.php/2010/06/learning-together-kanban-and-the-twelve-principles-of-agile-software/), legt einen Schwerpunkt auf Lernen. Es war also eine harte Entscheidung, mich hier gegen Lernen zu entscheiden.
• Herausforderung (ebenso Vision) und Mutüberschneiden sich klar mit Leadership, aber ich betrachte sie nicht als fundamental. Vergleiche hierzu meinen Post Dole out the 3C’s.
• Selbstorganisation steht ziemlich weit oben, wenn es um Werte bezüglich der Gestaltung von Organisationen geht, aber Respekt scheint mir für Change Agents eine ebenso gute Anleitung zu bieten. Wenn alles Andere gleich bleibt, würde man durch Respekt immer eine Lösung vorziehen, die Selbstorganisation zulässt oder aktiv aufbaut.
• Robustheit spielt eine große Rolle in meinem eigenen Denken, aber hiermit wird eher ein Resultat als ein Ansatz beschrieben. Dasselbe gilt für Gleichmäßigkeit und Vorhersagbarkeit.

Die Werte im Einsatz

Sehen wir uns unsere neun Werte noch einmal an:

Verstehen, Einverständnis, Respekt,
Leadership, Flow, Fokus auf den Kunden,
Transparenz, Balance, Zusammenarbeit

Ich muss zugeben, dass dies eine recht lange Liste ist – länger als die drei oder vier Werte, von denen ich lange Zeit bei verschiedenen Gelegenheiten gesprochen habe. Auf der anderen Seite sind es auch nicht so viele, dass man nicht mehr vernünftig darüber reden könnte. Sie lassen sich auch noch gut merken, so dass man auch leicht auf sie verweisen kann.
Ergeben einige dieser Werte mehr Sinn für Sie als andere? Was folgt daraus? Ich überlege, hierüber auf einem Leadership Retreat mit anderen Praktikern zu diskutieren – die unterschiedlichen Meinungen könnten extrem erhellend sein!
Gibt es Werte aus dieser Reihe, die in Ihrer Umgebung fehlen? Was folgt daraus? Können Sie daraus folgern, dass etwas geändert werden sollte?
Wenn ich beispielsweise zurückblicke, dann kann ich mich an viele Situationen erinnern, in denen es nicht genug Einverständnis gab. Dadurch wurden Veränderungen entweder langsam, oder es ergaben sich Veränderungen, die sehr schnell wieder zurückgedreht wurden. Und wenn ich mir Erfahrungsberichte von Anderen ansehe, dann bekomme ich den Eindruck, dass nicht nur ich diese Erfahrung gemacht habe.

Reflexion

Ich habe Werte explizit gemacht – dies ist angewandte Transparenz. Hierdurch wird Herausforderunggeschaffen (in erster Linie, weil ich den Fokus auf den Kunden noch deutlicher im den Kern von Kanban sehen möchte). Außerdem habe ich durch diese Transparenz mein Verstehen von mindestens einer Quelle von Unzufriedenheit besser verstanden. Im Sinn von „Eat your own dogfood“ funktioniert das System! Das gefällt mir!
Ob Sie und die Kanban-Community dieselben Werte wählen würden, ist eine interessante Frage, die ich gern diskutieren würde. Wie könnte man sonst noch vorgehen? Ich würde wirklich gern alternative Ansätze sehen. Ist es vielleicht nützich, die Werte, die ich ausgewählt habe, anders zu strukturieren oder anzuordnen? Oder sind Werte so zerbrechlich, dass man am Besten gar nicht über sie spricht?
Aufbauend auf einem Gedanken, der auf meinen Post How Deep is Your Kanban? vor einigen Monaten zurückgeht, stellt sich mir die Frage: Könnten Werte eine bessere Basis darstellen, um ein Assessment-Tool der zweiten Generation für Kanban zu etablieren? Im Moment fokussiert das Assessment-Tool auf die Praktiken. Wird dadurch vielleicht der wahre Zweck von Kanban verschleiert? Ich glaube, das ist gut möglich.
Ob die Werte einen guten Weg darstellen, um Kanban zu erklären und einzuführen, lässt sich nur herausfinden, indem man es ausprobiert. Das werde ich tun.

Right before Christmas I crossed a write-up of Al Shalloway about Kanban being the integration of Deming, Ohno, Goldratt’s Theory of Constraints, Satir and Nonaka. At a similar time I finished Jerry Weinberg‘s most recent book Experiential Learning Volume 3 – Simulation. Jerry explains the Satir Change Model in such a great way, that I would like to elaborate a bit more on the relevance of the model particular for Kanban.

Status Quo

The status quo is the state that you are currently in. Everything is quite comfy, you don’t need to bother about things outside your personal experiences that could go wrong. You can rely on different givens, and everything just works out well for you. Weinberg describes this state as “everything being familiar and in balance”. The status quo is “the outcome of of a series of attempts to get all the outputs of the system under control”. But the balance in that outcome might come at a cost:

[That] balance may require various parts of the system to have an unequal role in maintaining that balance.

In his blog entry, Al Shalloway writes about people preferring to work in their comfort zone. I consider the comfort zone as the late status quo that you are working in. You can lean back, do business as usual, and don’t have to cope with such things as foreign elements that kick you out of your comfort zone.

Foreign Elements

As Weinberg describes it, “change takes place in an unending series of cycles”. What causes such a cycle to start changing behavior is a foreign element. That foreign element is not particularly a sudden crisis, but rather the “sudden realization that things have been very unhealthy”. Or to put in Weinberg’s words from his book Secrets of Consulting:

It may look like a crisis, but it’s only the end of an illusion.

(Rhonda’s First Revelation on page 149)

Such a foreign element is out of control of the current system. That’s why it’s a foreign element.

There are many things that could yield a foreign element. The death of a person near to you is the beginning of the realization that something (or someone) has to step in that gap that will be created there. The missed deadline in your project plan might cause you to run around like headless chickens asking everyone to work overtime to please the customer by appearing to work. And finally, the introduction of transparency in terms of a visualization on a Kanban board can lead to a foreign element that causes programmers to start helping out at the perceived testing bottleneck.

Yes, that’s right. The introduction of a the first practice in Kanban – visualize your workflow – alone may lead to an foreign element. In the end, Kanban claims to be an evolutionary change method. Taking Weinberg’s picture from before – “change is an unending series of cycles” – it is inherent to Kanban that it introduces a foreign element for the first cycle to begin. Or stated in another way: Whatever you observe, gets changed – a problem every anthropologist is aware of.

Chaos

What happens in the chaos stage of the Satir Change Model is merely the try to cope with the foreign element. Depending on the foreign element, people in the system might reject the foreign element to cope with it, ignore it, hide form it, or actively fight it. What characterizes the chaos stage in the Satir Change Model is “that predictions no longer work”, “old expectations are not fulfilled”. “The Old-Status-Quo system has been disrupted.”

As a reaction on this, people might become scared, hiding from the foreign element, neglecting it, deny it, or deflect it – effectively playing the Hot Potato game. Weinberg describes that “people try random
behavior, or try reverting to even earlier behavior patterns, perhaps from childhood.” What’s remarkable about people in the chaos stage is that their thinking ability might be reduced since they will argue from an emotional viewpoint, not from a rationale one. In the end, fear, is an emotion, right?

More interesting, people might reject the foreign element so much, that they end up at Old-Status-Quo behavior. They might inflict the element to someone else, or might cope with it in a different manner only to get back to their comfort zone. In the end, it’s very comfy there.

To get back on my earlier example of the Kanban board, the board should be hard to reject. In the end, it tells the story of the old process. It makes things transparent. It will help you and your team overcome the temptation to revert to your Old-Status-Quo. That does not mean that Kanban inherently will lead to better changes, or lead to changes at all. That means, Kanban implemented well will make the rejection of foreign elements as they occur hard. That might also mean that Kanban implemented badly will lead to worse behavior than your current status quo. My gut feeling tells me that the recent addition of leadership to the Kanban practices yields from enough bad Kanban implementations because it needs leadership to help the team overcome the tendency to reject the foreign element they see and hide from on their boards. Kanban implemented well also means to nurture a culture of change.

Integration and Practice

During the stage of integration and practice, people will try various things to cope with the new foreign element. They will try out new things to overcome the short-comings of their old predictions. While productivity might have sunk during the chaos stage, in the integration and practice stage it will start to fluctuate. People will need a lot of slack-time to try out new things, and overcome a certain hump of pain. Some things will turn out to be bad ideas, others will work greatly.

Weinberg writes about the concept of a “transforming idea” that “AHA!”-moment where you stand up and say, “I learned something.” Weinberg describes that “just as the foreign element marks the beginning of chaos, the transforming idea marks its end.” When you had your transforming idea, you start to practice over and over to become even better at what you were doing. Of course, all along this process, you might find yourself facing the foreign element that your transforming idea was not that transforming in the end, does not scale, or leads to sub-optimal results. Then you might fall back into the chaos stage, and start to try new things. You might also find yourself getting back to the Old-Status-Quo. But a change to a higher potential of productivity needs the transforming idea and a certain time of practicing it. The transformation and the practicing turns a “good idea” into a great one. “here is where we can create an environment to perfect a good idea, or reject one that turns out to be bad – rather than demanding immediate perfection.”

Reflecting back on Kanban, it’s mandatory to establish a pull system that will create just enough slack-time to perfect your good idea, or reject it. The pull system creates the environment that helps you perfect the transforming idea, or play around with it enough to be able to reject it.

New Status Quo

At the end of the integration and practice stage stands a new stage of comfy feelings, where your new predictions will work. We will have reached a new comfort zone, a new status quo. Of course, just until you realize the next foreign element, and the cycle starts anew.

Conclusion

As you can see, Kanban makes use of the Satir Change Model a lot. Its practices and principles help to deal with foreign elements. For example, I left out the discussion on the Kaizen culture – a culture of small changes. Kaizen helps to cope more easily with foreign elements – foreign elements that are small enough though. It does not prevent you from Kaikaku – larger changes – when you start to realize larger foreign elements.

Since it was shortly before Christmas, I put a wish on twitter last week:

Anyone who wants to give me a gift for x-mas, consider writing a programming language where “if (* == true)” results in a compiler error.

This inspired some ideas on the twittersphere, and I decided to bring this topic to the Hamburg Software Craftsmanship user group on last Tuesday. Here’s what we brainstormed together: The best programming language, ever.

I need to elaborate a bit on some of them.

Disclaimer: Don’t hate me, I’m just a messenger.

if (foo == true)

I hate looking at code like this:

if (foo == true)

This really should be simpler than that:

if (foo)

There are also more convoluted examples of this. I dare not to mention them. As far as I would say, this should be rejected from the compiler.

else

else

is really ugly. I don’t know why to use this to start with. If you can’t hold, use a guard clause, and deal with the else path directly. It will make you happier. Oh, and don’t care about the “single exit from function” paradigm. Only people led astray talk about such non-sense. else is worse.

foo ? whenTrue() : whenNot()

Really, like else before, stop using this crap. You no longer work on 80 x 25 screens, do you? Well, sorry, if you do. But The tenary operator is merely a bad replacement for a conditional with an else. Stop using it. Period.

if – else – if – else

Vertical code is even worse. I think there should be a check on the cyclomatic complexity during compilation time, rejecting code that has a deeper level than 5. Right, maybe such a language won’t become mainstream, but then again, maybe we shouldn’t hire mainstream programmers to start with.

throw null

Yeah, really. That works – or maybe worked a while ago. I didn’t check with later versions of Java. I think Nat Pryce made me aware of this. It ends up in a NullPointerException when the Java exception handler tries to print the stacktrace.

i++ + ++i

For all those friends of C/C++-style languages, this might give you a headache, since the results may vary from language to language, and sometimes even from compiler to compiler (depending on the optimization level you enable).

switch (true)

Yeah, I heard this the first time. NEVER USE THIS!

switch (true) {
case a:
  // code when a is true
case b:
  // code when b is true
case c:
  // code when c is true
default:
  // "else"
}

Assignments in conditions

while (b = readLine() {

Really? Wtf! No one should write such low-level code nowadays anyways. Stop it, please.

Stuff we couldn’t agree on

There were other stuff that we couldn’t agree on like the never ending vi vs. emacs debate (emacs ftw!). This included checked exceptions, curly braces, and other stuff which seemed to matter for one language only (mostly PHP or Java). Take a closer look on the picture above for these. They are marked with x’s.

So, did I get my gift? Unfortunately not. But maybe someone will dare to build such a language for me – one day. What’s you favorite hated language feature?

A few weeks ago I started writing a book about agile tools. It’s a Leanpub book called Hands-on Agile. Right now, there is not much content. My idea is, to incrementally fill the book with the tools I blogged about.

So today, I’d like to introduce the first tool, the Chess Clock.

Intent

Capture the time each pair programmer spent in the driver’s seat

Motivation

Pair programming can be quite a challenge. When introduced poorly, you will not have the benefits it could offer or at least not as many. The senior developer in the driver’s role might be typing all the time, while the less experienced navigator does not have a clue what the other is typing and maybe started playing with his phone already. The knowledge transfer would be little to zero. The beginner’s mind effect would also not be there.

How it Works

Buy one chess clock per pair. But wait. Isn’t there an app for that? Yes, there is. I still recommend using a real clock. That way, you can easily press the time button when switching roles.

That’s about it. Reset the clock. From now on, whoever starts typing also starts his clock first. After the session is over, e.g. 90 minutes later, have a short five minute retrospective about the session. Check how long each developer was typing and use that information as an input. I don’t think it should be the goal to always have equal time for everyone. For me, the chess clock just helps to make certain information transparent – the time everybody was typing. What you do with that information is another story.

Related Tools

Pairing Matrix: Use the chess clock in combination with a pairing matrix to effectively introduce pair programming.

What next?

Found this post interesting? Maybe you even know some cool tool I should write about? Let me know and get involved in shaping the content of the book!