Agiles schätzen akademisiert

Ich war gestern auf einem Scrumtisch und da kam wieder mal das liebe Thema schätzen auf. Da bin ich ja kürzlich auch hier drauf eingegangen im Artikel „Schätzen ist wertvoll, Schätzungen sind es nicht“. Das ist ein Satz der da auch wieder viel Anklang gefunden hat. Was ich bei den Gesprächen rund um das schätzen in agilen Kontexten immer wieder feststelle ist, dass jedem wichtig ist genau zu definieren, was denn jetzt ein Story Punkt ist. Also wie komplex, aufwändig, risikobehaftet, … ist denn jetzt genau ein Story Punkt. Oder eben eine kleine, mittlere oder große Story. Das bricht dann immer in eine Diskussion aus, was jetzt genau Komplexität einer Story ist und welche Elemente da zu berücksichtigen sind.

Ganz ganz häufig kommt es dann zu dem Beispiel einer Aufgabe, etwas abzutippen. Wenn das jetzt ein Story-Punkt bekommt, wie sieht es dann mit 100 mal das gleiche abtippen aus? Story-Punkte sollen ja irgendwie auch Komplexität ausdrücken und wirklich komplexer ist die Aufgabe ja nicht. Hört doch bitte einfach auf damit das so zu akademisieren. Ich glaube ein wesentlicher Punkt ist, das wir keinen Namen für das haben, was wir da schätzen. Es ist eben nicht Komplexität im Sinne von Komplexitätstheorie. Da spielen ganz viele Faktoren eine Rolle.

Dabei ist es überhaupt gar nicht wichtig, dass wir eine universell einheitliche Definition von einem Story Punkt oder der Komplexität eines solchen haben. So war agiles Schätzen (= relatives Schätzen) auch überhaupt nie gedacht. Die Schätzungen im agilen Kontext sind eine Lösung für Teams gemeinsam ein Gefühl dafür zu bekommen, wie gut sie eine gewisse Anforderung handhaben können und darüber sprechen zu können. In Scrum, wo das relative Schätzen ja so populär ist, ist es einfach eine Möglichkeit für das Team, vor dem Sprint ein Gefühl davon zu bekommen, ob das was sie sich vornehmen in ein Sprint passt. Die Betonung liegt auf Gefühl. Es sind tendenziell echt komplexe Umgebungen. Sie wissen nicht wirklich ob das passt. Sie wollen nur ihre Erfahrungen abgleichen und nutzen dafür eine Praktik, die wir eben relatives Schätzen nennen.

Es soll ja gerade nicht überlegt werden, wie das genau umzusetzen ist, sondern eben per Gefühl schnell relativ eingeschätzt werden. Das können wir Menschen einigermaßen gut (im Gegensatz zu absoluten Schätzungen). Wenn wir jetzt diese Zahlen akademisieren und versuchen logisch zu begründen, führen wir das mit dem Gefühl ja ad absurdum. Dann müssen sich die Leute auch wieder für ihr Gefühl rechtfertigen. So ist der nicht gedacht.

Bitte überlasst den Teams selbst, was genau alles in ihre Schätzungen einfließt. Wenn sie damit häufig daneben liegen, haben sie dann ja die Möglichkeit aus dieser Erfahrung zu lernen und das dann anzupassen. Vorsichtig musst du nur sein, wenn sie absolut statt relativ schätzen, denn da wissen wir halt, dass das nicht funktioniert – nur das ist ein anderes Thema.

Das Team und „wichtig, nicht dringend“

Gestern habe ich schon angefangen von der zweistündigen Gruppensitzung zu erzählen, die ich jede Woche mit meinen Mitarbeitern mache. Oft stoße ich auch bei anderen Führungskräfte auf großes Unverständnis, wenn die das mitbekommen, oder ich davon erzähle. „Den Luxus möchte ich mal haben, dass wir uns zwei Stunden rausziehen können“, „Habt ihr nichts besseres zu tun?“, „Wir gehen hier unter in Arbeit und ihr macht Kaffeekränzchen“. Wenn die dann auch noch mitbekommen, dass wir da auch Spiele spielen (Serious Games), ist es ganz vorbei.

