Programmer At Work

"Adding manpower to a late software project makes it later." -- Fred Brooks, 1975

The Mythical Team-Month ist eine großartige Präsentation von Justing Searls (u.a.) über erfolgreiche Teams und schnellere Feedbackzyklen in der Softwareentwicklung. Die Folien stehen für sich alleine und sind aufgrund der angeschlagenen Audioqualität fast besser als die die 40minütige Aufzeichnung der Präsentation (siehe unten):



Hier die Videoaufzeichnung:

The Mythical Team Month from Justin Searls on Vimeo.

Einführende Videos über Scrum gibt es viele. Dieses hier zählt definitiv zu den Besseren. Gerade mal acht Minuten braucht Hamid Shojaee um seinen Zusehern viele Kernelemente von Scrum gespickt mit einigen persönlichen Erfahrungen zu vermitteln.



Klar, so manches Scrum -Artifakt oder -Meeting kommt in einem 8minütigen-Crash-Course zwangsläufig etwas zu kurz, aber dennoch ein gutes Video. Bemerkenswert finde ich neben der Gleichsetzung von ScrumMastern und Projektmanagern vorallem seine Einstellung zu Daily Scrums:

"The idea behind a standing meeting is that if everyone is standing nobody will waste time and therefore meeting will be short. And by meeting daily you can feel confident that everyone is on top of their tasks. The daily scrum is a great idea and especially useful in less experienced teams but I wouldn't call it a core or essential part of scrum. Insisting on these meetings in an already efficient and experienced team, especially teams that work in close proximity with one another could actually backfire by lowering team morality. Keep that in mind when deciding on having daily scrums." -- Hamid Shojaee über Daily Scrum

Heißt das also "Erfahrenes eingespieltes Team + aufrechter Kommunikationsfluss innerhalb des Teams" == "Daily Scrum kontraproduktiv"?

Auf keinen Fall! Schließt dieser aufrechte Kommunikationsfluss auch den Product Owner und vor allem auch den Scrum Master mit ein? für beide ist das Daily Scrum von wesentlicher Bedeutung. für den SM ist es ein Kanal um Impediments klar aufgezeigt zu bekommen, die zuvor vielleicht einem einzelnen Teammitglied aber nicht der ganze Gruppe bewusst waren. Blockaden die vielleicht bisher einfach nie angesprochen wurden. Außerdem ist das Daily Scrum nicht nur für das Team da. Es bietet auch Außenstehenden – allen Interessierten, wie etwa Marketing, Geschäftsführung, Kunden, potentiellen Nutzern... - eine Möglichkeit in ein Team und in ein Projekt hinein zu sehen.

"It's the meeting to end all meetings." -- Jonathan Rasmusson

Vor allem aber sollte das Daily Scrum natürlich seinen Teammitgliedern (und dem Projekt!) dienen. Es sollte Teil einer gefestigten Routine sein, die den (Tages-)Rhythmus vorgibt. Es ist mehr als ein Synchronisationsmeeting um sich über den Stand der Dinge zu informieren, es ist vor allem auch eine Gelegenheit ein Team noch enger zusammen zu schweißen und zu motivieren!

Aber es stimmt, einerseits sind auch erfahrene eingeschworene Teams die seit langem zusammen arbeiten, co-located sind, sich permanent austauschen und mit Scrum beginnen nicht vor schlechten Meetings sicher. Anderseits kann bei agilen Teams die tägliche taktische Planungskomponente (wer übernimmt welche Aufgaben?) mit der Zeit an Reiz verlieren kann. Oftmals begleitet von zusätzlichen Lästigkeiten, wie z.B. dass sich das Meeting verzögert, weil immer irgendjemand noch schnell irgendetwas fertig machen möchte. "Einen Moment noch! Muss nur noch schnell diese eine E-Mail fertig schreiben, dieses eine Telefonat führen, den Server neustarten, den Buildprozess anstoßen... (und dann unvorbereitet zum Daily Scrum)"

In solchen Fällen könnte ein Funkwecker im Teamraum helfen oder das automatisierte Abspielen eines bestimmten Songs, wie z.B. die Anfangssequenz von The Final Countdown von Europe oder irgendeinem anderen Song aus Rocky.

Aber klar, wenn jemand gerade im Flow ist, ist jede Unterbrechung schlecht.

"The purpose is not to meet... it is to improve." -- Joe Ely

Ein weiterer positiver Aspekt von Daily Scrums: Wenn man als Entwickler morgens beim Daily Scrum seinem Team - quasi öffentlich - erklärt, dass man die Funktion »Speichern« bis zum nächsten Daily Scrum liefern wird, dann erhöht das auch die Chance, dass das Feature tatsächlich geliefert wird (=commitment/forecast to each other). Jeder Mensch möchte stolz auf sich sein, möchte von anderen wertgeschätzt werden und niemand möchte seine Kollegen enttäuschen. Dieses Verhalten und der Wunsch etwas Qualitatives zu liefern ist meiner Erfahrung nach unter Softwareentwicklern besonders ausgeprägt.

Abschließend ein Tipp aus Jason Yips Artikel: It's Not Just Standing Up: Patterns for Daily Standup Meetings

"Instead of thinking of the daily stand-up as a ritual for the people, think of it as a ritual where the Work Items Attend (e.g., User Stories in an Agile context) and the people attend only to speak for the work items... since obviously the work items can't actually talk." -- Jason Yip

Wer sich ein bisschen bishin zu sehr viel mit Softwareentwicklung - und Scrum im Besonderen - beschäftigt, aber den Scrum et al. Talk von Ken Schwaber auf Google Video noch nicht gesehen hat: Halt! Sofort anschauen und heute noch etwas Neues lernen oder im schlechtesten Fall: von einem Ex-Marine gut unterhalten werden.

Scrums assumption is that you are intelligent or at least as intelligent as you'll ever be and that you will use that intelligence and your experience to come up with the best solution for whatever circumstance you're in right then.

When we first [...] announced Agile, 2001 there were a number of comments that agile was really, really good. This way from [...] people who were kind of a little troubled with Agile. They said really, really good if you have a team of outstanding engineers that are using excellent engineering tools, have engineering practices down pat, understand the business domain, the technology domain inside out and aren't interrupted and have all the resources they need, then you can use Scrum. While it's true that people like that can build an increment of software every iteration. That's good.

However, Scrum works with idiots. You can take a group of idiots, that maybe didn't even go to school, don't understand computer science, don't understand software engineering techniques, hate each other, don't understand the business domains, have lousy engineering tools and uniformly they will produce crap every increment. This is good!

You want to know - at the end of every iteration - where you are. And part of the point of Scrum [...] is transparency. So that everyone knows where you are all the time. -- Ken Schwaber