Donnerstag, 31. August 2017

Kommentierte Links (XXVIII)

Grafik: Pixabay / Geralt - Lizenz

Tendayi Viki: Lessons From Kodak’s Bankruptcy - How Can Large Companies Sustain Innovation?

Direkt zu Beginn dieses Textes wird die Tragik des Untergangs von Kodak auf den Punkt gebracht: die Firma ging nicht nur unter weil ihre Erzeugnisse durch den technischen Wandel obsolet wurden, sie hatte diesen Wandel selbst begonnen, wollte dann aber doch nicht auf ihre traditionellen Erfolgsprodukte verzichten. Tendayi Viki geht davon aus, dass ein solches Management-Verhalten seinen Ursprung in einer falschen Ausbildung der Manager an den Universitäten und in den Firmen hat, wo vermittelt wird, dass eine Fokussierung auf ein einziges Geschäftsfeld sinnvoll ist. Sein Gegenvorschlag besteht darin bis zu 30 % der Ressourcen auf neue und disruptive Geschäftsmodelle mit noch unklaren Erfolgschancen zu verwenden und diese möglichst früh validierbar zu machen. Klingt gut, es bleibt aber die Frage wie das mit kurzfristigen Shareholder-Interessen in Einklang zu bringen sein wird.

Ron Jeffries: Business Agile - Built Upon Sand

Ob Business Agility und agiles Projektmanagement wirklich neue Trends sind und ob sie grundsätzlich das Risiko in sich tragen die eigentliche Agilität mit zu viel Prozessen einzuengen würde ich hinterfragen. Ron Jeffries hat aber Recht damit, dass es eine spürbare Tendenz gibt agile Transformationen als rein organisatorische Vorhaben zu sehen und die technischen Implikationen auszublenden. Bei vielen Managern gibt es den Irrglauben, dass eine zweitägige Zertifizierung oder eine zweiwöchige Begleitung durch einen Coach ausreichen um ein Team "agil zu machen". In meiner Erfahrung sind eher mehrere Monate nötig, aber das muss erstmal jemand bezahlen wollen. Wobei klar ist - wer eine billige Transition will zahlt meistens drauf.

Jurgen Appelo: Frameworks are like Radio Stations

Da Jurgen Appelo zur Zeit an einem Framework-unabhängigen Methodenbaukasten arbeitet sind seine in letzter Zeit zunehmenden Äusserungen über die Starrheit und Unflexibilität dieser Frameworks mit Vorsicht zu betrachten. Einen zutreffenden Kern haben sie aber, hier werden Freiheiten und Optionen bewusst durch Leitplanken eingegrenzt. Ich bin auch bereit zu hinterfragen ob agile Teams diese Leitplanken wirklich brauchen, erfahrungsgemäß ist das oft nicht der Fall. Wenn aber auf der anderen Seite unerfahrene Teams versuchen die Methoden anzupassen endet das sehr oft in Verschlimmbesserungen. Harikiri, wie ich es nenne. Frameworks haben ihren Sinn, man muss ihn sich nur bewusst machen statt ihnen kritiklos zu folgen.

Urs Enzler: Problem-Centric User Stories

Einer der klassischen Fehler die man bei User Stories machen kann ist, dass bereits Lösungen beschrieben werden statt der Bedürfnisse des Benutzers oder des Kunden. Übertroffen wird das gelegentlich noch durch die Beschreibung von Bearbeitungsschritten ("Als Sachbearbeiter möchte ich auf einen Knopf drücken ..."). Der Lösungsansatz von Urs Enzler ist der Richtige, da er das Erarbeiten der Lösung beim Team lässt. Die Voraussetzung dafür ist allerdings, dass in dem auch wirkliche Software-Entwickler sitzen und nicht nur Coding Monkeys. (siehe auch: "As a User" needs to stop).

James Gadsby Peet: Scaling Autonomous Teams

Mit ihrer Aussage "It's all about Business Agility" gibt Debbie Wren scheinbar eine Gegenthese zu Ron Jeffries (weiter oben) ab. Wo sie wieder mit ihm zusammenkommt: um das zu erreichen ist (unter anderem) "technische Agilität" notwendig. Erst das, in Kombination mit Autonomie und Empowerment, macht Business Agility möglich.

Montag, 28. August 2017

Die verlorene agile Disziplin - Domain Driven Design (DDD)