Doch hier sind wir wieder an einer ähnlichen Stelle, an der ich schon bei dem Artikel über Führung ohne operative Tätigkeiten war. Das ist für mich eine Frage der Prioritäten. Zwei Stunden pro Woche sind fünf Prozent der Arbeitszeit. Wenn ich mir nicht einmal das bisschen an Zeit nehme, um mich nachhaltig um grundlegende Themen zu kümmern, wie soll das denn dann dauerhaft funktionieren? Gerade dadurch dass wir uns diese Zeit nehmen, werden wir immer effektiver und schaffen immer mehr.

Unter anderem mit der Gruppensitzung stelle ich sicher, dass sich die Gruppe um wichtige Themen kümmert, die (noch) nicht dringend sind. Denn die Gefahr ist ja sonst, dass immer nur das erledigt wird, was gerade am lautesten schreit (dringend und vielleicht gar nicht wichtig). Das läuft dann häufig auf dieses schöne Sinnbild des Schäfers hinaus, der den ganzen Tag seine Schafe einfangen muss, weil er keinen Zaun hat. Auf die Frage, warum er keinen Zaun baut, antwortet er, dass er dazu nicht kommt, weil er ja die Schafe einfangen muss.

Ehrlich gesagt finde ich auch die fünf Prozent das absolute Minimum und das ist nur das, was wir als Gruppe gemeinsam machen. Daraus resultieren immer auch wichtige Aufgaben, die wir alle dann parallel zu der operativen Tätigkeit erledigen, so dass insgesamt deutlich mehr als die fünf Prozent gemacht werden. Wir reden hier von einer Gruppe von Informatikern. Wir brauchen auch Zeit um uns kontinuierlich fortzubilden, kontinuierlich die Prozesse zu verbessern, kontinuierlich die technischen Grundlagen zu verbessern, kontinuierlich technische Schulden abzubauen, usw. Wenn wir das nicht tun, schadet uns das mittel- und langfristig und das können wir überall sehen, wo das wegen des operativen dringenden Geschäfts vernachlässigt wurde. Das können wir uns auch nicht leisten. Da müssen wir jetzt noch viel mehr Zeit investieren, um das wieder aufzuholen, was wir da verpasst haben.

Wie ist es bei dir? Nimmst du und nehmt ihr euch genug Zeit für die wichtigen, (noch) nicht dringenden Aufgaben? Oder rennt ihr immer nur den dringenden Aufgaben hinterher und geht unter, weil die grundlegenden Themen nicht gelöst werden? Schreib es in die Kommentare!

Zwei Stunden Gruppensitzung

Eine der ersten Handlungen als ich Gruppenleiter wurde war, einen Serientermin für eine Gruppensitzung zu erstellen. Jede Woche, zwei Stunden, mit allen zusammen. Die Kollegen waren etwas verwundert, was sollen wir denn zwei Stunden machen. Das ist sicher nur damit der Raum geblockt ist, falls wir mal länger brauchen. Natürlich kam auch auf, dass das zu viel Zeit von der eigentlichen Arbeit wegnimmt.

Sie haben festgestellt, dass ich das sehr ernst meine. Neben den aktuellen Themen der Gruppe, der IT-Abteilung und des Unternehmens habe ich die restliche Zeit immer mit Fortbildung gefüllt und wir sind fast nie vor Ende der zwei Stunden fertig gewesen. Natürlich stelle ich mich nicht nur da vorne hin und laber. Die Kollegen haben eine ganze Reihe von SeriousGaming Elementen kennengelernt und durften die theoretischen Modelle direkt in die Praxis umsetzen. Wir haben iterativ Papierflugzeuge gebaut, Kommunikationsprobleme zwischen Abteilungen mit dem ChairGame transparent gemacht, Spaghetti-Marshmallow-Türme gebaut im Zusammenhang mit Problemen im Projektmanagement und vieles mehr. Mit Spaß lernt es sich leichter.

