Airport-359

Ein Hamburger Buchblog

Prozesssteuerung Mit Kanban - Eine Kurze Einleitung

“Kanban” (aus der Reihe “Pocket Power”) ist ein kurzes Buch über die Steuerung von Prozessen mithilfe des Kanban-Verfahrens.

In der Begriffsklärung heißt es:

Kanban (japanisch 看板, deutsch Karte, Tafel, Beleg) ist eine Methode der selbststeuernden Produktion nach dem Hol- oder Pullprinzip. Der Materialfluss ist hierbei vorwärts gerichtet (vom Erzeuger zum Verbraucher), während der Informationsfluss rückwärts gerichtet ist (vom Verbraucher zum Erzeuger).

Ständige Eingriffe einer zentralen Steuerung sind im Kanban-System überflüssig.

Im Grunde muß man sich ein Produktions-System wie einen Kreislauf vorstellen. An einer Quelle werden benötigte Teile produziert, zum Beispiel Felgen, die für das Fertige Auto bestimmt sind. Die Senke ist ein Lager oder Regal, aus dem sich der Mitarbeiter an der Produktionslinie Felgen besorgen kann, um sie dann ans Auto zu schrauben.

Während der Produktion ist der Betrieb bestrebt die Lagerbestände groß genug zu halten, so dass die Produktion nie zum Stillstand kommt. (Wären keine Felgen mehr vorhanden, dann müsste die gesamte Produktion gestoppt werden, denn ein Auto ohne Räder kann nicht ausgeliefert werden.)

Gleichzeitig will man die Bestände aber so klein wie möglich halten, um unnötige Kapazitäten, zum Beispiel Lagerräume, zu sparen.

Zur Entstehung:

Um im Wettbewerb mit amerikanischen Unternehmen bestehen zu können, begann die Toyota Motor Company in Japan 1947 mit der Entwicklung eines neuen Systems zur Planung und Steuerung der Produktion. Ziele waren die Steigerung der Produktivität und die Senkung der Kosten. Um diese Ziele zu erreichen, wurde von Taicchi Ohno das Toyota-Production-System entwickelt. Bestandteil dieses Systems war die Just-in-Time-Produktion. Damit die benötigten Teile in der benötigten Menge zur benötigten Zeit an der richtigen Stelle ankommen, muss kommuniziert werden. Als Medium zur Informationsübertragung werden Karten (jap. = Kanban) verwendet, die zwischen Verbrauchern und Produzenten pendelten.

Im Auto-Beispiel würde sich das Regal, in dem die Felgen abgelegt sind, kontinuierlich leeren. Irgendwann würde ein Bestand erreicht werden, der eine “Nachbestellung” auslösen soll. Dies sollte früh genug passieren, damit es nie zum Stillstand kommt, aber nicht so früh, dass zu sehr “auf Vorrat” produziert wird.

Denn für die Produktion bestimmter Teile ist oft ein Umrüsten der Maschinen notwendig. Dies kostet Zeit. Die Anzahl und Dauer der Rüstvorgänge sollte daher stets minimiert werden.

Um der “Quelle” zu signalisieren, dass mehr Felgen benötigt werden, kann eben ein Kanban, also eine spezielle Karte, an ein “Kanban-Brett” gehängt werden. Dies ist ein sog. “Signal”.

Aber es gibt auch andere Arten von Signalen. Beispielsweise könnte ein Lagerraum in 4 Zonen A, B, C und D eingeteilt sein. Befindet sich nur noch in Zone D Material, dann muss sofort nachbestellt werden. Stehen nur noch auf D und C Kartons, dann darf man es machen, muss aber nicht. Ansonsten findet keine Bestellung statt.

An Stelle eines Kanban-Bretts oder unterteilter Lagerräume kann man auch Kanban-Regale verwenden, die z.B. Teile-Lager und Kanban-Brett in einem sind.

Bei den Kanban-Behältern handelt es sich um genormte Transportbehälter, die in einem speziellen Regal auf Rollenbahnen gelagert sind. Wird ein Behälter von der Vorderseite des Regals entnommen, rutschen die anderen Behälter durch die Schräglage der Rollenbahnen nach.

Das Buch führt noch weitere Beispiele an, die zumindest ein Gefühl dafür vermitteln, wie die moderne Produktion komplizierter Güter, wie Autos oder Motorräder, (heutzutage: nicht nur in Japan) funktioniert.

Es kann in gut einer Stunde von Anfang bis Ende gelesen werden, was sicherlich auch an den zahlreichen Abbildungen liegt. Vor allem ist es aber die Simplizität des Verfahrens, das das Buch in einem Durchgang lesbar macht.