Vor einiger Zeit gehörte Christoph Baudson zu einem Entwicklungsteam das ich coachen durfte. Deshalb freut es mich um so mehr, dass ich heute auf ihn, bzw. seinen Vortrag auf der Froscon 2017 verlinken kann.



Auch jenseits persönlicher Sympathie ist das Video sehenswert, da DDD in der Tat relativ selten diskutiert wird. Und wie Christoph richtig sagt: man muss es nicht als Konkurrenz zu Frameworks wie Scrum sehen sondern als mögliche Ergänzung.

Donnerstag, 24. August 2017

Warum Konzerne nicht versuchen sollten agil zu werden

Bild: Max Pixel / Freegreatpicture - CC0 1.0
Im Vergleich zu kleineren Unternehmen tun sich Konzerne häufig besonders schwer wenn es darum geht agile Vorgehensmodelle einzuführen. Dabei fehlt es meistens nicht am Willen, zumindest nicht an dem des Managements. Gemeinsam um einen langen Konferenztisch sitzend schaut man sich tief in die Augen und versichert sich gegenseitig "Wir werden Agil", tritt vor die Belegschaft und spricht auf Kickoff-Veranstaltungen um die Botschaft hinauszutragen in das eigene Unternehmen. Die Mitarbeiter verstehen, sie haben den Auftrag Agil zu werden. Die Umsetzung beginnt. Und dann passiert das genaue Gegenteil.

Das Problem in vielen Organisationen ist, dass sie ein falsches Verständnis von Agilität haben. Agilität wird gleichgesetzt mit den Rollen und Meetings von Scrum, SAFe und Spotify. Gibt es in den IT-Teams statt Teamleitern Scrum Master? Check. In den Fachabteilungen statt Business Analysten Product Owner? Check. Der Statusbericht heisst jetzt Daily Standup? Check. Die Architektur- und QA-Teams heissen jetzt Gilden? Check. Das Problem: hinter den neuen Rollen, Personen und Strukturen bestehen die alte Kultur und die alten Mindsets weiter. Das bloße Einführen neuer Organisationsstrukturen ändert gar nichts.

Was hier passiert ist nichts anderes als eine Umkehrung von Mittel und Zweck. Eigentlich sind agile Methoden nur ein Mittel um den Kulturwandel zu stützen und zu befördern, der Voraussetzung ist um den eigentlichen Zweck zu erreichen: kurze Time to Market, hohe Reaktionsgeschwindigkeit, Vermeidung sinnloser Arbeit. Nur dafür wurden die Frameworks, Rollen und Events erfunden und nur wenn sie darauf ausgerichtet sind machen sie Sinn. Wenn sie stattdessen als Selbstzweck eingeführt werden ist dieser nicht mehr gegeben. Einen Product Owner zu benennen nur damit er da ist bringt niemandem etwas.

Dass es trotzdem immer wieder vorkommt liegt daran, dass die meisten großen Unternehmen sich mit "weichen" Begriffen wie Kulturwandel oder Mindset-Weiterentwicklung extrem schwer tun. Nach Jahrzehnten der "Optimierung" durch zahllose Unternehmensberatungen greift fast überall der Reflex, dass sofort alles gemessen, gezählt und anhand dieser Zahlen kontrolliert werden muss. Und im Fall einer Agile- oder Scrum-Einführung ist das erste im Wortsinn Zählbare das man findet die Anzahl der Teams die schon die neuen Rollen und Meetings haben. Die alte Kultur formt die agilen Vorgehensmodelle auf diese Weise wieder in Command & Control um.

Um diese Zustände zurück auf die Füße zu bringen kann es sinnvoll sein die Begrifflichkeiten der Agilität fallenzulassen (und damit aus dem Focus der "Zähl- und Mess-Fetischisten" zu nehmen) und den eigentlichen Zweck wieder in den Mittelpunkt zu stellen. Wenn kurze Time to Market, hohe Reaktionsgeschwindigkeit und Vermeidung sinnloser Arbeit erreicht werden sollen, dann kann man das auch so benennen. Und die dahinführenden Maßnahmen werden automatisch die sein müssen die man aus Scrum & Co kennt: Nähe zum Kunden, flache Hierarchien, schlanke Prozesse und Automatisierung sich wiederholender Tätigkeiten. An dieser Stelle angekommen kann die Zähl- und Mess-Fixierung sogar wieder zum Vorteil werden - die Erkennung und Messung von Lead Times, Cycle Times und Reaktionszeiten ist genau das was man für die (von Natur aus datengetriebenen) agilen Vorgehensmodelle braucht.

