Diese Seite setzt Cookies ein, um das Nutzerlebnis zu verbessern. Durch Klick auf "OK" erklärst Du Dich damit einverstanden. Mehr dazu gibt es unter Datenschutz.

OK

„Individuals and interactions over processes and tools“ – das agile Manifest im Detail (1)

Teil eins einer kleinen Serie namens „das agile Manifest im Detail“ – es folgen ein paar Postings die sich mit den Grundsätzen aus dem agilen Manifest auseinander setzen: Was bedeuten die Grundsätze? Wie sind sie gemeint? Und vor Allem: wie sind sie nicht gemeint? Denn der letzte Punkt wird irgendwie sehr oft unterschlagen. Dabei hilft eine Abgrenzung gegen das Negativ oft weiter, wenn es darum geht die Bedeutung einer Aussage einzugrenzen bzw. die häufigsten Missverständnisse zu vermeiden.

Prozesse und tools die Schwimmweste des Teams

Prozesse und tools, die Schwimmweste im Arbeitsozean – nicht das wichtigste, aber sie helfen das wichtigste zu schützen.

Heute geht’s um den ersten Satz des agilen Manifests: „Individuals and interactions over processes and tools“

Was ist damit gemeint? Die Sätze des agilen Manifests sind in der Regel von einer bestimmten Dualität geprägt. Im Kern steht der Gegensatz von Dynamik und Statik, Flexibilität und Starre. Es geht immer darum einen Feedbackloop und damit einen Regelungskreis zu etablieren und zu halten (Merksatz: „Inspect and adapt“).

Was ist im Zweifel wichtiger?

Im vorliegenden Beispiel wird die Dynamik des Systems durch den Teil „individuals and interactions“ repräsentiert. „Processes and tools“ hingegen steht für eine Starrheit, für ein nicht gegebenes Anpassungsvermögen.
Beide Teilsätze werden nun durch das Wort „over“ verbunden. Dieses „over“ drückt die Beziehung zwischen beiden Parts aus. Es sagt aus, dass im Zweifel Individuen und die Kommunikation zwischen ihnen wichtiger sind als das Festhalten an bestimmten Prozessen und Tools.

Der Satz „individuals and interactions over processes and tools“ trägt der Tatsache Rechnung, dass Softwareentwicklung immer auch eine ergebnisorientierte Sache ist. Sozusagen „Prozess schön und gut, aber am Ende muss jemand das Ding bauen.“ Der Satz sagt aber nicht, dass es keine Prozesse und Tools braucht. Im Gegenteil! Agiles Vorgehen setzt nach wie vor stark auf Prozesse, jedoch auf intrinsische Prozesse. Also auf die Individuen und ihre Vorstellung davon wie Arbeit organisiert werden soll. Im Gegensatz dazu steht ein extrinsischer Prozess, der von der Organisation, dem Management – von wem auch immer – von außen vorgegeben wird.

Es gibt immer einen Prozess

Seien wir ehrlich: es bildet sich immer ein Prozess heraus. Wenn es keine Vorgaben von außen gibt, machen sich die Individuen – wie in jedem sozialen Umfeld – selbst Regeln nach denen sie ihr Handeln orientieren.
Das agile Manifest möchte nun auf diese den Individuen innewohnenden Vorstellungen aufsetzen und diese nutzen. Das ist vernünftig. Entscheidungen sollen nach Möglichkeit auf der Ebene getroffen werden, wo sie benötigt werden. Ein Team sollte den Spielraum haben sich seinen Prozess, seinen Workflow zu gestalten wie es dem Team am besten passt. Selbstverständlich so lange die Zielorientierung (immerhin entwickeln wir ein Produkt, das soll fertig werden) gewahrt bleibt. (Kleiner Einschub: Manche Entscheidungen können natürlich nicht auf der Ebene des Teams getroffen werden – bspw. wenn es um unternehmensweite Standards geht oder um die Arbeitsweise eines anderen Teams. Hier muss man ins Gespräch mit den Entscheidungsträgern gehen und versuchen gemeinsam eine Veränderung herbeizuführen.)