Immer wieder mal, kommt der Effekt, dass einzelne Mitarbeiter vor der Gruppensitzung versuchen, irgendwie darum herumzukommen, weil die operative Arbeit gerade lauter schreit und dann sind zwei Stunden doch eben viel Zeit. Die Arbeit erledigt sich nicht von allein. Naja, das Ergebnis ist immer, dass sie dann doch hingehen und nachher total froh sind, dass sie das nicht verpasst haben. In der Hektik des Alltags übersehen wir häufig, wie wichtig es ist, sich Zeit zu nehmen für die wichtigen Dinge, die (noch) nicht dringend sind (Eisenhower-Matrix). Da gehört fast alles zu, was wir in der Gruppensitzung machen. Klärung zukünftiger Themen, Reflektion, Fortbildung, …

Leider sind die 10 Minuten wieder um, dabei gibt es dazu noch so viel zu sagen. Bis morgen, oder eben bis zum nächsten 10 Minuten Artikel: Das Team und „wichtig, nicht dringend“.

Agile Produktentwicklung und der Projektplan

Eine Stelle an der die klassische Organisation auf die agilen Grundgedanken prallt ist immer wieder die Planbarkeit. Nein es gibt keinen Projektplan im klassischen Sinne. Das Produkt wird ja gerade agil entwickelt, weil es komplex ist und nicht vorhergesagt werden kann. Darauf bin ich kürzlich schon im Artikel Projekt-Wahrsagen näher eingegangen. Doch wie gehen die Mitarbeiter jetzt damit um? Ihnen ist klar, dass ein Projektplan kein Sinn macht. Nur gibt es da eben noch eine Organisation mit Portfolio-Management und Lenkungsausschüssen usw. die jetzt einen Meilensteinplan oder ein Gantt-Chart oder so haben wollen.

Eine Lösung die ich leider öfter mal sehe ist, dass der Product Owner tatsächlich die gewünschten Artefakte erstellt, im Zweifelsfall indem er irgendwelche Termine und Inhalte erfindet. Damit verletzt er natürlich elementar die agilen Grundwerte. Es entstehen Erwartungshaltungen gegenüber dem gesamten Team, die nicht erfüllt werden können. Auch dem Product Owner wird es längerfristig schaden, da seine Pläne halt immer falsch sind. Er handelt natürlich in der besten Absicht und weiß nicht, was er sonst tun soll. Schließlich muss den Befehlen der Hierarchen gefolgt werden und er erstellt die Pläne nach dem besten Wissen und Gewissen, basierend auf dem aktuellen Stand.

Das Product Backlog ist im agilen Kontext sowas ähnliches wie ein Projektplan, nur eben mit dem Fokus auf das Produkt – im Gegensatz zum klassischen Projektplan, der sich auf die Tätigkeiten der Teammitglieder fokussiert (siehe auch Projekt- oder Produktentwicklung). Agile Entwicklung ist ja nicht chaotisch, weil es kein Projektplan gibt, sondern die Planung funktioniert einfach elementar anders. So haben die Elemente des Product Backlogs eine fest definierte Reihenfolge, an der sich das Team in der Umsetzung orientiert. Also so eine Art Plan, welche Themen als nächstes behandelt werden sollen. Kombiniert mit der bekannten Entwicklungsgeschwindigkeit des Teams lassen sich auch einige gute Abschätzungen für die nähere Zukunft machen.

Auch die Organisation muss sich an den agilen Kontext anpassen. Sie muss lernen, dass im agilen Kontext der Fokus auf das Produkt und den Nutzen gelegt wird und nicht auf einen Projektplan und Vorhersagen.

Wann ist Selbstorganisation gut?

