Wenn der Agile Coach nur ein Team hat um dessen Wohl er sich kümmern soll, dann hat er Glück. Es gibt einen klaren Fokus, man kann sich kümmern, man kann für „sein Team“ sorgen und es gedeihen lassen. Eigentlich das perfekte Setup, mit dem man den größten Benefit realisieren kann.
WeiterlesenWir hoffen, dass wir von der Kooperation profitieren, dass wir keine Engpässe durch Einzelkompetenzen erzeugen und jede Aufgabe – ihrer Priorität angemessen – schnell umsetzen können.
Spannend wird das Ganze, wenn wir in ein verteiltes Setup gehen, wie es meine Kollegen Martin Ruprecht und Jens Broos in ihren Talks und Workshops besprechen.
Die Schwelle zu Kooperation ist höher, wenn ich erst die Video-Konferenz oder das Remote-Pair-Programming-Werkzeug der Wahl aktivieren muss.
Wir würden deshalb gerne von Euch wissen: Wie oft braucht ihr denn tatsächlich Kooperation, das heißt, die Zusammenarbeit und Kommunikation zwischen Kollegen?
Wie viele Aufgaben kann jeder erledigen, wie viele brauchen Kooperation oder Wissenstransfer? Welche Abhängigkeitsstrecken haben wir, wo kann ich mit mehreren Kollegen an den Tasks der gleichen Story parallel arbeiten?
Ihr findet unsere Umfrage unter https://www.surveymonkey.de/r/3TX3LSY.
Es wäre nett, wenn ihr sie auch ausfüllt – die Ergebnisse stellen wir dann hier vor.
Agile Methoden setzen auf das Team, nicht auf die Individuen. Alles soll das Team entscheiden, alles soll das Team gemeinsam machen. Von Pair über Mob Programming, die meisten Dinge lasten auf mehr als einem paar Schultern. Als Metapher hat man sogar den Bus-Faktor gefunden: Wie viele Leute aus dem Team muss ich mit dem Bus überfahren, bis die Software nicht mehr weiterentwickelt werden kann?
The best architectures, requirements, and designs emerge from self-organizing teams.
Also ist die Sache doch klar: Das Team entscheidet selbst über die Architektur, und die alten Mächte, die aus den Enterprise Architecture Boards die richtige Architektur aus der Ferne finden wollten, sind bezwungen. Endlich kann man selbst Hand anlegen und Architektur passiert dann, wenn sie gebraucht wird.
Weiterlesen
Also lieber nicht schätzen, sondern auf Business Value und Durchfluss optimieren. Wenn ich zu jedem Zeitpunkt das Nützlichste mache und meine Strecke auf dem Weg dazu kontinuierlich verbessere – was könnte ich mehr als Beitrag leisten?
Das ist praktisch für das Team: Diese Stories sind fertig, bis auf Bugfixes und neue Features wird man von ihnen wenig hören. Endlich etwas geschafft.
Für das Team ist die Sache klar: Unter diesen Bedingungen kann man nicht mehr die Verantwortung für den Sprint übernehmen. Ähnlich sieht es der Scrum Master – so ist es nicht möglich, den Sprint weiterzuführen, er muss abgebrochen werden. Also trifft man sich in der Mitte des Sprints in einer spontan einberufenen Retro und bricht den Sprint offiziell ab, weil es ja nicht anders geht.
Schaut man sich die Diskussionen in agilen Unternehmen an, entsteht schnell der Eindruck, dass die Entwickler-Teams sehr zart besaitet sind und es ihnen an Kraft und Resilienz fehlt, auch mit den kleinsten Störungen umzugehen.
Wir alle kennen die Schmerzen, wenn es um die Formulierung von User-Storys geht. Je nach Unternehmen, Abteilung und Person ist alles möglich: Zwischen Akzeptanzkriterien, die aus einem einzigen Wort bestehen, und seitenlangen Dokumenten mit hunderten Querverweisen, von denen ohnehin niemand davon ausgeht, dass sie wirklich gelesen oder geprüft werden können, ist alles denkbar.
Wenn Sie die Seite weiterhin nutzen, akzeptieren Sie die Verwendung von Cookies. Weitere Informationen
The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.