Am Ende ist es fast ein Paradoxon. Sich das Ziel zu setzen Agil zu werden führt viele Konzerne in eine Sackgasse. Auf diese Bezeichnung zu verzichten kann Agilität dagegen fördern.

Montag, 21. August 2017

Team-Urlaub für einen Sprint

Bild: Pixabay / Walkerssk - Lizenz
Als Agile Coach besuche ich bei einem meiner Kunden in unregelmässigen Abständen die Scrum Teams bei ihren Sprintwechseln. Auch letzte Woche war es wieder soweit, allerdings nur in kleinster Runde - neben dem Product Owner waren nur ein Entwickler und ein Business Analyst anwesend, das restliche Team (den Scrum Master eingeschlossen) befand sich in den Sommerferien. Naheliegenderweise war das auch das Thema der Retrospektive: wie kann unter solchen Bedingungen noch ein geregelter Arbeitsbetrieb aufrechterhalten werden?

Diese Frage dürfte bei so gut wie jedem Scrum Team regelmässig auftreten, und das nicht nur im August sondern in allen üblichen Ferienzeiten, z.B. Ende Dezember. Jedesmal wenn sich ein Teil der Teammitglieder für einige Tage oder Wochen verabschiedet fehlen Erfahrungswerte, unerwartete Mehraufwände fallen schwerer ins Gewicht und Arbeitstechniken wie Pair Programming oder Code Reviews können ggf. gar nicht mehr angewandt werden, weil wie im gerade genannten Beispiel nur ein Entwickler übrig ist.

Ein Lösungsansatz den ich bei einem anderen Kunden gesehen habe war, dass ein Team sich entschieden hat geschlossen in den Urlaub zu gehen, und zwar für genau einen Sprint. Nach der Retrospektive des Sprints davor gingen alle in ihre Ferien. Nach der Rückkehr gab es ein kurzes Backlog Refinement um sicherzustellen, dass sich in der Zwischenzeit nichts Neues ergeben hatte, danach ging der normale Rhythmus mit einem Planning wieder los.

Der Vorteil dieses Vorgehens war, dass die oben genannten negativen Effekte auf diese Art vermieden werden konnten. Statt mehrere Sprints mit ausgedünnter Personaldecke zu haben war das Team mit Ausnahme dieser zwei Wochen durchgehend voll besetzt, der "Urlaubssprint" wurde in der Sprintplanung ignoriert und auch in der Berechnung der Velocity nicht berücksichtigt. Dass das Review ausfallen würde wurde den Stakeholdern rechtzeitig vorher mitgeteilt.

Was dieses Vorgehen in diesem Fall begünstigt hat war eine besondere Rahmenbedingung: das Team war Teil eines Tribes, so dass andere Teams einspringen konnten wenn Bugfixing- oder Support-Aufgaben zu erledigen waren. In Konstellationen in denen das nicht der Fall ist müsste man über Ausgleichsmaßnahmen nachdenken. Eine die ich an anderer Stelle miterlebt habe war z.B. die, dass ein Team-Mitglied sich bereiterklärt hat seinen Urlaub später zu nehmen. Während des Urlaubssprints arbeitete er aber in einem anderen Team mit, wodurch die Auswirkungen der Ferienzeit auch dort abgeschwächt wurden.

Donnerstag, 17. August 2017

Scaled Agile: Chapter (Querschnitts-Organisationen)

Bild: Flickr / iMorpheus - CC BY 2.0
Die Verwendung des englischen Begriffs "Chapter" für eine Untergruppe einer größeren Organisation ist in Deutschland noch immer ungewöhnlich, sie kommt vor allem im Zusammenhang mit Rocker-Clubs wie den Hells Angels oder den Bandidos vor. Im englischen Sprachraum ist er dagegen viel normaler und wird für Gruppen jeglicher Art verwandt. Auch im Kontext agiler Skalierung ist er in Mode gekommen und bezeichnet hier in der Regel eine Querschnittsorganisation zur Koordination verschiedener Entwicklungsteams.

