Die balancierte Organisationskultur

Das agile Manifest [Beck et al. 2001] definiert eine Zusammenarbeitskultur. Diese Kultur lässt sich in vielen Unternehmen, die agile Verfahren einsetzen, nicht beobachten. Vielmehr werden agile Techniken praktiziert, ohne die Haltung, die hinter der Agilität stehende Kultur, zu begreifen.

Es gibt natürlich Projekte, die durch Anwendung agiler Praktiken (zum Beispiel der Scrum Praktiken) erfolgreich sind – aber nur, weil die Alternativen, wie zum Beispiel das wasserfallorientierte Vorgehen, für Innovationsprozesse schlechter geeignet sind. Ein Scrum-praktizierendes Projekt wird damit noch nicht gut, sondern erntet lediglich die niedrig hängenden Früchte.

Um gut oder exzellent zu sein, muss im Projektteam eine Zusammenarbeitskultur lebendig sein. Um mit agilen Verfahren auf Unternehmensebene exzellent zu sein, müssen Elemente der Zusammenarbeitskultur im gesamten Unternehmen einen hohen Stellenwert haben.

Agil zu sein bedeutet mehr, als agile Praktiken anzuwenden. Agilität ist ein kulturelles System, es bezeichnet eine Art zu Denken und zu Handeln.

Weiterlesen

Werbeanzeigen

Sind Sie in T-Form?

Innovation muss jetzt stattfinden. Soziale, ökonomische und ökologische Verbesserungen werden dringend benötigt. Diese Verbesserungen können nur durch Menschen hervorgebracht werden, die einen offenen Geist haben, die Freude an kooperativer Ideengenerierung und eine Leidenschaft für den Wandel zum Besseren haben. Menschen, die neue Perspektiven suchen und einnehmen können. Menschen, die radikal sind, die an die Wurzel der Dinge gehen und die Begonnenes zu einem guten Ende führen. Menschen, die einsichtig und mutig den Status Quo herausfordern.

Suchen wir, was uns eint, und nicht, was uns trennt.

Weiterlesen

Agile World

Von improuv organisiert und durch Telefonica unterstützt, fand am 11. und 12. Juli die Agile World 2012 in München in den Räumen der Telefonica statt. Unter dem Motto Sharing Experiences and Ideas habe ich zwei sehr intensive Tage voller Gedankenaustausch und mit interessanten Agilisten erlebt.

Die Inhalte waren inspirierend und hochwertig – dank der Sprecher und der Organisation durch improuv.
Die Teilnahme war kostenlos – dank der Förderung durch Telefonica.

Für mich wesentlich waren die von verschiedenen Sprechern aufgezeigten Grenzen  agil-organisatorischer Veränderung in großen Unternehmen. Hier gibt es ein Aufgabenfeld, das in den Häusern auftaucht, die schon länger Scrum in mehreren Teams praktizieren und in denen nach einem agilen Wirken in teamübergreifenden und gesamtorganisatorischen Zusammenhängen gesucht wird.

Einen spannenden Analyseansatz brachte Dieter Bertsch. Er stellte mit dem Core Culture Model von William E. Schneider einen Ansatz zur Klassifizierung von Organisationskulturen vor und brachte gleich noch einen Fragebogen mit, durch den eine Einschätzung der eigenen Organisation innerhalb der Modellkategorien (Anweisungskultur, Kompetenzkultur, Zusammenarbeitskultur, Vervollkommnungskultur) vorgenommen werden konnte.

Ein Vorschlag zur Erleichterung organisatorischer Anpassung ist die Schaffung von Kulturadaptern, um zum Beispiel eine Steuerungskultur an eine Zusammenarbeitskultur anzupassen. Ein Kulturadapter wäre beispielsweise die Umformulierung eines Burndown Diagramms in ein Berichtsformat, das in der Organisation bereits bekannt ist.

