Her mit den Problemen

In meiner Ausbildung zum lösungsfokussierten Coach habe ich Denken in Lösungen gelernt. Es hilft! Es ist motivierend, sich vorzustellen, wie es sein wird, wenn das Ziel erreicht und das Problem Vergangenheit ist. Daran zu denken, was gut funktioniert und wie man mehr davon machen könnte, eröffnet neue Perspektiven und setzt emotionale Kraft frei.problem lösung

Auf der anderen Seite kenne ich die Vorteile einer strukturierten Problemanalyse. Ich setze Techniken wie die Root Cause Analyse ein, mit denen ich den Problemen auf den Grund gehe. Wenn ich die tieferliegenden Ursachen kenne, kann ich Maßnahmen entwickeln, die das Übel an der Wurzel packen und nicht nur Symptome kurieren. Tabletten bekämpfen mein Kopfweh, aber genau das hindert mich daran, mir die Mühe zu machen, mit einem Kopfschmerzkalender die Ursachen für die Schmerzen herauszufinden.

Schauen wir uns ein anderes Beispiel an. Das Entwicklerteam hat wieder mal nicht alles geschafft, was es sich für den Sprint vorgenommen hat. Der problemorientierte ScrumMaster fragt in der Retrospektive: „Warum haben wir das Commitment nicht geschafft?“ Es kommen Antworten wie „Weil wir uns verschätzt haben“, „Weil der Product Owner mitten im Sprint mit neuen Anforderungen gekommen ist“, „Weil Peter eine Woche krank war“. Das beharrliche Weiterbohren des problemorientierten ScrumMasters fördert die Ursachen zu Tage: „Der Product Owner ist gewohnt, dass seine Wünsche sofort berücksichtigt werden, und möchte das weiter so haben“, „Das Commitment wird doch von niemandem ernst genommen und ist daher eigentlich überflüssig“, „Peter mag sein Wissen nicht teilen“.

Der lösungorientierte ScrumMaster fragt: „Stellt euch vor, wir sind im Review des nächsten Sprints und haben unser Commitment geschafft. Wie haben wir das hinbekommen?“ oder „Im vorletzten Sprint haben wir unser Commitment geschafft. Was war da anders?“ Das Team antwortet: „Wir haben einen Puffer in die Planung eingebaut“, „Wir haben Überstunden gemacht“, „Wir haben die neuen Wünsche des Product Owners ignoriert“.

In welchen der beiden Retrospektiven ist die Stimmung besser? Wahrscheinlich in der zweiten. Welche führt zu den besseren Lösungsansätzen? Wahrscheinlich die erste. Die Problemanalyse bringt uns vielleicht darauf, über den Sinn eines Commitments nachzudenken, anstatt zu überlegen, wie wir es erfüllen.

Komme ich mit Problemanalysen immer weiter? Nein – manche Probleme sind zu schwer zu durchschauen, zu komplex, ohne erkennbaren Zusammenhang zwischen Ursache und Wirkung. Oder die Ursachen entziehen sich meinem Einflussbereich. Ich werde die Haltung des Product Owners oder von Peter vielleicht nicht ändern können. Gerade in solchen Fällen hilft das Bauchgefühl, die Intuition, die das lösungsfokussierte Vorgehen auszeichnen. Sie erleichtern mir den Umgang mit dem Problem – auch wenn ich es gar nicht komplett verstanden habe. Lösungsfokus geht schneller, ist dafür aber weniger gründlich.

Wenn wir Problemanalyse einsetzen, müssen wir uns vor Schuldzuweisungen in Acht nehmen. Edward Deming, der „Erfinder“ des kontinuierlichen Verbesserungsprozesses, hat gesagt, dass 85 Prozent aller Fehler von einem mangelhaften System und nicht von den Mitarbeitern verursacht werden. Nicht Peter ist Schuld, wenn er sein Wissen nicht teilen will – das System honoriert Expertenteam mehr als Teamgeist. Nicht der Product Owner ist Schuld, dass er schnelle Reaktionen auf seine Anforderungen erwartet – seine Kunden erwarten auch schnelle Reaktionen von ihm, und die Auswirkungen solcher ad hoc Unterbrechungen auf das Team sind ihnen nicht ausreichend bewusst. Mit dem Team über Probleme zu diskutieren und ihnen auf den Grund zu gehen, kann Spaß machen – wenn das notwendige Vertrauensverhältnis dazu da ist, alle an einem Strang ziehen und Probleme als Chance für die gemeinsame Verbesserung behandelt werden.

Letztendlich hängt es an einzelnen Menschen, welche Vorgehensweise sie bevorzugen. Manche von uns sind her kopfgesteuert und analytisch, andere eher bauchgesteuert und emotional. Dementsprechend werden wir auch eine Vorliebe für eine der beiden Vorgehensweisen haben. Es ist hilfreich, beide im persönlichen Methodenkoffer zu haben, um sie je nach Situation anwenden zu können.

Probleme sind nicht das Problem – sie bringen uns dazu, uns weiterzuentwickeln. Langfristige und tiefgreifende Verhaltensänderungen sind dann nötig und möglich, wenn das bisherige Verhalten zu Problemen führt. Deswegen bin ich dafür, das Kind beim Namen zu nennen und nicht als „Herausforderung“ oder „Verbesserungspotenzial“ zu verklausulieren – und schon gar nicht unter den Teppich zu kehren. Also her mit den Problemen!

 