Eine Sammlung von Berechnungsformeln, etwa die Berechnung der optimalen Lagergröße, gibt Lösungsansätze für konkrete Probleme und Denkanstösse für eine weitere Beschäftigung mit dem Thema Prozessoptimierung.

(Und man wird nach dem Lesen das Gefühl nicht los, dass sowohl die Planung von als auch die Arbeit in einem Kanban-gestützten Verfahren durchaus Spaß machen könnten..)

Agile Softwareentwicklung Mit Scrum

Das erste Buch, das ich vorstellen möchte ist Scrum - kurz und gut von Rolf Dräther, Holger Koschek und Carsten Sahling.

Hintergrund ist, dass ich Programmierer bin, und seit Jahren fast ausschließlich in “agilen” Teams gearbeitet habe. Dabei habe ich Scrum zwar praktisch kennengelernt, aber nie in Form einer (wie auch immer gearteten) formellen Unterweisung.

“Scrum - kurz und gut” ist tatsächlich kurz (und wie sich später rausstellte auch gut), und ich habe spontan beschlossen es zu lesen.

Zur Sache.

Scrum hilft, komplexe Produkte zu entwickeln

Scrum ist ein “leichtgewichtiges Framework für Projektmanagement”. Es formuliert eine Methode, um umfangreiche Produkte in vorhersehbaren Etappen, den sogenannten “Sprints” zum Erfolg zu führen.

Ursprünglich ist es aus der “Agilen Softwareentwicklung” hervorgegangen, weswegen im Buch auch meist von Softwareprojekten die Rede ist.

Es geht darum, das Produkt inkrementell aufzubauen, und am Ende jedes Sprints in der Lage zu sein ein Produkt zu präsentieren, das funktioniert und, theoretisch, einem Kunden in die Hand gegeben werden kann.

Dabei orientiert sich Scrum an 4 Werten:

Fokus (Focus)

Erledige deine Arbeit. Verwende all deine Energie und Erfahrung auf die Aufgabe zu der Du dich verpflichtet hast. Mach dir um alles andere keine Sorgen.

Offenheit (Openness)

Scrum macht alle Informationen über das Projekt für alle sichtbar.

Respekt (Respect)

Individuen sind geprägt durch ihren persönlichen Hintergrund und ihre Erfahrungen. Es ist wichtig, die verschiedenen Menschen zu respektieren, die sich zu einem Team zusammengeschlossen haben.

Mut (Courage)

Habe den Mut, dich einem Ziel zu verpflichten, zu handeln, Offenheit zu zeigen und Respekt zu erwarten.

Ein Scrum Team sollte in der Regel nicht aus mehr als 9 Personen bestehen, wobei folgende drei Rollen definiert und in der Regel auch zu besetzen sind:

Scrum kommt mit einem sehr schlanken Rollenmodell aus. Lediglich drei Rollen werden im Scrum Guide benannt und beschrieben: Der Scrum Master, der Product Owner und das Entwicklungsteam. Diese drei Rollen formen zusammen das Scrum-Team.

Kurz gesagt, spielt der Product Owner denjenigen, der das Produkt nach jedem Sprint (und letztlich am Ende) abnehmen muss. Er definiert die Anforderungen an das fertige Produkt und schreibt grob nieder, wie die Vision aussieht und welche Meilensteine auf dem Weg zu erreichen sind.

Der Scrum-Master kümmert sich um die Umsetzung des Scrum-Verfahrens. Er übernimmt aber auch wichtige organisatorische Rollen und steht, auch auf persönlicher Ebene, dem Team zur Seite.

Die Rolle des Scrum Masters ist die wohl vielschichtigste innerhalb des Scrum-Teams. Sie erfordert ein sehr breites Spektrum an Erfahrungen, Fähigkeiten und Fertigkeiten, das von der Scrum-Expertenrolle bis zu Mediation und persönlichem Coaching reicht. Dennoch wird diese Rolle gern unterschätzt.

Das Entwicklungsteam, last but not least, sind die Leute, die das Produkt tatsächlich herstellen. Also in der Regel die Programmierer, Gestalter, Designer, usw. Dieses Team bricht auch die Meilensteine des Product Owners auf kleinere Tasks runter, die in den Sprints abgearbeitet werden.

Neben den Rollen, definiert Scrum vier Meetings, drei “Artefakte” und eine “Definition of Done”.

Ohne auf die Details einzugehen, sei nur grob erwähnt, dass es vor dem Sprint ein sogenanntes “Sprint Planning”-Meeting gibt, am Ende des Sprints dann ein “Sprint Review”. Außerdem finden regelmäßige “Retrospektiven” statt, in denen das Team zusammen über die Zusammenarbeit reflektiert und in dem es auch rauszufinden gilt, was verbessert werden könnte.