Zumindest für das obige Beispiel sehe ich Kulturadapter skeptisch, da Organisationsverhalten auch über Berichte und den Umgang mit Berichten gestaltet wird. So, wie das Messen von Fortschritt anhand fertiggestellter Software (und nicht anhand von verbrauchtem Aufwand) das gemessene System beeinflusst, so werden auch die Berichtsinhalte, -formate und -häufigkeiten einen Einfluss auf die Organisation haben. Mir stellt sich die Frage, ob ein Kulturadapter den nötigen Wandel umgeht oder verzögert? In erster Linie werden durch diese Adapter Informationen indirekter an nächsthöhere Managementeinheiten geliefert. Soll aber ein Wandel in der Organisation stattfinden, so muss dieser Wandel geführt werden [Kotter 1996]. Dazu sollten die Informationen, auf deren Grundlage Entscheidungen getroffen werden, so klar und ungefiltert wie möglich sein. Das Führungspersonal muss an erster Stelle den Wandel wollen und sollte somit den geringsten Bedarf für Kulturadapter haben. Öfter ist aber wohl eher das Gegenteil der Fall. Kulturadapter, so wie oben beschrieben, haben in meiner Wahrnehmung einen nachteiligen Effekt. Dennoch möchte ich das Thema nicht ad acta legen. Kann es sinnvolle Kulturadapter geben? Solche, die den kulturellen Wandel befördern?

Ein hitzig diskutiertes Thema fand sich in der Verortung von Architektur und Architekten in agilen Softwareentwicklungsprozessen. Waren wir uns noch einig darin, dass man Architektur benötigt und dass die Rolle eines Architekten oft benötigt wird, so konnten wir keine Einigkeit mehr in der Frage erzielen, ob ein Architekt das letzte Wort bei Architekturentscheidungen haben muss. Dies sehe ich in Analogie zum Product Owner, der das letzte Wort in geschäftlichen oder fachlichen Fragestellungen hat. Im späteren Nachdenken vermute ich, dass unser Dissenz sich vielleicht erklären lässt, weil wir unterschiedliche Projektarten und -größen vor Augen hatten und uns diese gegenseitig nicht richtig erklärt haben.

Meine Position zur Architektur im Scrum ist zum Beispiel unter [Schneider 2011] nachzulesen. Diese Einschätzung habe ich auch auf der Agile World in meiner Session zur konzeptionellen Integrität im Scrum Prozess [Schneider 2012] vertreten.

Was bleibt? Das Motto der Konferenz wurde umgesetzt. Vielen Dank.

Referenzen
[Agile World 2012] Website der Agile World 2012, siehe: http://agileworld.de/

[Kotter 1996] John P. Kotter, Leading Change, Harvard Business School Press, 1996

[Schneider 2011] Ulf Schneider, Scrum und Architektur, Konzeptionelle Integrität im Scrum Prozess, in: OBJEKTspektrum 4/2011, siehe: https://allesagil.net/2011/06/27/scrum-und-architektur/ 

[Schneider 2012] Ulf Schneider, Konzeptionelle Integrität im Scrum Prozess, Session auf der Agile World, Juli 2012, siehe: konzeptionelle_integritaet.pdf

Die fünf Fehlfunktionen eines Teams

Unsere gesamte agile Methodik stößt schnell an ihre Grenzen, wenn die Menschen, die über die Methodik zusammenarbeiten, nicht als Team agieren. Patrick Lencioni bietet mit seinem Titel The Five Dysfunctions of a Team, der 2002 bei Jossey-Bass erschienen ist, ein aus meiner Sicht überzeugendes Modell an, mit dem sich ein nicht funktionierendes Team einerseits analysieren lässt und das ausserdem dazu geeignet ist, den Weg hin zu einem funktionierenden Team aufzuzeigen.

Der folgende Text ist ein Auszug aus dem Buch von Pat Lencioni [Lencioni 2002:188-189], den ich aus dem Englischen übersetzt habe.

fuenf_fehlfunktionen
Die fünf Fehlfunktionen und ihre Maskierung

