(Nicht so sehr) Lean Untersuchung der Lean-Prinzipien

Zunaechst sei angemerkt, dass die "Lean-Prinzipien" schon eine etwas längere Geschichte haben als die sogenannten "agilen".

Auserdem sind sie ursprünglich in Japan entwickelt worden, und die "Übersetzungen" geben oft (und können oder wollen es auch nicht) nicht wirklich die assozierte japanische Mentalität wieder, ...nur die "Techniken".

"Unfortunately, there are almost as many definitions for Lean as there are authors on the subject."

Wahrscheinlich aus diesen Gründen gibt es eine Vielzahl von Ausprägungen der Lean Prinzipien. Daraus hat man dann, um es bunter zu machen, die "Lean-Prinzipien-für-die-SW-Entwicklung" abgeschrieben, abgeleitet von den Lean Prinzipien fuer die Produktion. Daraus ist auch die SW-Entwicklungsmethode entstanden: "Kanban" gennt. Die neueste Methode, die zurzeit Teams anwenden, nachdem sie mit Scrum nicht weiter kamen. Gerade sind sie dabei herauszufinden, dass sie mit Kanban auch nicht wirklich besser werden :-)

Woran liegt es?
Natürlich habe ich nicht die Antwort, letztendlich habe ich nicht die Weissheit mit Löffeln verspeist. Ich gucke nur. Und lese. Und untersuche. Und nachdenke.
Erklärungsideen hätte ich schon.
Die werde ich bei entsprechender Reife hier aufschreiben.

Nun zu den Prinzipien.

Die sieben Prinzipien der Lean-Entwicklung:

1. Verschwendung vermeiden (siehe weiter unten)
2. Feedback einfordern (alle Teilnehmer einbeziehen - Kommunikation intensivieren)
3. Spät entscheiden (sich so viel Zeit wie möglich nehmen: zum Denken und zum Planen)
4. Schnell ausliefern (so schnell wie möglich die Entwicklung durchziehen, nachdem "entschieden" wurde)
5. Team trägt Verantwortung (impliziert Selbst-Organisation...)
6. "Integrität einbauen" ("stets" standardisieren, so wie ich es verstanden habe)
7. Die Gesamtheit optimieren (Den gesamten Prozess verbessern)

Andere "Übersetzungen" postulieren:

• Die Arbeiten gleich beim 1. Mal richtig machen (inhaltlich zum 1. Punkt: keine Verschwendung)
• Den Arbeitern erlauben, Entscheidungen zu treffen (nicht nur "ganze Teams" sondern auch auf persönlicher Ebene)
• Stets verbessern (inhaltlich zum 7. Punkt)
• Lernen unterstützen (entfernt verwand mit dem 2. Punkt...)

Und hier die 7 Verschwendungen der SW-Entwicklung:

• Überproduktion (Zusätzliche Funktionalität)
• Inventur (Administration / Anforderungen)
• Zusätzliche Produktionsschritte (Komplexität / Überfluss)
• Bewegungen (Suche von Informationen)
• Fehler (Bugs / Fehler in der SW / Tools mit )
• Wartezeiten (Warten auf Entscheidungen / Warten auf Kunden-Feedback)
• Transport (Schnittstellen / Workflow der Arbeit)

Hier die japanischen Begriffe für Verschwendung:

- Muda: die übliche Übersetzung von Verschwendung, gemeint ist aber die Arbeit ohne Mehrwert (so wie die Steuer: Keine Mehrwert für den Konsumenten ;-) )
- Mura: Bedeutet "unstetigkeit", hierunter versteht man die Unterschiede des Arbeitsaufkommens
- Muri: Bedeutet "überlastung"; bei diesem Begriff kann man auch "unlogik" oder "unvernunft" verstehen.


Meinen "Senf" dazu?Tja... ich kann keinen Denkfehler sehen.
Man kann sich sicherlich streiten, ob der eine oder andere Punkt von der Reihenfolge an der richtigen Stelle steht, ...
Ebenfalls kann man sich streiten, ob vielleicht manche Punkte nicht anders ausgedruckt werden sollte (je nach Betonung), ...
Auch ob es 6, 7 oder 8 Prinzipien bzw. Verschwendungen sein sollten kann man ausdiskutieren.
Doch, in Großen und Ganzen macht das Sinn und es ist eine vernünftige Arbeitsbasis um Prozesse bzw. Projekte zu optimieren.

Warum Scrum abbrennen soll (eine Übersetzung)