In meinem letzten Artikel zum richtigen Führungsstil habe ich Beispiele dafür gegeben, wann Selbstorganisation nicht geeignet ist. Jetzt will ich näher darauf eingehen, warum dann alle von Selbstorganisation sprechen oder das anstreben. Der wesentliche Punkt dabei ist die gewachsene Komplexität. Früher gab es sehr viele Aufgaben, bei denen es eine oder ein paar gute Lösungen gab. Die Probleme waren also nur einfach oder höchstens kompliziert und wenn einer wusste wie es geht, konnte er dies als Best Practices weitergeben. Da gibt es dann auch nicht viel zu diskutieren, denn es sind ja schon beste Lösungen.

In den komplexen Umgebungen die wir heute häufig vorfinden, können wir nicht im Voraus wissen, was die Beste Lösung ist. Da bin ich etwas genauer drauf eingegangen in dem Artikel Projekt-Wahrsagen. Das heißt, Erfahrung ist hier hilfreich und doch werden wir erst im Nachhinein sehen, warum etwas gut funktioniert oder eben nicht gut funktioniert hat. Nur wie kommen wir jetzt zu der Entscheidung, welchen Ansatz wir wählen, welches Experiment wir machen? Das hat eben doch ganz viel mit Erfahrung und Bauchgefühl zu tun.

Genau da liegt die Stärke der Selbstorganisation. Während bei Führungsmodellen mit einem Chef davon ausgegangen wird, dass dieser es am besten kann und deshalb vorgehen kann, funktioniert diese Vorannahme in komplexen Umgebungen nicht mehr. Die Führungskraft hat dann nur einen Satz von Erfahrungen und nur ein Bauchgefühl. In der Selbstorganisation hingegen wird die Erfahrung und das Bauchgefühl aller Teammitglieder genutzt. Ein wesentliches Element, um in komplexen Umgebungen erfolgreich zu sein, wird also durch die Selbstorganisation massiv verstärkt. Dieses Prinzip wird dann weiter unterstützt von dem Commitment der einzelnen Teammitglieder.

Während autoritäre Führung in komplexen Umgebungen nicht gut funktioniert, geht es andersrum schon. Selbstorganisation funktioniert auch gut bei komplizierten Problemen. Deshalb ist es heutzutage tendenziell gut sich an der Selbstorganisation zu orientieren, wenn es nicht klar einfache oder chaotische Umgebungen sind. Es ist nur wichtig sich dann der Nachteile der Selbstorganisation in diesem Umfeld klar zu werden. So entsteht ein deutlicher Mehraufwand für Kommunikation, Entscheidungen, Abstimmungen und überhaupt der ganzen Organisation. Es gibt ja nicht nur einfach einer vor. Natürlich kann man auch hier einen Vorteil drin sehen, da dieses Vorgehen gleichzeitig zur Mitarbeitermotivation und -bindung beitragen kann. Es hat eben alles Vor- und Nachteile.

Der richtige Führungsstil

Es gibt die unterschiedlichsten Arten zu Führen. Salopp formuliert hier mal ein paar die mir einfallen: Autoritär, mit Beteiligung, auf Kumpelbasis, Selbstorganisiert, Chef als Koordinator und Chef als Coach. Welcher Stil ist denn der richtige? Immer wieder höre ich in der heutigen Zeit Aussagen in der Richtung, das Selbstorganisation das Richtige sei. Ist ja modern und agil (das Wort taucht sogar im Manifest auf). Dabei ist das überhaupt nicht der Fall und es hängt auch von vielen Faktoren ab.

Im absoluten Katastrophenfall, also z.B. eine Explosion im Zivilgebiet, herrscht sofort Chaos. Wenn jetzt die Feuerwehr kommt und selbstorganisiert helfen will, wird das nichts werden. Es herrscht Chaos. Menschen handeln Irrational und in Panik. Der einzige uns bekannte Führungsstil den wir kennen der hier funktioniert ist der autoritäre Stil. Jemand trifft Entscheidungen und alle folgen. Auch derjenige weiß natürlich nicht was das richtige ist. Nur versucht er mithilfe seiner Erfahrung zu handeln und die Situation unter Kontrolle zu bekommen. Also weg vom Chaos und hin zu einfacheren Problemen.