Genau wie der Begriff des Tribes ist der des Chapters durch den Skalierungsansatz der Firma Spotify bekanntgeworden, wo diese beiden Konzepte auch in Verbindung miteinander stehen. Ein Tribe ist dort eine Gruppe von Teams die an einem gemeinsamen (Teil)Produkt arbeiten, weshalb sie durch gegenseitige technische und fachliche Abhängigkeiten verbunden sind. Um sich nicht gegenseitig zu behindern ist eine Koordination zwischen diesen Teams nötig. Da der klassische Lösungsweg (die Einsetzung eines koordinierenden Managers) zu Hierarchien und Flaschenhälsen führen würde, wurde ein anderer Ansatz entwickelt, die Chapter.

In einem Chapter sind aus allen beteiligten Teams die Verantwortlichen für jeweils ein Spezialgebiet zusammengefasst. Häufig sind das Frontend, Backend und QA, es sind aber auch andere Konstellationen möglich, z.B. UX oder SEO. Zusammen haben sie die Aufgabe an übergreifenden Architekturen und gemeinsamen Standards und Tools zu arbeiten. Im Grunde eine ausdifferenzierte Version eines Scrum of Scrums, gewissermassen mit jeweils einem davon für jedes Spezialgebiet. Über Frequenz und Intensität der gegenseitigen Abstimmung entscheidet jedes Chapter dabei selbst.

Was ein Chapter ausserdem noch von einem Scrum of Scrums unterscheidet ist die Rolle des "Chapter Lead". Sie wird von einem der beteiligten Entwickler in Teilzeit ausgeübt und übernimmt das was von den klassischen Management-Tätigkeiten übrigbleibt: Personalentwicklung/Coaching, Gehaltsverhandlungen, Koordination des Recruitings, etc. Explizit nicht zu ihren Aufgaben gehört dagegen das Entscheiden fachlicher und technischer Konflikte oder das Vorgeben von Architekturen und Standards.

Wenn andere Organisationen versuchen Spotify zu kopieren ist die Rolle des Chapter Lead eine häufige Bruchstelle an der Probleme auftreten. Oft wird sie mit Personen besetzt die vorher Manager, Teamleiter, Architekt oder Lead Developer waren und sich aus ihrer alten, weisungsbefugten Rolle nur schwer lösen können. In solchen Fällen kann die helfende oder hemmende Begleitung durch einen Scrum Master oder Agile Coach Sinn machen.

Montag, 14. August 2017

Organizations that are fit for the Future

Das Internet hält offensichtlich einen nie versiegenden Nachschub mitreißender Redner bereit. Die neueste Entdeckung ist Gary Hamel, der sich das Thema der zukunftsfähigen Organisationen zu eigen gemacht hat:



Wie viele professionelle Konferenzredner ist er nicht nur rhetorisch brilliant sondern verfügt auch über das Wissen wie man gute, den Vortrag unterstützende und trotzdem nicht ablenkende Powerpoint-Präsentationen erstellt. Und sein ab Minute 07.40 vorgestelltes Beispiel von "Reverse Accountability" in einer indischen Firma ist wirklich inspirierend.

[Edit: das ursprüngliche Video wurde gelöscht, stattdessen ist jetzt ein inhaltlich ähnliches eingebunden]

Donnerstag, 10. August 2017

Why agile: Feature-Wettrennen

Bild: Pixabay / Macayran - Lizenz
Zu agiler Softwareentwicklung in der Lage zu sein kann vor allem für Firmen in umkämpften Märkten Vorteile bringen. Kurze Time to Market, schlanke Prozesse und schnelle Feedbackzyklen sind zwar eigentlich immer erstebenswert, besonders aber in einer Situation: wenn mehrere Unternehmen vergleichbare Produkte entwickeln und sich dabei einen Wettlauf um neue Features liefern. Jede der beteiligten Firmen versucht Kunden zu gewinnen und an sich zu binden indem sie zum Einen alle Funktionen der Konkurrenz kopiert und zum Anderen das eigene Produkt immer schneller weiterentwickelt, um so dauerhaft einen Vorsprung zu haben. Um konkurrenzfähig zu bleiben müssen die anderen mitziehen, und so geht es weiter und weiter, bin einer nicht mehr mithalten kann und aufgeben muss.

Die beiden Firmen die diese Vorgehensweise am weitesten perfektioniert haben dürften vermutlich Facebook und Google sein, die sich bereits mehrere solche Wettläufe geliefert haben. Facebook hat einen solchen im Jahr 2009 sowohl gegen Twitter als auch gegen StudiVZ gewonnen und führt im Augenblick einen gegen Snapchat. Google hat alle anderen Suchmaschinen (Altavista, Yahoo, Lycos, Ask, Bing, etc.) weit hinter sich gelassen und 2009 seinen Landkartendienst gegen Apple um die Wette entwickelt. Der aktuelle Wettstreit findet gegen ein Unternehmen namens Pinterest statt, das im Nischenmarkt der Bildersuche und -kuratierung ein Konkurrent ist. Beide Firmen arbeiten zeitgleich an Bilderkennung und Schnittstellen, wodurch z.B. Kuchenbilder sowohl mit ähnlichen Aufnahmen als auch mit Rezepten verknüpft werden können.