Why Scrum Should Basically Just Die In A Fire (hier nur ein Abzug)

Von: http://gilesbowkett.blogspot.de/2014/09/why-scrum-should-basically-just-die-in.html

(Ich empfehle das Original zu lesen!)

The Agile Manifesto might also be to blame for the Scrum standup. It states that "the most efficient and effective method of conveying information to and within a development team is face-to-face conversation." In fairness to the manifesto's authors, it was written in 2001, and at that time git log did not yet exist. However, in light of today's toolset for distributed collaboration, it's another completely implausible assertion, and even back in 2001 you had to kind of pretend you'd never heard of Linux if you really wanted it to make sense.

Well-written text very often trumps face-to-face communication. You can refer to well-written text later, instead of relying on your memory. You can't produce well-written text unless you think carefully. Also, technically speaking, you can literally never produce good code in the first place unless you produce well-written text. [...]

In fact, GitHub itself was built without face-to-face communication. Basecamp was built without face-to-face communication as well. I'm not saying these people never met each other, but most of the work was done remote.  [...]. And face-to-face communication plays a minimal role in the majority of open source projects, which usually outperform commercial projects in terms of software quality.

In addition to defying logic and available evidence, both these Agile Manifesto principles (1) encourage a kind of babysitting mentality. I've never seen Scrum-like frameworks for transmuting the work of designers, marketers, or accountants into cartoonish oversimplifications like story points.

Übersetzung (des Abzuges)

Das Agile Manifesto widerspricht auch die Standup des Scrum . Es besagt, dass "die effizienteste und effektivste Methode der Übermittlung von Informationen zu und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch". Um fair zu den Autoren zu sein muss man hier bemerken, dass dieses wurde im Jahr 2001 geschrieben, und zu dieser Zeit gab es noch kein git log. Bei den heutigen Tools, die für die verteilte Zusammenarbeit existieren, es diese Behauptung recht unglaubwürdig, und eben auch im Jahr 2001; musste man doch annehmen, die Autoren haben nie etwas von Linux gehört, wenn Sie wirklich richtig liegen sollten.

Ein gut geschriebener Text ist oft einfach besser als ein persönliches Gespräch. Ein Text kann jederzeit nachgelesen werden, anstatt dass man sich auf das eigene Gedächtnis verlässt. Man kann auch ein Text nicht schreiben ohne (genau) zu wissen, was man wirklich äußern will. Technisch gesehen, man kann auch nicht gut programmieren wenn man nicht richtig schreiben kann. [...]

Richtig ist es, dass GitHub selbst ohne persönliche Gespräche entwickelt wurde. Das Gleiche gilt für Basecamp. Ich behaupte nicht, das die Entwickler sich nie getroffen haben, doch die meiste Arbeit wurde aus der "Ferne" getan. [...]. Ebenfalls spielen persönliche Gespräche in den meisten Open-Source-Projekte eine untergeordnete Rolle. Und Open-Source-Projekte übertreffen in der Regel, in Bezug auf die Qualität der SW, kommerzielle Projekte.

Nich nur dass diese beide "agilen" Prinzipien (1) vorhandene Beweise und einfache Logik trotzen, sondern dass sie auch eine Art Kindergarten-Mentalität fördern. Ich habe noch nie gesehen, dass man Scrum bei Design, Buchhaltung oder Ein- und Verkauf benutzt: oberflächliche, Bilderbuch-ähnliche Vereinfachungen, wie die Sache mit den "Story Points" (Bewertung der 'Geschichten').


(1)
Als 2. Prinzip ist gemeint:
"business people and developers must work together."
Zu deutsch:
'Geschäftsleute und Entwickler müssen zusammenarbeiten.'

Die 1. angesprochene Prinzip war:
'die effizienteste und effektivste Methode der Übermittlung von Informationen zu und innerhalb eines Entwicklungsteams ist ein persönliches Gespräch'.

Agile Prinzipien: Schwammig. Schwach. Lahm.

From: http://www.agilemanifesto.org/principles.html
Principles behind the Agile Manifesto

We follow these principles:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

4. Business people and developers must work together daily throughout the project.

5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

7. Working software is the primary measure of progress.

8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

9. Continuous attention to technical excellence and good design enhances agility.

10. Simplicity -the art of maximizing the amount of work not done- is essential.

11. The best architectures, requirements, and designs emerge from self-organizing teams.

12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Mein Senf dazu:

Zu 1. Gut und wichtig ist es, den Kunden stets glauben zu lassen, man will sie zufriedenstellen. Ansonsten ist der Punkt eher schwammiges Wunschdenken.

Zu 2. Mehrarbeit zu begruessen zeugt eher von schwacher Denkweise. Es soll gelten: Aenderungen zu minimieren. Das soll auch der Kunde beherzigen. Je eher die Anforderungsaenderungen erscheinen desto besser, man soll diese ergo verlangen, ASAP, doch nicht "auch spaet im Projekt diese willkommen heiszen".

Zu 3. Schwacher Punkt. Es ist wichtig, dass das Ergebnis funktioniert, und zwar so gut wie moeglich. Das die SW lange vor Ende des Projekts "arbeitet", und auch diese (so) oft (wie moeglich) zu liefern... das kann kein wirkliches Ziel sein. Ziel ist das Endergebnis. Und darauf sollte man fokusieren.

Zu 4. Die Entwickler taeglich mit Meetings (oder was auch immer eine Zusammenarbeit bedeutet) mit "Business People" wuerde den Entwickler eher zu sehr ablenken, belasten. Eine enge Zusammenarbeit ist erwuenscht, doch "taeglich" ist uebertrieben. Die "Business People" sollen dem Entwickler jederzeit zur Verfuegung stehen. Nicht mehr und nicht weniger. "Taeglich" etwas zu erzwingen ist irgendwie besonders unflexibel.

Zu 5. Gute Idee. Ist das aber eine exklusive Eigenschaft des "Agilen" Entwickelns, oder eher eine allgemeine gute Idee ...?

Zu 6. Aber auch nicht immer. Ausnahmen existieren. Ich halte solche allgemenine generalisierneden Aussagen, fuerwahr, fuer eher unflexibel. Die Punkte 5 bis 7 sind eher allgemeine gute Praktiken, wurden aber sicher nicht von den Autoren des "agilen Manifests" "erfunden".

Zu 7. Es kommt darauf an, wie man "Fortschritt" definiert. Und was man genau messen will. Komplexitaet, z.B. -in Bezug auf Fortschritt-, sollte man anders messen. Diese Aussage ist in meinen Augen auch eher zu allgemen. Dieser Punkt auch eher unflexibel.

Zu 8. These ohne Beweis. Nur solange die Entwickler bezahlt werden, werden sie auch entwickeln. Ausserdem muessten die Entwickler auch die Taetigkeit als sinnvoll erachten. Diese Voraussetzungen basieren nicht auf "agilen Prinzipien".

Zu 9. Scheinbar waren die Schreiber des Manifests ab Punkt 8 schon etwas muede. Schoene Woerter, zusammenhaltslos aneinadergereiht. Nicht nur, dass die Folgerung, wie hier beschrieben, nicht ersichtlich ist; sondern vielmehr lassen sich zahlreiche Gegenbeispiele zu dieser Aussage finden.

Zu 10. Einfachheit ist schon (sehr) wichtig. Doch "essential" ? Na ja. Ausserdem ist "Einfachheit" ganz sicher nicht "die Kunst, die nicht verrichtete Arbeit zu maximieren". Im Gegenteil; oft muss man mehr Arbeit verrichten und ein System einfacher zu gestalten.

Zu 11. Ich halte dieses Prinzip auch wieder fuer schwach im Sinne des Denkens: Gute Architekturen werden von guten Architekten entwickelt. Gute Anforderungen werden von guten Requirement-Engineers geschrieben. Gutes Design wiederum von guten Designers erstellt. Diese Arbeiten haben mit einem Team eher wenig zu tun. Ziemlich egal wie sehr sich das Team "selbst organisiert".

Zu 12. Gutes Prinzip. Sehr gut sogar (richtung Kaizen). Doch... eine Exklusivitaet von agilen Teams...? Zweifle ich stark.

Mein Fazit zu dem Manifest:

Inhaltslos: Punkte 1, 5 und 9.
Unflexibel: Punkte 4, 6 und 7.
Folgerung unlogisch: Punkte 8 und 9.
Falsch: Punkte 2, 10 und 11.

Auch hier (wie bei http://www.agilemanifesto.org) sollte man stark (zum Besseren) ueberarbeiten.
Vom urspruenglichen Manifest wird wahrscheinlich kaum etwas uebrig bleiben.

To be done. Bei mir. Im Laufe dieses Jahres.
 :-)

Agile heilige Kühe in Indien...