Ähnlich ist es bei ganz einfachen Aufgaben. Die Lagermitarbeiter bei Amazon übernehmen im wesentlichen die Arbeit, die eine Maschine nicht machen kann, weil die Variation zu groß ist. Die Mitarbeiter bekommen also von der Maschine genau gesagt, was sie tun sollen. „Stell das Paket vor dir in das Regalfach 3B, rechts neben dir.“ Diese Mitarbeiter können sich nicht selbstorganisieren, da sie Teil der Maschine sind und es wäre schlecht, wenn sie anfangen zu diskutieren: „Ich denke es wäre besser das in 4D abzulegen“. Gut wäre hier natürlich, wenn die Mitarbeiter Feedback geben dürfen, um den Prozess zu verbessern, usw. Solange der Prozess im Gang ist, müssen sie diesen jedoch genau befolgen.

Leider sind die 10 Minuten schon fast um. Wir sehen bis hierhin schon, dass es nicht den einen richtigen Führungsstil für alle geben kann, sondern der Kontext eine entscheidende Rolle spielt. Morgen gucken wir uns dann an, wo die Selbstorganisation ihre Stärken hat.

Schätzen ist wertvoll, Schätzungen sind es nicht

Ich bin tendenziell für #NoEstimates, also keine Schätzungen zu benutzen und gleichzeitig ich bin dafür im Team zu schätzen. Wie passt das zusammen? Schätzen ist ein total wichtiger Vorgang, nur eben nicht für das Ergebnis. Was machen wir denn beim Schätzen? Wir klären, worum es überhaupt geht und stellen damit ein gemeinsames Verständnis her. Auch das schätzen der Komplexität oder des Aufwands sorgt für ein gemeinsames Verständnis, da über große Abweichungen der Schätzungen der einzelnen Teammitglieder gesprochen wird. Damit werden häufig Vorannahmen und Missverständnisse aufgedeckt. Das alles ist wesentlich zur Auftragsklärung und trägt zur erfolgreichen Umsetzung bei.

Schätzungen hingegen sind dann nicht mehr wertvoll. Sie werden meist dazu genutzt, das Team festzunageln und jemand verantwortlich zu machen, wenn die Schätzung daneben lag. Dabei wissen wir aus so vielen Untersuchungen (Cone of Uncertainty, Link zu Wikipedia), dass wir Menschen einfach nicht gut schätzen können. Das relative Schätzen aus dem agilen Kontext ist da schon wesentlich besser und auch da ist es eben nur eine Schätzung. Da wir für gewöhnlich über komplexe Umgebungen sprechen, können wir die Zukunft nicht voraussagen, egal wie lange wir analysieren und diskutieren. Erst wenn die Aufgabe erledigt haben, wissen wir, wieso das Alles wie zustande gekommen ist.

Natürlich ist das alles nicht so Schwarz-Weiß. Das Team weiß natürlich, was es in etwa geschätzt hat und kann im Nachhinein feststellen, ob sie grob daneben lagen. Für sie kann das hilfreich sein, um mithilfe von Erfahrung etwas besser zu werden im Schätzen. Außerdem hilft es grundsätzlich dem Product Owner bei der Priorisierung. Nur hier reden wir definitiv über so Schätzungen der Größenordnung klein, mittel, groß, mega groß. Dafür braucht es dann keine Schätzungen im Sinne von Zahlen und es reicht das Bauchgefühl des Teams vollkommen aus.

Wie siehst du das? Hast du gute oder schlechte Erfahrungen mit Schätzungen gemacht? Schreib es in die Kommentare!

Führung ohne operative Tätigkeiten