Die erste Fehlfunktion ist durch fehlendes Vertrauen zwischen den Akteuren gekennzeichnet. Diese Fehlfunktion findet ihren Ursprung im Widerwillen der Mitglieder eines Teams, innerhalb der Gruppe angreifbar zu sein. Teammitglieder die nicht wirklich offen zueinander über ihre Fehler und Schwächen sprechen, machen die Bildung von Vertrauen unmöglich.
Das fehlende Vertrauen wirkt beschädigend für das Team, weil der Weg für die nächste Fehlfunktion bereitet wird: Konfliktvermeidung. Teams ohne Vertrauen sind nicht in der Lage, sich ungefiltert und leidenschaftlich über Ideen auseinanderzusetzen. Stattdessen findet ein Rückzug auf verschleiernde Diskussionen und Schutzbehauptungen statt.
Das Fehlen gesunder Konflikte führt zur nächsten Fehlfunktion: fehlende Selbstverpflichtung. Wenn die Mitglieder des Teams ihre Meinungen nicht in offener und leidenschaftlicher Debatte zur Sprache bringen, werden sie selten oder niemals als Team hinter einer Idee stehen und verpflichtende Entscheidungen treffen. Stattdessen werden in Besprechungen Scheinzustimmungen abgegeben, die nicht bindend wirken.
Durch die fehlende Selbstverpflichtung werden die Teammitglieder gegenseitige Verantwortlichkeit vermeiden, den ohne die Verpflichtung zu einem klaren Aktionsplan werden selbst fokussierte und engagierte Menschen ihre Kollegen nur zögerlich auf ihr teamschädigendes und kontraproduktives Verhalten hinweisen.
Geht die gegenseitige Verantwortlichkeit verloren, entsteht ein Umfeld in dem die fünfte Fehlfunktion gedeihen kann. Fehlende Ergebnisorientierung entsteht, wenn die Mitglieder des Teams ihre individuellen Bedürfnisse (wie z.B. Ego, Karriere, Sichtbarkeit), oder die Bedürfnisse ihrer Abteilungen über das gemeinsame Ziel des Teams stellen.

So wie eine Kette mit nur einem gebrochenen Glied nicht funktioniert, verschlechtert sich die Teamarbeit, wenn auch nur eine der genannten Fehlfunktionen raumgreifen kann.

Referenzen
[Lencioni 2002] Patrick Lencioni, The Five Dysfunctions of a Team, Jossey-Bass 2002

Fertigstellungskriterien (Definition of Done)

Die Fertigstellungskriterien sind nicht nur eine Prüfliste, die für die Erzeugung eines Arbeitsergebnisses abzuarbeiten ist. Vielmehr eröffnen die Fertigstellungskriterien – und der Weg zu ihrer Definition – einen Raum für agiles Denken und Handeln, der nicht nur durch das ausliefernde Team, sondern auch durch die umgebende Organisation gestaltet werden kann.

Die Diskussion der Frage, „Wann ist eine Sache fertiggestellt?“ erzeugt Einsichten in den Arbeitsprozess.
Die Frage wird an erster Stelle innerhalb des Auslieferungsteams diskutiert. Dabei zeigt sich sehr schnell, ob das Team für die Erbringung der Arbeit richtig besetzt ist.

Zunächst ist der Teilaspekt der Arbeitsschritte relevant. Schon das klare Notieren einer Schrittfolge macht überflüssige, fehlende oder unzureichende Arbeitsschritte bewusst.

arbeitsschritte
Liste mit Fertigstellungskriterien

Die in diesem Rahmen zu ermittelnde Arbeitsfolge kann der Ausgangspunkt für eine Aufgaben- oder Kanbantafel sein. Allerdings muss nicht jeder Schritt als Spalte auf einer solchen Tafel berücksichtigt werden, es ist ebenso gut denkbar, mehrere Schritte in einer Spalte zusammenzufassen. Im einfachsten Fall zeigt sich das an einer Aufgaben- oder Kanbantafel, die nur die Spalten „nicht begonnen“, „in Arbeit“ und „fertig“ enthält.

kanban
Die Arbeitsschritte in einer Kanbantafel