Frage: Warum sind die Inder so stark vertreten seit einigen Jahren (seit der Einführung der "agilen" Methoden) bei der Entwicklung von Software?

Antwort: Weil bei der Software-Entwicklung so viele heiligen Kühe gibt!

Wie "Agil" ist eigentlich "Agil"? Was kann man damit anfangen?

From: http://www.agilemanifesto.org

Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:
1- Individuals and interactions over processes and tools
2- Working software over comprehensive documentation
3- Customer collaboration over contract negotiation
4- Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.


Meine Gedanken zu den "Werten" des Manifestes:

1- Also, "agil" sind Individuen ohne Tools die wilde Interaktionen ohne wesentliche Prozessorientierung zu tun pflegen.

2- Das Ergebnis wird dann nicht unoft: "Unmaintable SW and uncomprehensive documentation". Also für die Katz, die Entwicklung...

3- Echt super, die Kunden werden geradezu ermuntert, ständig Änderungen und neue Funktionalitäten zu fördern!

4- Alles Andere als zielorientiert...

Daraus folgt, aus meiner Sicht: Das "Manifesto" ist noch nicht richtig anwendbar, ca 80% müsste noch korrekt überarbeitet werden.

Dazu, zu lesen (wenngleich nicht besonders informativ, sondern eher Gelaber/Textguss ohne wertvollem Inhalt): http://ronjeffries.com/xprog/articles/beyond-agile-new-principles/

Meetings ohne Vorbereitung sind etwas fuer Unorganisierte

Es ist mir klar, dass ich schon radikale Meinungen habe... :-)
Ich moechte ein bisschen hier an dieser Stelle mein Hintergrund ansprechen, das koennte helfen, so hoffe ich jedenfalls, solche radikale Ansichten nachzuvollziehen.

1. Ich bin nun mal Deutscher (trotz oder gerade weil ich im Ausland aufgewachsen bin: ich bin naemlich in einem Deutschen Haushalt aufgewachsen, mit Deutscher Kultur. Ich bin von der Propaganda der Nachkriegszeit in Deutschland nicht in uebermass beeinflusst worden). Und als Deutscher  versuche ich auch immer alles richtig zu machen (deswegen vielleicht arbeite ich auch in erster Linie bei der Qualitaetssicherung).

2. Ich habe Mathematik studiert. Mathe ist doch ein Fach fuer Faule (bitte beachten Sie diese Aussage ganz genau!), fuer Leute die, wie ich, es vorziehen 5 Male zu denken bevor sie etwas tun, dafuer aber richtig. Mathematiker sind Menschen, welche die ganze Zeit versuchen Prozesse zu optimieren, Vorgaenge zu verbessern. Nicht, wie ein lieber Freund von mir behaupten wuerde, weil wir "Gutmenschen" sind, nein; aus Faulheit!

Aus diesem Hintergrund heraus wird es fuer jedermann/jedefrau so weit nachvollziehbar, hoffe ich zumindest, warum ich so denke wie ich denke.

Beschreibung des Ist-Zustandes: Es ist doch so, dass Vorgesetzte mit wenig Ahnung sehr schnell bei der Sache sind, Meetings aufzurufen. Meetings werden also vorgetragen von Personen mit wenig (oder gar keine) Vorbereitung und besucht von Menschen, die oft genug das vermeintlich erteilte Wissen von Meetings ueberhaupt nicht brauchen.
Damit sind Meeting Zeitfresser der uebelsten Sorte:
1. Es gibt Leute (keine Mathematiker ;-) die durch Meetings das Gefuehl kriegen, viel "gemacht" zu haben (mit kaum eine/eigene Anstrengung)
2. Meetings fressen Zeit von Menschen, die das zu ermittelnde Wissen brauchen, es aber unstrukturiert und unvollstaendig durch unvorbereitete Vortrage erhalten (sollen)
3. Fressen Zeit von Menschen, die nur ein Teil (wenn ueberhaupt) der Vortrages brauchen.

Hier einige eigene Gedanken, um Meetings ein Mindestmass an Nutzen einzuhauchen.

Check-Liste zur Verbesserung von Meetings
1. Vorbereiten: Ziel; Was genau ermittelt werden soll
2. Benoetigte Zeit genau festlegen (Zielzeit)
3. Vorbereitung der Teilnehmer (!) Stoff im Vorwege zusenden und Fragen den Teilnehmer vorbereiten lassen (und diesen Punkt hier ist der "Kasus Knaktus")
4. Am Besten die Fragen von Punkt 3. den Vortragenden mitteilen
5. Nacharbeit: Zusammenfassung des Vortrages mit FAQs an alle Teilnehmer zusenden
6. Bei jeder Teilnehmer definieren, warum er/sie teil nehmen soll (sonst keine Teilnahme!)