Denn Prozesse sind kein Selbstzweck. Man arbeitet nicht nach einem Vorgehensmodell um des Modells Willen. Prozesse sind immer Mittel zum Zweck, sie sind Werkzeug und Weg meine Ziele zu erreichen. Und die Ziele können verschiedener Gestalt sein: schnellere time to market, Flexibilität bei der Planung, zufriedenere Mitarbeiter die sich besser einbringen können – you name it.

Gleiches gilt für tools. Wozu benutzen wir die tools? Um alle Softwarelizenzen die unser Unternehmen erworben hat zu nutzen? Ich denke nicht. Wir benutzen die tools weil sie uns helfen sollen die Vorstellung von Arbeitsorganisation die wir haben abzubilden. Und uns so viele administrative Arbeiten (i.S.v. Verwaltung, keine Arbeit am konkreten Produkt / Projekt) abzunehmen.
Auch tools sollten durch das Team angepasst werden können – das kann auf vielfältige Art und Weise geschehen. Beispielsweise indem wir die Workflows verschiedener Issuetypen / Tickets (Beispiel JIRA) anpassen, so dass sie unserer tatsächlichen Arbeitsweise entsprechen (Status, Benachrichtigungen etc.). Uns zum richtigen Zeitpunkt automatisch fragen wieviel Aufwand wir investiert haben (immernoch Beispiel JIRA). Und – auch automatisch – geschätzte Restaufwände auf null setzen wenn ein Issue done ist (ja, immernoch JIRA).

Wir haben die Möglichkeiten unsere Umwelt an unsere Bedürfnisse und unseren Bedarf anzupassen. Diese Möglichkeit sollten unbedingt wir nutzen. Das nimmt uns Arbeit ab und gibt uns Zeit uns um die eigentlichen Aufgaben zu kümmern. Und darauf will das agile Manifest an dieser Stelle u.a. hinaus. Es sagt uns, dass man im Zweifel Prozesse und tools anpassen soll, damit sie das Team bei der Arbeit unterstützen. Der Fokus liegt auf dem Ziel der Arbeit, nicht unbedingt auf konkreten Prozessen oder tools. Prozesse und tools werden nicht abgeschafft, sondern ihre Wichtigkeit wird in Relation zu den arbeitenden Individuen gesetzt. Und die sind neben dem Arbeitsziel am wichtigsten.

Scrum gibt aber einen „Prozess“ vor – alles Lüge?

„Stimmt doch vorne und hinten nicht! In meinem Scrumbüchlein steht genau drin wie’s gemacht werden soll (und dass man dazu den Greenhopper benutzt, sonst isses kein Scrum)“ Von wegen! Da steht drin wie es gemacht werden kann. Scrum als Prozessmodell beschreibt nur das notwendigste und wie man es organisieren kann. Nicht wie man es organisieren muss.

Wenn man sich mit (auch nur halbwegs seriösen) Scrum Coaches / Scrum Mastern unterhält, kommt immer irgendwann der Punkt an dem ideale Scrumwelt und Realität kollidieren. Und dann ist die Frage wie geht man damit um. Beispiel:

Wir benutzen unternehmensweit tool XY, das muss das Scrumteam auch benutzen. Schlimm? Nein. Die Frage ist unterstützt das tools das Team bei seiner Arbeit oder nicht. Wenn nicht: Wie kann ich dafür sorgen dass es das tut? Wenn das unter keinen Umständen möglich ist (was ich in den meisten Fällen jedoch für machbar halte, denn die meisten tools kann und muss man nunmal konfigurieren), dann muss man sich die Frage stellen wozu dieses tool gut ist. Manchmal erfüllt es ein unternehmensrelevantes Ziel das seine Nachteile für die konkreten Teams übergeordnet aufwiegt. Wenn nicht, dann raus damit.