Wenn bestimmte Arbeitsschritte durch das Team nicht ausgeführt werden können, ist zu entscheiden, ob das Team erweitert wird oder ob Schnittstellenverträge mit Lieferanten ausserhalb des Teams zu schliessen sind. Gleiches gilt für die Lieferung von Ergebnissen durch das Team. Die Definition der Schnittstellen mit Hilfe der Fertigstellungskriterien verankert das Tun des Teams in der umgebenden Organisation. Somit entsteht ein Ansatzpunkt für die Veränderung/Verbesserung dieser Organisation.

Für einen Product Owner ist die Liste eine große Hilfestellung, um objektiviert Arbeitsergebnisse abzuweisen oder zu akzeptieren. Gleichzeitig hat das Team von Beginn an vor Augen, wann eine nicht korrekt fertiggestellte Arbeit abgewiesen wird. Für die Komplexitätsschätzung des Teams ist die vorherige Kenntnis der Fertigstellungskriterien ebenfalls essentiell.

Übergreifend zu berücksichtigende Fertigstellungskriterien haben ihren Ursprung oft in den nicht-funktionalen Anforderungen eines Projektes. Diese Kriterien sind in mehr als einem Arbeitsschritt zu berücksichtigen, selbst dann, wenn in der Arbeitsfolge ein eigenständiger Prüfschritt für die Einhaltung dieser Kriterien existiert. Ein Beispiel dafür sind Performance-Anforderungen, die in einem Performancetest abgesichert werden, die sich in vielen Fällen aber nur erfüllen lassen, wenn sie in mehreren Arbeitsschritten berücksichtigt und überprüft werden.

Ist eine Liste von Arbeitsschritten erarbeitet, ergibt sich die Frage der Verantwortlichkeit für die Durchführung der Tätigkeiten. Zwar ist das Team als Ganzes für die erbrachten Leistungen verantwortlich, während der Verrichtung der Arbeit sind aber oft spezielle Kenntnisse und Fertigkeiten nötig, über die nur einzelne Teammitglieder verfügen. Dafür gibt es gute Gründe, zum Beispiel weil die Aneignung des relevanten Könnens viel Zeit und Energie beansprucht oder weil die zu lösende Aufgabe so komplex ist, dass fachinterdisziplinär gearbeitet werden muss. Über das Können Einzelner hinaus wirkt die Zuordnung von Arbeitsschritten zu bestimmten Rollen ordnend für den Teamprozess und kann Koordinationsaufwände verringern.
Insofern ist die Interpretation der Teamverantwortlichkeit dahingehend, dass „jeder im Team alles macht“ in sehr kleinen Teams von zwei bis drei Personen und in homogenen Projektumfeldern vielleicht möglich und sinnvoll, in meiner Praxis traf das bisher nur selten zu.

arbeitsschritte_und_rollen
Fertigstellungskriterien mit zugeordneten Verantwortlichkeiten

Es ist besser, die Energie im Team auf die Pflege einer angstfreien und offenen Kommunikation bei gleichzeitiger Aufrechterhaltung der Professionen und zugehörigen Rollen einzusetzen.
Es ist besser, unklare Rollenverantwortlichkeiten nicht zuzulassen.
Dabei geht es darum, die verschiedenen Talente im Team produktiv zu nutzen, weil heterogene Aufgabenstellungen besser durch heterogene Teams bewältigt werden.

Suchen Sie also klare Arbeitsschritte und klare Rollenverantwortlichkeiten.

Manche Rollen können gut mehrfach besetzt werden, so dass gegenseitige Vertretungen oder fachlicher Austausch zwischen den Inhabern derselben Rolle befördert werden.
Lassen sich bestimmte Rollen, die zur Durchführung eines Arbeitsschrittes nötig sind, nicht besetzen oder sind einzelne Teammitglieder nicht bereit, die damit verbunde Verantwortung gegenüber dem Team wahrzunehmen, so haben Sie vielleicht ganz nebenbei einen Hinweis für eine organisatorische Dysfunktion erhalten. Es lohnt sich, dem nachzugehen. Warum ist die Rolle so schwer zu besetzen? Warum wird die Verantwortung nicht übernommen?

Bei allem zuvor Gesagten darf nicht aus dem Blick geraten, dass immer  das Team als Ganzes für die erzielten Ergebnisse die Verantwortung trägt.