Werbeanzeigen
Veröffentlicht unter Uncategorized | Verschlagwortet mit , , , , | Kommentar hinterlassen

Ist Scrum Lean?

Heute habe ich gehört, Scrum sei die Anwendung von Lean in der Software-Entwicklung. Dazu habe ich mir meine Gedanken gemacht.

Na klar, Scrum hilft Teams (idealer Weise), Lean-Prinzipien umzusetzen. Ein paar Beispiele:

  • Wertschöpfung: der Product Owner ordnet (idealer Weise) den Backlog nach dem Wert für die Kunden.
  • Pull statt Push: das Team entscheidet (idealer Weise), wieviel Arbeit es in einem Sprint erledigen kann, und wird (idealer Weise) nicht gezwungen, mehr als das in den Sprint aufzunehmen.
  • Kleine Stapel an Arbeit (Batches): durch die zeitlich begrenzten Sprints ist auch die Menge des Work in Progress begrenzt. Dadurch werden (idealer Weise) Warteschlangen und Verschwendung vermieden.
  • Continuous Improvement: In den Retrospektiven entscheidet das Team, wie es immer besser werden kann. Idealer Weise wird dadurch auch die ganze Organisation besser.

Aber warum dieser Zusatz „idealer Weise“?

Mit dem Kunden im C-lean-sh

Ich kenne etliche Beispiele, wo ein „Product Owner“ nach allem möglichen priorisiert, aber nicht nach Wert für den Kunden. Weil er den Wert nicht einschätzen kann, vielleicht nicht einmal den Kunden kennt. Weil er zwar dem Team gegenüber als Vermittler dient, aber keine wirkliche Verantwortung für das Produkt trägt. Der Product Backlog ist eine „irgendwie“ geordnete Liste sein, nach der man die Arbeit organisiert. Das ist ja auch ok, da ich mit Scrum dies und das planen und organisieren kann, zum Beispiel meinen Umzug oder meine Geburtstagsfeier. Lean ist strenger. Lean rückt immer den Nutzen für den Kunden in den Vordergrund. Und zwar den wirklichen Kunden, nicht einen Abnehmer von Zwischenergebnissen am Ende eines Prozessschrittes. Die Testabteilung ist eben nicht der Kunde der Entwicklung. Nein, auch die Fachabteilung nicht. Nicht mal der Vertrieb, und schon gar nicht das Management. Sondern der, der unsere Produkte kauft und so dem Unternehmen die Einnahmen verschafft. Lean verlangt von allen Einheiten, dass sie sich zusammenraufen, um diesem Kunden zu nützen. Und alles, was ihm nicht nützt, wird erbarmungslos als Verschwendung klassifiziert. Wobei klar ist, dass wir diese Verschwendung nicht komplett wegrationalisieren können, weil unsere Organisation darauf angewiesen ist.

Ver-lean-kte Teams

Hilft denn Scrum automatisch dabei, Verschwendung zu vermeiden? Scrum Teams können Verschwendung vermeiden, wenn sie während der Sprints darauf achten, dass keine zu langen Warteschlangen entstehen. Dazu müssen die Team-Mitglieder bereit sein, Wissen und Erfahrungen so zu verteilen, dass sie sich gegenseitig helfen können, wenn es irgendwo brennt. Sie optimieren nur dann zum Wohle des Kunden und der Organisation, wenn sie sich als Teil eines Systems, eines Beziehungsgeflechts sehen und erkennen, dass ihre eigenen Bewegungen an anderen Stellen Zug oder Druck  auslösen. Sonst kann leicht ein lokales Optimum entstehen.

Lean, lean, nur Du allein…

Wenn trotz Scrum die Kunden nicht begeistert sind oder einzelne Einheiten eher gegen- als miteinander arbeiten, versucht es mal mit einer lean-dernden Maßnahmen wie der Wertstromanalyse – danach könnt ihr euch entspannt zurück-lean-en ;-).

 

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , , , , | Kommentar hinterlassen

Mein Block

Als ich neulich einem Kollegen von einigen Erfahrungen berichtete, war die Reaktion „Das ist ja interessant. Hast du das schon auf deinem Block gepostet?“ An meiner verständnislosen Mine war unschwer zu erkennen, dass dies nicht der Fall war. Meinen Block hatte ich schon vor Jahren abgeschafft, als ich noch an das papierlose Büro glaubte, aber noch keinen rechten Ersatz dafür gefunden. So konnte das nicht weitergehen! Schlimm genug, dass ich immer noch kein Smartphone und nur 4 Freunde bei Facebook habe, zwar ganz gern mal einen zwitschere, aber Twitter-abstinent bin. Wenigstens der blockfreie Zustand musste beendet werden! Nachdem meine Internet-Recherchen ergeben hatten, dass es den Ostblock nicht mehr gibt und der Schwarze Block von St. Pauli sich auch nicht zum posten (bestenfalls zum prosten) eignet, wurde ich relativ schnell bei WordPress fündig. Hier ist er also, mein eigener Block und mein erster (erstes?) Post – Prost!

Veröffentlicht unter Uncategorized | Kommentar hinterlassen