Ich bin im Konzern auch immer wieder deshalb aufgefallen, weil ich mich nicht über meine Fachtätigkeiten als Entwickler profiliert habe. Als Gruppenleiter habe ich konsequent nicht mit entwickelt. Meine Ansicht dazu ist ganz einfach: Jede Minute die ich mit Entwicklung verbringe, ist eine Minute, in denen ich meine Mitarbeiter nicht unterstützen kann. Es ist meine Aufgabe, dafür zu sorgen, dass mein Entwicklungsteam so effektiv wie möglich ist. Dazu räume ich Probleme aus dem Weg, helfe den Kollegen sich zu entwickeln, coache und berate sie bezüglich diverser Themen, kurzum: Ich bin für sie da und das ist mir wichtig.

Jetzt muss ich vielleicht dazu sagen, dass die Gruppe von der ich hier rede aus 12 festangestellten Mitarbeitern, einem dualen Studenten und 4 Externen Mitarbeitern besteht. Die Führungsspanne ist also auch nicht gerade klein. Meiner Meinung nach sogar viel zu groß. Ich finde 8 Mitarbeiter ist eine gute Größe für eine Führungskraft. 12 Mitarbeiter sollte das äußerste Maximum sein. Natürlich hängt die Menge des operativen Geschäfts durch die Führungskraft auch von der Führungsspanne ab. Bei nur 3 Mitarbeitern, erwarte ich natürlich, dass auch der Chef operativ mitarbeitet.

Immer wieder höre ich von Führungskräften, die operativ mitarbeiten, dass sie Probleme haben, weil sie keine Zeit finden, sich (ausreichend) um ihre Mitarbeiter zu kümmern. Die Arbeitslast sei einfach zu groß. Das ist ein ganz wichtiger und spannender Punkt, denn in der Aussage steckt eine Priorität: Die operative Tätigkeit ist wichtiger, als die Führungsaufgabe. Da steckt für mich der Knackpunkt. Die Prioritäten sind grundlegend falsch gesetzt.

Ja natürlich muss die Arbeit fertig werden. Nur was passiert denn mithilfe dieser Priorität auf Dauer? Der Chef rennt einem Problem nach dem anderen hinterher, damit die Arbeit fertig wird. Die Mitarbeiter werden dadurch nicht effektiver, im Gegenteil. Es besteht eine massive Gefahr von Demotivation der Mitarbeiter. Dadurch verschlimmert sich das Problem nur noch und es beginnt eine Abwärtsspirale. Am Ende sieht natürlich auch die Führungskraft die Probleme mit der Führung und dass die Mitarbeiter Aufmerksamkeit brauchen. Nur da sind ja längst alle im Überlebensmodus und wollen nicht unter der Arbeitslast zusammenbrechen.

Selbstorganisation: Urlaub

Eine der ersten Themen, bei denen ich mit meinen Mitarbeitern in Richtung Selbstorganisation gegangen bin, war das Thema Urlaub. Wir haben vereinbart, dass grundsätzlich jeder selbstständig entscheiden kann, wann er Urlaub nimmt. Er muss selbst verantworten können, dass er nicht da ist und durch das Team muss sichergestellt sein, dass im Notfall jemand erreichbar ist, der sich um die Themen kümmern kann.

Das ging etwa ein Jahr lang ziemlich reibungslos, weil sich zufällig ergeben hat, dass immer alles gepasst hat. Letztes Jahr dann kam der Fall zustande: Fast alle wollten die Brückentage rund um Weihnachten und Neujahr als Urlaub nehmen und damit wäre die zweite Regel verletzt, dass jemand da sein muss. Das Team hat dann selbstorganisiert das Thema aufgegriffen und gemeinsam eine gute Lösung erarbeitet. Die bedeutete allerdings auch, dass es Leute gab, die zumindest einen der Brückentage da sein mussten. Alle waren überzeugt, dass es die beste Lösung für alle ist und gleichzeitig war natürlich auch ein bisschen Frust da für diejenigen, die dann zur Arbeit kommen mussten.