Der Punkt ist wieder inspect and adapt. Nimm die Schablone aus dem Scrumbüchlein und passe sie an! Nichts ist in Stein gemeißelt. Es handelt sich vielmehr um Hilfestellungen, sensible defaults wenn man so will. Daran kann man anknüpfen. Nur nicht alles glauben was irgendwo steht, sondern selbst nachdenken…

Grenzfälle – wann es besser ist einen Prozess vorzugeben

„Individuals and interactions over processes and tools“ – keine Regel ohne Ausnahme. Denn das agile Manifest hat bestimmte Vorannahmen wenn es „individuals and interactions over processes and tools“ stellt.
Und diese Vorannahmen fallen unter den Begriff „agiles mindset“. Schauen wir uns das näher an:

Es gibt Teams die sind relativ homogen, was ihre Arbeitsweise angeht. Und im Idealfall sind die Teammitglieder kommunikationsstark, gehen auf andere zu wenn sie Fragen haben, treten an andere heran um Aufgaben durchzusprechen, bieten anderen von selbst Hilfe bei bestimmten Fragestellungen an.
Das ist ein Glücksfall, denn dann bilden sich – unausgesprochen, durch die Praxis – Prozesse heraus, unter denen sich die Teammitglieder selbstständig und eigenverantwortlich organisieren um ihre Ziele zu erreichen. In dem Fall braucht man flankierende Maßnahmen – man strickt die tools u.ä. sozusagen um die Arbeitsweise des Teams herum und (unter-)stützt die Kollegen. Das agile mindset ist schon da.

Und es gibt Teams die sind sehr heterogen, was ihre Arbeitsweise bzw. die Vorstellung davon wie Arbeit organisiert sein und ablaufen sollte. Und hier hilft ein Impuls von außen! Der Scrum Master thematisiert die Frage wie das Team arbeiten möchte und zeigt mögliche Organisationsformen auf, geht vielleicht in dem Sinne schon in Vorleistung: Der Scrum Master schlägt einen Prozess (als Leitplanken) vor. Das Team aktualisiert seine Vorstellung vom Workflow und entwickelt diese mit Hilfe des Scrum Masters weiter – letzten Endes im Sinne des agilen Manifests. Insofern kann zu Beginn eine Etablierung eines bestimmten Prozesses die forming Phase („Team Uhr“, ne?!) des Teams begünstigen.

Auf diese Art und Weise kommt der Scrum Master seiner Aufgabe nach das agile mindset der Kollegen zu fördern – und mit dem steht und fällt der Erfolg von Scrum oder anderen agilen Vorgehensweisen. (A propos Vorannahmen: Weshalb agiles mindset, eigenverantwortliches und selbstorganisiertes Handeln der Kollegen wünschenswert ist, darauf gehe ich zu späterer Zeit mal gesondert ein – das sprengt mir hier sonst den Rahmen.)

Und das heißt jetzt was?!

Nun, long story short: In jedem Fall bildet sich ein Prozess heraus. Daher ist es besser diesen Workflow bewusst zu gestalten als abzuwarten was sich unbewusst herausbildet (das zu korrigieren wird zeitintensiv, stressig und teuer). Das agile Manifest lenkt dabei den Fokus auf die tatsächlichen Vorstellungen und Wünsche der Beteiligten und weg von Ideen und Annahmen die sich irgendjemand im stillen Kämmerlein ausgedacht hat. Dazu bietet Scrum ein sensible default von dem man ausgehen, das man weiterentwickeln kann damit es zur Organisation passt. In jedem Fall sollte das Individuum im Mittelpunkt stehen, denn:

Arbeit macht sich nicht von allein, Arbeit wird von Menschen geleistet.

Und die möchten sich auf ihre Arbeit konzentrieren können und nicht jedes Mal 10 Minuten überlegen welche resolution ein Ticket braucht wenn es fertig ist.

Verwandte Artikel

Schönen Donnerstag!