Es gibt natuerlich Meetings die wichtig sind, z.B. wenn eine Gruppe Designer und Entwickler Teile einer SW definieren muessen. Da hilft natuerlich die Check-Liste sehr, zwecks Definition, was genau das Ergebnis sein soll.

Ich kann mir schon vorstellen, dass ca 90 bis 95 % aller Meetings zwar notwendig sind, doch die Zeit kann man sicherlich halbieren: Ein einstuendiger Meeting kann in 10 Minuten gehalten werden, dazu kommen 15 Minuten Vorbereitung plus 5 Minuten Nacharbeit.

Nachtrag: 37Signals, eine Firma mit der ich keinerlei geschaeftlichen Verbindungen habe, teilt aber meine Meinung ueber Meetings (sie schreibt: Meetings are toxic).

Der Untergang des Titanics aus der Perspektive eines Qualitaetssicherers

Der Fall "Titanic" ist laengst untersucht in allen Einzelheiten.
Also mache ich es kurz nur mit einigen Gedanken aus der Perspektive der Qualitaetssicherung.

Welche waren die Ursachen fuer das Unglueck?
Warum mussten Menschen sterben?
Ganz knapp sind 2 Tatsachen dafuer zu nennen:
1. Das Schiff fuhr zu schnell
2. Es gab nicht genug Rettungsboote fuer alle Passagiere

Und... Warum war das Schif zu schnell?
War der Kapitaen leichtsinnig?
Es war doch seine letzte Fahrt. Alt genug war er also und Erfahrung soll man ihm nicht absprechen. Und schnell soll er gewesen sein weil er einen neuen Rekord aufstellen wollte. So wird es zumindest berichtet. Glauben soll man es nicht unbedingt (wo so viele Sachen, die berichtet werden, oft -sehr oft- gelogen oder bestenfalls erfunden sind). Doch Leichtsinn moechte ich ihm (aufgrund seines Berufslebens) nicht bescheinigen. Warum war er dann zu schnell?
Und warum gab es fuer alle Passagiere nicht genug Rettungsboote?
Auch leichtsinn?
Ja...
Eine Antwort die zu beide Fragen passt und noch dazu schoen geschichtlich belegt ist, ist die, dass das Schiff als unsinkbar galt.
Wenn man oft genug eine idiotische Aussage hoert, dann glaubt man am Ende langsam daran.
Sogar ein alter Kapitaen scheint daran geglaubt zu haben. Er haette es besser wissen, naemlich: Alles sinkt, wenn der Schaden bloss gross genug ist.
Alles. Holz- und Metalschiffe. Einruempfige und mehrruempfige Schiffe, alles.
Wenn der Glaube, dass das Schiff "unsinkbar" war, die Grundlage fuer den Leichtsinn zu gelten hat, dann wuerde ich behaupten, dass die Qualitaetssicherung ganz miserabel gegenueber der Werbung und den Slogansmachern versagt hat.
Die ernuechtende Qualitaetssicherung-Aussage "Alles sinkt wenn der Schaden gross genug ist" wurde ausser Acht gelassen, verdraengt durch die (falsche aber werbewirksame) Aussage "unser Schiff sinkt nicht". Und alle Menschen scheinen es geglaubt zu haben. Auch die, die das eigene Leben aufs Spiel gesetzt haben.

Heutzutage gibt es mehr Regel und Gesetze, Schiffe muessen genug Rettungsboote fuer alle haben. So etwas kann eigentlich nicht mehr vorkommen.
Doch das Problem liegt, meiner Ansicht nach, daran, dass Werbeslogans mehr "gewicht" haben als nuechterndes Ingenieurwissen... schlimmer noch, sie haben mehr gewicht sogar als jahrelanges Berufswissen oder gar schlichter Vernunft.
Oder liegt es eher daran, dass ueber die Werbung nicht nachgedacht wird?
Oder daran, dass, wenn eine Aussage oft genug wiederholt wird, diese geglaubt wird, ohne nachzudenken?
Und, was damals geschah, kann sich doch jederzeit wiederholen.
Nur weil man nicht ueberlegt...
Qualitaetssichern bedeutet ueberlegen. Haette doch damals geholfen, denke ich.