Darauf aufbauend haben sie sofort selbstständig einen Prozess etabliert, um die kritischen Tagen im Jahr (insbesondere Brückentage) weit im Voraus urlaubstechnisch zu klären. Damit kann dieser Konflikt in Zukunft vermieden werden. Gleichzeitig ist es ein Prozess, den das Team selbst geschaffen hat und entsprechend committed ist.

Ich finde das ist ein tolles Beispiel dafür, wie in ganz einfachen Dingen einfach mal Selbstorganisation ausprobiert werden kann. Natürlich funktioniert das bei dir nicht, wenn da eh schon Stress auf dem Thema Urlaub ist. Das ist bei uns halt nicht der Fall. Dann nimm ein anderes einfaches Thema, wo das Team Erfahrungen in der Selbstorganisation sammeln kann. Ähnlich habe ich es z.B. mit dem Thema Log-Überwachung gemacht.

Hast du ähnliche Erfahrungen beim Start der Selbstorganisation gemacht? Was fallen dir noch für Themen ein, mit denen das Team das mal ausprobieren kann? Schreib es in die Kommentare!

Angebote statt Vorgaben

In vielen klassischen Unternehmen gibt es Mitarbeiter und Gruppen, die dafür zuständig sind, zentrale Vorgaben zu machen. Vorgaben zur Architektur, zum zu verwendenden Ticket-System, zum Release-Prozess, usw. Das Problem dabei ist, dass diese zentralen Vorgaben natürlich nie 100% auf alle passen. Es gibt immer wieder Fälle, in denen diese Vorgaben die Mitarbeiter unnötig beschränken. Faktisch wird dann sehr viel Energie darauf aufgewendet, um diese Beschränkungen herumzuarbeiten und es entsteht häufig sehr viel mehr Aufwand dadurch. Das ist einer der Gründe, warum das agile Manifest das Wertepaar „Individuen und Interaktionen mehr als Prozesse und Werkzeuge“ hat.

Jetzt kann das Problem auch nicht gelöst werden, indem jeder alles selbst regelt. Es hat schon seinen Grund warum es zentrale Vorgaben gibt. Außerdem betont das Manifest ja auch, dass Prozesse und Werkzeuge nicht wertlos sind, sondern nur die andere Seite wichtiger ist. Doch wie lösen agile Unternehmen dieses Problem? Indem zentrale Angebote statt Vorgaben gemacht werden. Es ist eine ganze Menge Arbeit einen zentralen Prozess oder ein zentrales Werkzeug bereitzustellen. Gerade in hoch reglementierten Märkten braucht es dazu nicht nur die Installation, die Integration und den Betrieb, sondern auch Sicherheitskonzepte, Betriebshandbücher, Revisionsabsprachen, Zustimmung des Betriebsrats, … All dies machen diejenigen, die das Angebot machen und sie dokumentieren auch, was sie alles berücksichtigt haben, um auch den Mehrwert (Fokus auf Nutzen) ihrer Arbeit transparent zu machen.

Wenn jetzt der Fall aufkommt, dass der angebotene Standard nicht passt und es aus welchen Gründen auch immer nicht möglich ist, diesen für den konkreten Einsatzzweck anzupassen, dann gibt es die Möglichkeit eine eigene Lösung zu entwickeln. Das wird jedoch wohl überlegt sein, denn es ist ja transparent, was dabei alles berücksichtigt werden muss. Die neue Lösung muss dann eben auch ordentlich eingeführt und betrieben werden und auch die Compliance-Vorgaben erfüllen. Deshalb kommt das einfach selten vor.

Dieses System ist auch ein guter Ansporn für alle Personen und Gruppen, die zentral Prozesse und Werkzeuge bereitstellen, da sie wissen, dass ihre Dienstleistung qualitativ gut sein muss. Andernfalls sind die Kollegen gezwungen eigene Lösungen zu entwickeln. Auch geschäftlich lässt sich das gut betrachten, da es um eine einfache Kosten-/Nutzenrechnung geht. Kosten der eigenen Implementierung und Pflege eines neuen Standards, gegenüber dem Mehrwert der dadurch entsteht.