Mit einem Tropfen Öl kann man so und so viele Liter Trinkwasser vergiften. So ähnlich ist das mit dem "Firnis der Zivilisation", der ausgerechnet von Linken wie Wolfgang Schäuble betont wird, wenn man über Weltkriege spricht. Firnis ist der farblose Schutzanstrich, der den wahren Kern zwar zeigen aber auch schützen soll.
So ähnlich ist es aber auch mit agilen Methoden für die Softwareentwicklung. Es funktioniert nur, wenn alle eine positive, eigene Motivation haben.
Weder funktioniert es mit Leuten, denen man jeden Tat jede Woche sagen muss, was sie als nächstes tun sollen. Das müssen sie selbst erkennen. Sie müssen auch von sich selbst wissen, welche der Aufgaben im Arbeitsvorrat sie am besten umsetzen können. Wenn der Rhythmus aus Sprints und Meilensteine nicht anspringt und läuft wie ein 12 Zylinder sondern man in jedem Arbeitstakt auf die Einhaltung des Taktes achten muss, wird es nicht laufen.
Wenn Du 10 Product Owner mit Epics versorgst, und sie haben Rückfragen, die sie nie in der Gruppe sondern nur unter 4 Augen zu stellen wagen, ist Dein Zeitkontingent für die Woche schnell verfrühstückt.
Ja, man darf einwenden, dass es auch an mir liegen könnte. Dass ich die Episch nicht klar genug beschreibe. Die Trennlinie der Verantwortung liegt in der Tiefe: Ich beschreibe von allem den Umfang und das gewünschte Verhalten. Einzelheiten der Umsetzung müssen mit dem Architektenteam und/oder dem Technikteam auf Kundenseite besprochen werden.
Und wo wir gerade Missverständnisse aufklären: Der Sprint Review ist keine Verkaufsveranstaltung. Nein, sie ist nicht DIE Gelegenheit, sich von anderen Product Owner abzugrenzen. Sie ist der Ort an dem Du vor "Mächtigen" die Wahrheit sprichst -als Teil eines Teams.
Und hey, Kundenrepräsentanten: Sprint Review ist auch nicht der Ort, über Arbeitszeiten und Überstunden zu diskutieren.
Was sagst Du? Nein, mich interessiert nur, dass alles rechtzeitig fertig wird. Wann die Teams etwas beginnen, ist Prio 2.
Wenn Du dem Projekt signalisierst "Hey, ich lasse mich gerne als Hipster eines coolen Startups feiern und präsentiere gerne in Turnschuhen und T-Shirt, dann signalisierst Du den Entwicklern: Ich bin ein Teil von Euch. Vision und Ziel sind alles, Hierarchie und Druck ist etwas für Ewiggestrige."
Und wenn Du dann beim ersten Status "Nicht erreicht" sofort nervös wirst, weil Du nicht einschätzen kannst, wie kritisch das jetzt ist, dann solltest Du besser beim vertrauten Schmerz bleiben.
Denn was Du mal eben heraus posaunst das kannst Du nur schwer wieder zurücknehmen. Das bleibt dann uns überlassen. Die Sandwichposition gibt es auch in der agilen Welt.
Im Kern ist das doch das allzu Menschliche, das immer wieder durchbricht. Und entscheidend sind die Leute im Team, ob das jetzt Scrum ist oder was anderes. Und da die Leute so verschieden sind und natürlich verschiedene Interessen und Prioritäten, Hobbies und Ansichten haben, werden Software-Teams wirklich nur in Ausnahmefällen so funktionieren, wie es die Theorie "vorsieht". Die Kunst besteht dann darin, das alles ans Laufen zu bringen und sich einem theoretischen Optimum so weit wie möglich anzunähern.
AntwortenLöschenEs spricht auch nichts dagegen, Teams umzustrukturieren, wenn der Verantwortliche das sichere Gefühl hat, so nicht voranzukommen.
Und noch etwas ist GANZ wichtig: Die gemeinsame Sprache. Weil oft auch bei Allerweltsbegriffen unterschiedliche Interpretationen bestehen.
Und all das kann (!) dann in der Tat zum Erfolg führen, wenn ergänzend alle eine positive, eigene Motivation haben (s. Beitrag) - die nicht allzu verschieden voneinander sind.