Pinterest vs. Google

Auf lange Sicht bedenklich ist, dass die beiden Großunternehmen durch ihre Fähigkeit Feature-Wettrennen zu gewinnen praktisch jede neue Konkurrenz marginalisieren können. Selbst disruptive Technologien und Ideen bringen wenig wenn ein bereits etablierter Wettbewerber sie in kürzester Zeit kopieren und in sein Produkt einbauen kann. Auf der anderen Seite kann man gespannt sein ob der ständige Nachbau von Konkurrenzprodukten nicht irgendwann zu überladenen Funktionsumfängen und Codebases führen wird. Die wiederum wären für Agilität hinderlich.

Montag, 7. August 2017

Diversität

Bild: pxhere - CC0 1.0
Der Sturm der in den letzten Tagen durch das Wasserglas der Tech-Industrie gegangen ist drehte sich um die Firma Google, genauer gesagt um deren Maßnahmen zur Diversitätsförderung. In einem kontroversen und viralen Diskussionsbeitrag wurden diese von einem Mitarbeiter in Frage gestellt, da sie aus seiner Sicht zwar gut gemeint aber schlecht umgesetzt sind [Edit: Da ich es anscheinend nicht deutlich genug formuliert habe - nein, ich teile diese Meinung dieses Herrn nicht]. Selbst in diesem Beitrag wird Diversität aber als etwas grundsätzlich Notwendiges betrachtet, eine Sicht der Dinge die immer populärer wird. Es stellt sich die Frage - warum ist das so? Warum ist Diversität unter den Mitarbeitern etwas Erstrebenswertes? Und bringt sie einem Unternehmen wirklich einen Mehrwert? Ja, das tut sie, und zwar aus mehreren Gründen.

Zunächst deshalb, weil diverse Teams in der Regel eine größere Vielfalt an möglichen Innovations- oder Lösungsoptionen erarbeiten können. Entgegen einer häufigen Annahme allerdings nicht weil Diversität das befördert sondern weil Gleichartigkeit das behindert. Je homogener eine Gruppe ist, desto einmütiger denkt sie und verhält sie sich. Dieses Phänomen, das so genannte Group Think, wird durch diverse Teams aufgebrochen.

Als Zweites kommt ein wirtschaftlicher Aspekt dazu. In Zeiten des Fachkräftemangels ist es nahezu fahrlässig wenn weite Teile der Bevölkerung einem Segment des Arbeitsmarktes nicht zur Verfügung stehen. Man muss dazu nicht nach Kalifornien blicken, es reicht ein Blick in eine Maschinenbau-, IT- oder Buchhaltungsabteilung eines beliebigen deutschen Unternehmens. Frauen und Gastarbeiter-Kinder sind hier sehr, sehr, selten. Angesichts zahlloser unbesetzter Stellen ist das ein Zustand den zu ändern sich lohnen würde.

Zuletzt kann Diversität zu einer besseren (weil ausgeglicheneren) Firmenkultur führen. Es ist ein tiefer Griff in die Klischee-Kiste, aber rein männliche Teams neigen häufig zu einer gewissen Ruppigkeit im Umgang, Teams aus älteren Mitarbeitern hinterfragen Routinen seltener und rein deutsche Teams sind tendenziell weniger sensibel gegenüber kulturellen und religiösen Befindlichkeiten ausländischer Mitarbeiter (und Kunden). In diversen Teams ist all das meistens besser.

Natürlich ist Diversität nicht die Wunderlösung für alles, die gibt es nicht. Gerade in agil arbeitenden Unternehmen, solchen also in denen Offenheit und Anpassungsfähigkeit eminent wichtig sind, ist sie ein wichtiger Baustein für Erfolg und Wettbewerbsfähigkeit. Dass man damit auch Kontroversen auslösen kann zeigt das oben genannte Beispiel Google [Edit: Siehe dazu auch diesen Beitrag in der Zeit, diesen aus der FAZ oder diesen aus der New York Times]. Allerdings ist davon auszugehen, dass sich auch hier mittels Inspect & Adapt eine Lösung finden lassen wird.