Die Artefakte sind Backlogs und Inkremente, also Listen von Aufgaben, die erfüllt werden müssen, sei es für das Produkt insgesamt (gröbere Meilensteine) oder im aktuellen Sprint (detaillierte Aufgaben). Die “Definition of Done” dient dazu, beurteilen zu können, ob ein “Task” tatsächlich abgeschlossen ist.

Probleme sollen direkt angegangen und nicht verwaltet werden. Entwickler arbeiten nicht parallel an mehreren Dingen, sondern implementieren sequentiell einen Task nach dem anderen.

Die Rollen, Artefakte und Ereignisse von Scrum sind unantastbar. Obwohl es möglich ist, nur Teile von Scrum zu implementieren, ist das Ergebnis nicht Scrum.

Auch wenn man Scrum kennt, lohnt es sich dieses Buch zu lesen, um die Philosophie hinter den Konzepten nachvollziehen zu können. So zitieren die Autoren zum Beispiel zu einem Konzept namens “Shu-Ha-Ri”:

>>In der japanischen Kampfkunst gibt es drei Stufen des Lernens. Shu ist wie >gehorche< - alles wird genau nach Rezept oder >Prozess< ausgeführt und wird zu absoluter Fehlerfreiheit eingeübt. Ha steht für >probiere< - man weicht von der Lehre ab, sammelt Erfahrungen durch Variation und versteht langsam die Kunst an sich. Ri bedeutet >verlasse< - der Meister löst sich von den Formen, den Lerhen und den Stilen seiner Vorbilder und vollendet sich.<<

So ist auch die Arbeit mit Scrum ein fortschreitender Prozess. Insbesondere in den Retrospektiven wird Vergangenes diskutiert, so dass der Prozess schrittweise angepasst werden kann.

Thematisch abgerundet wird das ganze mit ergänzenden Kapiteln, die nicht direkt Scrum behanden, aber im Umfeld angesiedelt sind, wie “Software Craftsmanship”, in denen darüber philosophiert wird, welche Eigenschaften einen guten Softwareentwickler ausmachen - Konzepte wie der persönliche Qualitätsanspruch oder professionelles Handeln stehen dort z.B. im Mittelpunkt.

Das Buch eignet sich zwar für Leute, die Scrum aus der Praxis kennen, aber es richtet sich auch an Skeptiker oder Scrum-Neulinge:

Der Effekt bei der Einführung agiler Methoden ist vergleichbar mit dem Übergang von der prozeduralen zur objektorientierten Programmierung: Sobald man die Prinzipien verstanden und verinnerlicht hat, kann man sich kaum noch vorstellen, je wieder anders zu arbeiten. Das liegt daran, dass es sich bei beiden Konzepten nicht um eine neue Arbeitsweise handelt, sondern vor allem um eine neue Denkweise oder Sicht auf die Welt. Wo der objektorientierte Programmierer eine Welt voller Objekte sieht, betrachtet der agile Entwickler die Welt als komplexes adaptives System und Softwareentwicklung als kollaborative Tätigkeit in interdisziplinären Teams, die von einem gemeinsamen Wertesystem zusammengehalten werden. Um aus einer Organisation eine agile Organisation zu machen, genügt es folglich nicht, das Handeln der Akteure in dieser Organisation zu beeinflussen; man muss die Akteure dazu bewegen, neu zu denken - und das ist ungleich schwieriger.

Ich kann und will in diesem Blogpost nicht auf alle im Buch besprochenen Konzepte eingehen. Aber wo sonst findet man auf rund 200 Seiten eine ganz neue Sichtweise auf das Thema Projektmanagment vermittelt? Vor allem die Ideen hinter den Prozessen sind großartig.

Ein sehr empfehelenswertes Buch, nicht nur für Akteure im Software-Business.

Erster Post

Auf diesem Blog schreibe ich über die Bücher, die ich gelesen habe.

Ich lese relativ viel und mache mir oft auch Notzen dazu. Da liegt es doch nahe, darüber zu bloggen. Ich schreibe hier nur über gute Bücher. Also solche, die mir persönlich gefallen haben oder bei denen ich etwas Interessantes erfahren habe.

Inspiriert hat mich übrigens der Blog Farnam Street. Ich glaube ich kann nie so gut sein wie Shane Parrish (oder so viel lesen wie er), aber ich hoffe ich bin gut genug, dass es zumindest einigen Leuten gefällt.

Es wird wahrscheinlich so sein, dass ich die Affiliate-Links von Amazon verwenden werde. Aber das sollte nicht weiter schlimm sein, da Sie als möglicher Käufer deswegen nicht mehr bezahlen müssen.

Ich hoffe meine kleinen Zusammenfassungen gefallen Ihnen.