Nicht nur bin ich in Bielefeld geboren und aufgewachsen, ich lebe auch noch im weiteren Dunstkreis der Hauptstadt von Ostwestfalen-Lippe. Zugleich habe ich wegen meines Namenskollegen, der u.a. das Buch „Lügenpresse“ veröffentlicht hat, einen gewissen Hintergrund mit Verschwörungstheoretikern, die – für mich offensichtlich – Schwierigkeiten mit der eigenen Recherche im Internet haben und deswegen meine Kontaktdaten gefunden haben, statt die meines Namenskollegen, den sie eigentlich kontaktieren wollten.
Beide Themen werden nicht nur im Film behandelt, sondern auch im dazugehörigen Spiel. Gleichzeitig bin ich als ehemaliger Amiga 500-Besitzer sehr angetan von klassischen Jump’n’Run-Spielen. Und jetzt auch noch ein klassisch aufbereitetes Jump’n’Run-Spiel mit dem Känguru. Das konnte ich mir einfach nicht entgehen lassen.
Das Spiel besteht aus mehreren Episoden. Einige davon sind als Jump’n’Run ausgelegt, andere haben eher einen Adventure-Stil, wo es mehr um das Lösen von Puzzles geht. Dann gibt es noch mehrere Episoden, in denen man durch die Gegend fährt und entweder Dingen ausweichen muss oder sie aus dem Weg räumen muss.
Als Gegner laufen in den Levels viele Verschwörungstheoretiker herum, die man ab dem zweiten Level wegboxen kann – sofern man gerade das Känguru selbst steuert. Marc-Uwe als Pazifist bleibt da nur noch die Option, entweder geschickt auszuweichen oder ihnen auf den Aluhut zu springen.
Apropos Aluhut: In den Levels versteckt sind auch jede Menge Aluhüte, je Level meistens einer in Bronze, einer in Silber und einer in Gold. Man muss sich schon mal anstrengen, um sie alle zu finden. Das vorlaute Känguru vermutet dabei von Anfang, dass es irgendein großes Mysterium zu entdecken gibt, wenn man alle gesammelt hat.
Insgesamt hat mir das Spiel durch meinen verkaterten Neujahrstag geholfen. Ich fand das Spiel kurzweilig, auch wenn ich anfangs mit ein paar Bugs zu kämpfen hatte. Wie ich feststellen musste, hatte ich scheinbar das Spiel zu einem ziemlich frühen Zeitpunkt schon gekauft und noch nicht alle Bugs waren ausgemerzt. Krass fand ich die Reaktionszeit der Entwickler: Bei den Bugs, die ich ihnen reportet habe, hatte ich meistens innerhalb von 24 Stunden ein Update mit einem Fix von genau meinem gemeldeten Fehler vorliegen. Die aktuelle Version schein mir stabil genug zu sein, dass ich das Spiel auf jeden Fall empfehlen würde, falls Ihr Anhänger von Platformern seid, gerne Puzzle löst und auf 8-Bit Grafiken steht.
Auf Steam habe ich folgende Bewertung hinterlassen:
Auf nach Bielefeld! Sehr nettes Spiel mit Abwechslung zwischen Adventure, Jump’n’Run und Rhythm-Scrollern. Kurzweilig und sicherlich mal wert, noch mal zu spielen. Für Känguru-Fans eine absolutes Muss.
Steam Review des Spiels
Man muss dazu sagen, dass es sich bei dem Spiel mehr um ein Kleinprojekt von leidenschaftlichen Fans handelt. In Details und in den Witzen konnte man viel von dieser Leidenschaft aus den Känguru-Werken wiederfinden, so dass Fans der Känguru-Chroniken mindestens hierbei auf ihre Kosten kommen werden.
Da die Reise in der Story im Spiel nach Bielefeld geht, teilte ich einige Tage später folgendes Feedback mit den Entwicklern:
Als Nicht-Nur-Känguru-Fan, sondern auch in Bielefeld Geborener und Aufgewachsener hat der Film und auch das Spiel gleich mehrere Nerven bei mir getroffen. Da ich auch noch Namensvetter des Autors des Buches „Lügenpresse“ bin, kam auch noch die Thematik der Verschwurbler dazu, die mir in den letzten 5 Jahren immer mal wieder ungewollte Fanpost beschert haben. Der Film und insbesondere auch das Spiel haben mir in den letzten zwei Tagen sehr dabei geholfen, mit den negativen Eindrücken der Fanpost der letzten zwei Jahre abzuschliessen. Und dafür möchte ich allen Beteiligten meinen persänlichen Dank aussprechen.
Kurzweilig, humorvoll, nicht zu schwierig. Einen ersten Eindruck vom Spiel bekommt man bereits im Trailer.
Mein zweites Durchspielen habe ich auf twitch gestreamt und bin in knapp 2 Stunden durchgekommen. Wer ebenfalls Lust auf etwas 8-Bit-Nostalgie gespickt mit Känguru-Humor hat, findet in diesem Spiel auf jeden Fall mindestens genauso viel Spass wie ich.
In diesem Sinne: auf zu Herta.
Adam Yuret, (2016), Create Space Independent Publishing Platform, 38 Seiten
Adam Yuret beschreibt in seinem Buch, was ihn an den meisten Meetings in Unternehmen stört. Für Adam haben sich viele der Probleme durch Lean Coffee gelöst. In seinem Buch beschreibt er dazu, was Lean Coffee ist, wie man ein Lean Coffee Meeting aufsetzen kann und welche Erfahrungen er mit dem Format gesammelt hat.
Bei einem Lean Coffee handelt es sich um ein loses Moderationsformat, bei dem anfangs keine festgelegte Agenda existiert. Die Agenda wird mit den Teilnehmern direkt am Anfang erstellt, indem sie zunächst Themen sammeln, diese vorstellen und dann über Dot-Voting priorisieren. Anschließend werden die Themen in kurzen Timeboxen von beispielsweise fünf Minuten diskutiert. Wenn genügend Teilnehmer einer Verlängerung zustimmen, so wird ein Thema weitere drei Minuten vertieft.
In seinem Buch geht Adam unter anderem auch auf seine Erkenntnisse als Moderator von Lean Coffee Meetings ein. Er bringt dafür langjährige Erfahrungen in der Organisation von Lean Coffees mit und das sowohl bei Konferenzen wie der großen Agile-Konferenz als auch bei lokalen Meetings von Usergruppen und in Unternehmen. Dadurch ist How to Have Great Meetings ein kurzweiliges Buch, das mit etlichen praktischen Tipps aufwartet.
David L. Rogers, (2016), Columbia University Press,
278 Seiten
Den Begriff der Digitalisierung hört man in diesen Tagen aus allen Richtungen. Das Digital Transformation Playbook von David Rogers beschäftigt sich mit der strategischen Sicht auf Digitalisierung. Rogers liefert ein Modell dazu, was Unternehmen in den letzten Jahren getan haben, um das Potenzial der digitalen Verarbeitung auszuschöpfen. Die Hauptunterscheidungsmerkmale liegen dabei in den Bereichen Kunden, Wettbewerb, Daten, Innovation und Wert. Diese Bereiche haben sich mit dem Vormarsch der Digitalisierung gewandelt, so dass Unternehmen heute strategische Vorteile durch den geschickten Einsatz von Datenverarbeitung haben.
Im Bereich der Kunden hat sich in den letzten Jahren ein Wandel vollzogen. Während früher Produkte spezifisch für Kunden hergestellt wurden und vor allem das Marketing den Kunden eingesäuselt hat, was sie kaufen sollen, liegt im digitalen Zeitalter ein viel höheres Potenzial darin, Netzwerkeffekte der Kunden auszunutzen. Internet-Startups haben diese Idee vorgemacht und im Rahmen der weiteren Digitalisierung nutzen immer mehr Firmen die eigene Kundenbasis, um weitere Nutzer für sich selbst zu gewinnen. Im Bereich des Wettbewerbs vollzieht sich ein anderer Wandel. Die Wettbewerber auf dem eigenen Markt kommen nicht länger aus dem eigenen Markt. Stattdessen gibt es Hersteller, die aus teilweise ganz anderen Märkten das eigene Geschäftsmodell torpedieren. Tesla beispielsweise setzt gerade traditionelle Autobauer unter Druck und tut sich sehr leicht damit, Innovationen umzusetzen, die bisher nur wenige Autobauer anbieten. Rund um Partnerschaften mit anderen Mitbewerbern entsteht so aber auch ein verteiltes Netzwerk, das man sich zunutze machen kann. Im Bereich der Datenverwaltung ist es heute leichter möglich, viele Daten zu sammeln und neue Erkenntnisse für das eigene Geschäft daraus zu gewinnen. Diese Einsichten wiederum helfen bei der Entscheidungsfindung für die weitere strategische Auslegung von Unternehmen. Rund um Innovationen wächst nicht zuletzt mit dem Vormarsch agiler Entwicklung in den Unternehmen das Potenzial für neue Funktionalitäten. Diese lassen sich mithilfe divergenter und konvergenter Experimente zielgerichtet und schnell einsetzen, um neue Funktionen angemessen zu validieren. Zu guter Letzt wandelt sich mit dem größeren Wettbewerb auch das, was Wert für Kunden generiert. Im digitalen Zeitalter wird immer weniger wichtig, was Firmen und Industrien als wertvoll definieren. Stattdessen müssen die Firmen in der Lage sein, auf sich verändernde Kundenbedürfnisse einzugehen und ihre Value Proposition kundengerecht anzupassen.
Rogers gibt in seinem Buch jede Menge Beispiele von Firmen wie AirBnB, Apple und Netflix, die es in den vergangenen Jahren geschafft haben, aus einem ganz anderen Marktsegment in immer wieder neue Bereiche vorzustoßen und Marktführer in diesen neuen Märkten zu verdrängen. Diese Beispiele untermauern die Diskussion um die fünf Hauptunterschiede im digitalen Zeitalter.
Außerdem liefert Rogers neben der theoretischen Diskussion einige Tools, um eine Strategie zur eigenen Digitalisierung ableiten zu können.
Das letzte Kapitel zu Markt-Disruption rundet das Buch insgesamt ab. Hier geht Rogers darauf ein, wie Unternehmen feststellen können, ob von einem neuen Wettbewerber aus einem neuen Umfeld eine Gefahr für das derzeitige Geschäftsmodell ausgeht und wie Unternehmen mit einer derartigen Disruption umgehen können, um nicht dort zu landen, wo viele Firmen wie die MobilfunkSparte von Nokia oder traditionelle Video-Verleih-Shops in den letzten Jahren gelandet sind: auf dem digitalen Abstellgleis.
Ron Jeffries, (2015), O’Reilly UK Ltd., 150 Seiten
Ron Jeffries ist einer der 17 ursprünglichen Unterzeichner des Agilen Manifests. Er ist weiterhin einer der Begründer der Extreme Programming (XP) Software Entwicklungsmethode und Autor von Extreme Programming Installed. In The Nature of Software Development versucht er dem Leser zu helfen, den natürlichen Weg (natural way), Software zu entwickeln, zu erkennen und zu verstehen.
Für Jeffries bedeutet der natürliche Weg, sich auf Wert zu fokussieren und entsprechend alle Facetten von Software-Entwicklung darauf zu basieren: Produziere früh, oft und richtigen Wert.
Was ist Wert eigentlich? Für Jeffries ist das klar: Wert ist das, was man will. Features sind die Teile, die Wert liefern. Daher ist es auch sinnvoll, dass wir Feature-Teams haben und diese, wenn nötig, einfach skalieren.
Das Buch besteht aus zwei Teilen. Im ersten Teil versucht Jeffries in kurzen Artikeln mit eigenen Skizzen den natürlichen Weg zu erklären. Der zweite Teil besteht aus Notizen und Essays, die versuchen, das Vorherige zu vertiefen. Das Buch liefert keine direkten Antworten oder Rezepte, sondern fordert den Leser auf nachzudenken. Daher schreibt Jeffries auch: „Your job is to think a lot, while I write very little.“
Der entscheidende Satz, der im Buch immer wieder auftaucht, ist für mich: „Zeig uns deine Software.“ („Show us your software.“) So einfach wie der Satz ist, so einfach ist Jeffries Argumentation: Wenn wir in regelmäßigen Abständen lauffähige Software demonstrieren, wird keiner nervös – weder das Management noch das Projektmanagement und auch nicht die Entwickler.
„This book should be ‚The CTO’s Guide to Professional Software Development‘.“ So preist „Uncle Bob“ Martin im Vorwort das Buch an. Während der Lektüre habe ich mir tatsächlich immer wieder gewünscht, dass die CTOs, mit denen ich bis jetzt zusammengearbeitet habe, das Buch gelesen hätten oder hoffentlich noch lesen würden.
Für erfahrene Agilisten wird das Buch keine neuen Erkenntnisse bringen. Die sehr einfache und gut durchdachte Argumentation von Jeffries wird aber auch den Erfahrenen sicher Freude bereiten.
Morgen ist mein letzter Arbeitstag in 2022 und ich bin mir nicht sicher, inwiefern ich die bisherige Veröffentlichungsmenge nach meinem Urlaub aufrechterhalten möchte. Ich vermute stark, dass ich wieder in einer großen Stille versinken könnte. Für die kommenden Woche habe ich noch einige agile review Buchreviews geplant, die nach und nach herauskommen werden. Darüber hinaus bin ich mir nicht sicher, ob ich viel Schreiben werden, falls überhaupt.
Ich freue mich über jede Person, die hin und wieder mal guckt, ob es etwas Neues von mir gibt. In diesem Sinne wünsche ich allen Personen, die meinen Blog lesen, an dieser Stelle schon mal ein Frohes Fest, Frohe Weihnachten, einen guten Rutsch und vielleicht sieht man sich ja mal im neuen Jahr in persona.
Craig Larman, Bas Vodde, (2016), dpunkt-Verlag, 290 Seiten
Das Buch Large-Scale Scrum ist das dritte Buch in der LeSS-Reihe. Während die ersten beiden eine ganze Reihe von Experimenten beschreiben, die die Autoren Craig Larman und Bas Vodde bei Nokia Siemens Networks über die Zeit ausprobiert haben und eher auf ein in agiler Skalierung fortgeschrittenes Lesepublikum abzielen, beschäftigt sich das neue Buch von Larman und Vodde damit, einen Handlungsleitfaden für die Skalierung zu liefern.
Das merkt man direkt beim Aufschlagen des Buches. Neben einer generellen Einführung in das Skalierungs-Framework LeSS beschäftigen sich die Autoren in ihrem neuen Werk mit der Motivation hinter der LeSS-Struktur, der Bedeutung des Produktbegriffs in LeSS und dem Ablauf im Sprint. Neben Tipps zu den Rollenbesetzungen und den entsprechenden Aufgaben geben Larman und Vodde jede Menge Hinweise rund um die Einführung von LeSS in einer Organisation und auch dazu, wie eine skalierte Organisationsstruktur mit mehreren Teams funktionieren kann. Auch wenn bei LeSS Manager als optional bezeichnet werden, haben die beiden Urheber des Frameworks der Rolle des Managements ein eigenes Kapitel spendiert.
Das Buch ist angereichert mit vielen hilfreichen Tipps aus ihrer mehr als zehnjährigen Erfahrung mit der Skalierung von Scrum. Dazu gehören nicht nur Geschichten aus den unterschiedlichsten Einführungen, sondern auch Bildmaterial dazu, wie ein Sprint Review mit mehreren Teams in einem Bazar-Format aussieht und wie das Backlog-Refinement und Sprint Planning mit mehreren Teams funktioniert.
Der Anhang rundet das Buch mit den grundlegenden LeSS-Regeln ab, die eine Zusammenfassung der jeweiligen Kapitel beinhalten, um einen direkten, möglichst reibungslosen Einstieg in die Scrum-Entwicklung mit mehreren Teams zu ermöglichen.
Das Scrum-Team sollte nur 50% seiner Zeit im Scrum arbeiten, die restlichen 50% mit anderen Tätigkeiten verbringen. Sie schätzten ihre Aufwände in idealen Personenstunden, aber der Effekt ist nach meiner Beobachtung gleich, wenn man hier auf ein abstraktes Schätzmaß wie Story Points setzt.
Zu Beginn des Plannings haben sie geplante Abwesenheiten aller Entwicklerinnen abgefragt. Danach kamen sie dann dazu, die Kapazität für den kommenden Sprint auszurechnen. Aus empirischen Daten wussten sie, dass sie an reiner Arbeitszeit ca. 40% von der verfügbaren Kapazität einplanen konnten. Also haben sie die Summe der verfügbaren Arbeitsstunden mit 0,4 multipliziert und hatte sie eine theoretische Kapazität von 180 Stunden für diesen Sprint. Damit waren bereits 30 Minuten des laufenden Sprint Plannings vorüber, bevor irgendjemand überhaupt einen Blick in die anstehenden Dinge geworfen hatte.
Die nächste Stunde verbrachte das Scrum-Team dann damit, die Kapazität zu verplanen. Eintrag um Eintrag wanderte in das weiter wachsende Sprint Backlog, bis die 180 Stunden voll waren. „Aber ich habe jetzt nichts zu tun.“ merkte ein Entwickler an. Also planten sie lustig Tätigkeiten für die Köpfe, die noch nicht ausgelastet waren ein, oftmals ungeachtet, ob das jetzt das wirklich dringlichste aus der Product Backlog Priorität ist. Am Ende hatten sie 320 Stunden für den Sprint eingeplant, alle hatten was zu tun, alle glücklich, richtig?
Eigentlich hätten sie sich die erste halbe Stunde komplett schenken können. Gerade weil das Scrum-Team anschließend gar nicht nach verfügbarer Kapazität planen konnte, weil sie dafür nicht cross-funktional genug aufgestellt waren. Ich denke, ich muss nicht erwähnen, dass am Ende des Sprints natürlich nicht alles fertig geworden ist.
Ich arbeite mit Teams immer daran, dass sie die vorherige Velocity (deutsch: Geschwindigkeit) aus der Vergangenheit ignorieren. Stattdessen erarbeiten wir uns einen Plan, den wir für realistisch halten, also eine Menge an Arbeit, die wichtig ist für die kommenden zwei Wochen, aber gleichzeitig auch realistisch schaffbar erscheint.
Als letzten Sanity-Check nach dieser Planung zählen wir die Schätzungen auf den geplanten Product Backlog-Einträgen zusammen und vergleichen den Wert mit unserer Performance aus der Vergangenheit. Erscheint uns das ähnlich viel wie zuvor? Mehr? Viel mehr? Viel weniger? Je nach Ausgang der daraus entstehenden Diskussion kann man dann den Plan noch mal überarbeiten oder aus berechtigten Gründen damit in den Sprint starten. Alle relevanten Punkte wie „ich habe eine Woche Urlaub geplant“ werden bei der Erörterung der Gründe ohnehin aufkommen.
Das bedeutet, statt einer zeremonierten Zusammentragung von Velocity-Punkten können wir die Diskussion auch haben, wenn wir sie haben müssen. Brauchen wir sie nicht, lassen wir sie weg. Damit bleibt das Planning fokussiert auf den eigentlichen Sinn des Planens: das Planen der Inhalte, nicht der Kapazitäten.
Jake Knapp, Johne Zeratsky, Braden Kowitz, (2016) Bantam Press, 288 Seiten
Google Ventures unterstützt Startups auf der ganzen Welt, um Geschäftsideen zu validieren, bevor diese umgesetzt werden. Im Rahmen ihrer Arbeit bei Google Ventures haben die drei Co-Autoren Jake Knapp, John Zeratsky und Braden Kowitz ihre geballte Erfahrung in einem gut zu lesenden Buch zusammengefasst. Der Titel selbst hat nichts mit Sprints aus dem Scrum-Framework zu tun, sondern bezieht sich auf das Vorgehen, innerhalb einer Woche gute Ideen zu generieren, diese in einem Prototypen umzusetzen und dazu am letzten Tag von Kunden Feedback zu bekommen.
Der Untertitel verrät schon die ganze Struktur des Ansatzes der Autoren: In fünf Tagen herauszufinden, was für Kunden funktioniert. Dazu strukturieren sie eine ganze Woche von Montag bis Freitag, von der Ideengenerierung bis zum Einholen von Feedback. Im Buch bringen die Autoren neben der Vorstellung, wie das geht, auch immer wieder Geschichten von Firmen, in denen sie den Sprint-Ansatz benutzt haben. Dazu zählt beispielsweise ein Roboter für Hotels, der den Gästen vergessene Artikel des täglichen Bedarfs aufs Zimmer bringen soll.
Ein anderes Beispiel, das mehrfach im Buch benutzt wird, beschäftigt sich mit einer neuen Webseite zum Bestellen von Kaffee, die möglichst den Firmenwerten aus den Vor-Ort-Geschäften und der dazugehörigen Beratung treu bleibt. Im Groben strukturieren die Autoren die Woche dazu so, dass am ersten Tag die Beteiligten erstmal das Problem besser verstehen und ein Ziel für die Woche auswählen. Am zweiten Tag erarbeiten die Teilnehmer unterschiedliche Lösungen, aus denen am dritten Tag die beste Lösung ausgewählt und weiter ausgearbeitet wird. Am vierten Tag beschäftigen sich die Beteiligten mit der Umsetzung eines Prototyps, der möglichst echt wirken soll. Am fünften Tag dreht sich alles darum, den Prototypen fünf potenziellen Kunden vorzustellen und in Interviews Feedback zu bekommen.
Die Autoren geben viele nützliche Tipps, angefangen bei der Auswahl der Teilnehmer für die Woche bis zu Vor- und Nachteilen von Gruppen- und Einzelübungen, worauf man bei den Prototypen achten und was man bei den Interviews mit den Kunden im Blick haben sollte. Das Buch führt in fünf Teilen durch die einzelnen Tage und gibt nicht nur Tipps für die mechanische Umsetzung, sondern auch Tipps für die Moderation.
Wie sollen unsere Teams aufgeteilt werden? Wie viel Gehalt bekommt jeder Mitarbeiter? Auf welches Thema möchten wir uns in der nächsten Zeit am Produkt fokussieren?
Das sind nur ein paar Beispielen von Situationen, in denen Organisationen gerne Top-Down Entscheidungen treffen. Meistens involvieren diese Entscheidungen eine kleine Auswahl von Entscheidern, z.b. nur der Product Owner, die Vorgesetzten der Teammitglieder der betroffenen Teams oder die direkte Vorgesetzte bei der Gehaltsfindung.
Der Vorteil dieser Form der Entscheidungsfindung ist eine zeitliche Komponente. Die Entscheidung kann schnell – im Vergleich zur Involvierung aller Beteiligten – gefällt werden. Die Product Ownerin gibt die Richtung für das Produkt vor.
Die Nachteile ergeben sich daraus, dass wir als Menschen gerne unser eigenes Glückes Schmied bleiben möchten. Eine Entscheidung von jemand anderem, die unser weiteres Glück betrifft, – wie zum Beispiel wie viel Gehalt wir in den kommenden Monaten bekommen werden – kann dann schon mal auf wenig Gegenliebe stoßen. „Der hat doof entschieden“ kursiert dann schon mal in den Köpfen.
Das bedeutet insbesondere, dass bei Top-Down Entscheidungen nicht nur wichtig ist, dass die Entscheiderin das entsprechende Mandat für die Entscheidung bekommt, sondern auch, dass die Person sich um die Begleitung der Entscheidung kümmern sollte. Ein Product Owner mit guten Kommunikationsfähigkeiten wird sich beispielsweise leichter damit tun, eine unliebsame Entscheidung auch an die Stakeholder-Gemeinschaft des Produktes heranzutragen, als eine Person, die dort Defizite hat.
Zusammenfassend sind Top-Down Entscheidungen immer dann sinnvoll, wenn sie zeitlich kritisch sind, viel von der Entscheidung abhängen könnte, und wenn die Entscheidungsperon gut in der weiteres Begleitung gerüstet ist.
Basis-demokratische Entscheidungen, die von allen mitgetragen werden, bedürfen einer Entwicklung eines geteilten mentalen Modells rund um das Entscheidungsthema. Dann kann die Gruppe als solche eine Entscheidung treffen, die von einer Mehrheit mitgetragen wird – vielleicht sogar von allen Beteiligten.
Dieser Prozess der Entwicklung eines gemeinsamen mentalen Modells bedarf allerdings Zeit. Die Gruppe muss ihre Sichtweisen austauschen, so dass wir ein allumfängliches Bild bekommen, welche Nuancen und Beweggründe die Gruppe als ganzes bewegen könnte bei den Konsequenzen einer Entscheidung.
Die einleitenden Fragestellungen kann man auch als Bottom-Up Entscheidung fällen. Die Aufteilung von Teams können Teammitglieder z.B. in einem self-designing teams workshop vornehmen, die Gehaltsfindung kann über transparente Gehälter und einen Konsultationsprozess geschehen. Die Festlegung der Richtung kann eine Product Ownerin auch kollaborativ mit der Stakeholder-Gemeinschaft erarbeiten.
Bottm-Up Entscheidungen bedürfen mehr Zeit, bieten aber den Vorteil, dass die Ergebnisse von mehr Menschen per Definition mitgetragen werden. Das bedeutet, die initiale Entscheidung dauert vermutlich länger, die Begleitung im Nachhinein muss aber weniger intensiv als bei Top-Down Entscheidungen sein.
Oh, gute Frage. Bottom-Up vs. Top-Down Entscheidungen sind zwei Extrema im Entscheidungskontinuum. Natürlich kann man den Graubereich zwischen diesen Extrempositionen auch unterschiedlich gemischt füllen. Ein einzelner Entscheider fällt ihre Entscheidung erst nach einer Gruppenkonsultation ist beispielsweise eine Ausprägung. Das Einsetzen eines konsultativen Einzelentscheiders, der die Aufgabe bekommt, die Stimmen im System zu hören, bevor sie eine Entscheidung trifft, ist eine andere Ausprägung.
Bei den Vor- und Nachteilen ergibt sich dann allerdings auch eine Mischform von den Konsequenzen, die man nicht übersehen sollte. Die Begleitung eines Veränderung nach einer konsultativen Einzelentscheidung ist genauso wichtig, wie die Entscheidung selbst.
Ich bin mir sicher, dass in diesem Kosmos noch weitere Entscheidungsmöglichkeiten entdeckt werden können. Es muss nicht immer unser präferiertes Entscheidungsmodell für alles benutzt werden.
Chris McGoff, (2012) John Wiley & Sons, 272 Seiten
Chris McGoff beschreibt in diesem netten Buch verschie- dene Patterns, wie Gruppen besser miteinander arbeiten können. Getrieben werden die unterschiedlichen Primes dabei stets von der Rolle der Führungskraft. Ein wesentliches Muster ist etwa, dass man als Manager entweder im System des Unternehmens arbeiten kann oder an dem System, um den Mitarbeitern ein besseres Arbeitsumfeld zur Verfügung zu stellen.
In insgesamt 46 solcher Primes geht McGoff auf Aspekte ein, beispielsweise wie man andere mitreißt in seinen Unternehmungen, wie man eine geteilte Perspektive in einer Gruppe bekommt und wie man zu Entscheidungen kommt. Das Buch ist unterteilt in 16 Kapitel mit jeweils 2-3 solcher Primes, die Gruppen dabei helfen, jedes Problem lösen zu können.
Die Primes basieren auf McGoffs langjähriger Erfahrung in verschiedensten Unternehmen. Sie sind jeweils angereichert durch ein gut zu merkendes Bildchen, das das jeweilige Prime zusammenfasst. Dadurch prägen sich die unterschiedlichen Muster nicht nur besser ein, sondern können auch vom Leser einfacher in einer entsprechenden Situation vorgestellt und beschrieben werden.