Samstag, 5. August 2017

lean-agility.de

Bild: Flickr / Chris Dlugoz - CC BY 2.0
Eine Nachricht aus dem Maschinenraum: da sich in der letzter Zeit die Beschwerden über die schwer zu merkende Blogspot-URL dieser Website gehäuft haben hat jetzt ein Umzug stattgefunden. Die neue URL ist http://www.lean-agility.de und hoffentlich einfacher im Gedächtnis zu behalten.

Die bisherige Blogspot-URL besteht immer noch, leitet aber auf die neue Web-Adresse weiter. Es ist also nicht nötig gesetzte Links anzupassen, sie sollten weiterhin funktionieren.

Zusammen mit der URL wurde auch der Seitenname angepasst, er hat jetzt mehr Bezug zu den hier behandelten Themen. Auch das ist ja von Zeit zu Zeit kritisiert worden.

Soviel dazu, Maschinenraum Ende.

Donnerstag, 3. August 2017

Make Rules Explicit


Manchmal ergeben sich die spannendsten Diskussionen dort wo man sie am wenigsten erwarten würde. Im Rahmen eines Kanban-Workshop bei einem Kunden gab es den größten Gesprächsbedarf zu dem Grundsatz, dass alle Regeln unzweideutig formuliert werden müssen. Eigentlich eine Selbstverständlichkeit - bevor eine Organisation ihre Prozesse optimieren kann müssen alle ihre Mitglieder das selbe Verständnis haben wie diese Prozesse überhaupt aussehen, sonst versuchen verschiedene Personen "in verschiedene Richtungen zu optimieren", was selten gut geht.

In diesem Fall ergab sich allerdings an dieser Stelle starker Widerspruch. Es wäre Best Practice und seit je her üblich, dass Regeln "hinreichend unscharf"formuliert sein müssten. Nur dadurch könne man sicher sein, im Zweifel nicht unnötig in der eigenen Entscheidungsfreiheit eingeengt zu werden. In der Vergangenheit habe es zwar immer wieder Versuche gegeben die Regeln zu verschärfen, das sei aber immer wieder an der Realität gescheitert. Damit jetzt wieder anzufangen wäre unnötig und kontraproduktiv.

Ein Blick in die firmeninternen Regelwerke zeigte deutlich was mit "hinreichend unscharf" gemeint war. Immer wieder tauchten Einschränkungen oder Verallgemeinerungen auf, wie etwa "so weit wie möglich", "falls machbar", den üblichen Standards entsprechend", "erfahrungsbasiert" oder "je nach Erfordernis". Letztendlich hätte man sich die kompletten Dokumente sparen können, unterschwellig zog sich durch alle die Aussage "jeder macht was er will und keiner fragt genau nach".

Nach längerer Diskussion schälte sich langsam die wirkliche Begründung dieses Zustands heraus. Ohne diese Relativierungen und Verallgemeinerungen wären die Vorgaben einfach nicht erfüllbar gewesen. An einer Stelle liefen sie beispielsweise darauf hinaus, dass die Übergabe neu programmierter Features an die nächste Abteilung erst erfolgen durfte wenn die Auswirkungen ihrer Integration in das Altsystem klar waren. Das Problem - Integrationstests fanden erst noch später in der Prozesskette statt, die Auswirkungen konnte also noch niemand wissen.

Das unzweideutig machen der Regeln (das dann doch beschlossen wurde) führte in diesem Fall zu der für viele schockierenden Erkenntnis, dass ein Großteil der eigenen Prozesse aufgrund ihrer eigenen Widersprüchlichkeit gar nicht funktionieren konnte. Als logischer nächster Schritt wurde ein Großteil davon gestichen, das übrigens gegen den erbitterten Widerstand des eigenen Qualitätsmanagements. Wie sich herausstellte hatte das seine Aufgabe vor allem darin gesehen den Teams immer härtere Auflagen aufzudrücken ohne sich um deren Umsetzbarkeit zu kümmern.

Dieses wildgewordene Qualitätsmanagement einzufangen ist jetzt die nächste große Herausforderung in diesem Unternehmen. Und dass man sie angeht (und damit einiges verbessert) wäre bei den alten, "hinreichend unscharfen" Formulierungen vermutlich nicht passiert. Das unzweideutig machen der Regeln hat sich bereits ausgezahlt.