Software Engineering Blog

Vor ein paar Tagen habe ich ja schon einmal den Vortrag von Alan Atlas über die Einführung von Scrum bei Amazon berichtet, über die der bei ImmobilienScout24 gesprochen hat.

Marion Eickmann von agile42 hat Altas kurz danach zum Berliner Scrumtisch eingeladen und das auch in ihrem Blog mit Fotos dokumentiert. Aus dem Blog heraus kann man auch die Präsentation herunterladen.

Isabel Drost hat sich die Zeit genommen und Atlas' Vortrag in Ihren Blog ausführlich dokumentiert.

Gestern bin ich auf dem Scrum-Symposium hier in Berlin von ImmobilienScout24 gewesen und hatte die Möglichkeit zwei Vorträge über Scrum in der Praxis zu hören. Der erste beschäftigte sich mit Scrum bei ImmobilienScout24. Leider habe ich dank der vereisten Berliner Straßen das meiste davon verpaßt. Der zweite wurde Vortrag an diesem Abend wurde von Alan Atlas gehalten, der bei Amazon die Webservices-Sparte (mit?) aufgebaut hat. Altas erzählte auf eine sehr unterhaltsame Art und Weise, wie er bei Amazon Scrum eingeführt hat. Eine kurze Zusammenfassung kann hier gefunden werden.

Was aber für mich wieder am interessantesten zu beobachten war, war daß in den Fragerunden, fast egal wo man ist, immer wieder die gleichen Fragen auftauchen. Wie gehe ich mit dem Testen um? Wie plane ich richtig und auch über längere Zeiträume? Wo bleibt der Architekt und was macht er? Wie tue ich dies oder jenes? Warum sagt und Scrum nicht, wie wir das zu tun haben? Einige Punkte hierzu werden von auch von Uncle Bob angesprochen oder auf XING in der Scrum-Gruppe diskutiert.

Der Kern von Scrum

Scrum hat kein Problem. Das was einige für ein Problem halten, ist die Grundeigentschaft von Scrum. Scrum ist wie viele agile Prozesse schlank aufgestellt und bringt nur wenige Regeln mit. Doch wir wollen an die Hand genommen werden und in Sicherheit sein, in dem wir die Regeln befolgen, die es gibt. Gibt es diese nicht, fühlen wir uns unsicher.

Bleibt also die Frage, was Scrum ist, wenn es uns doch keine Antwort auf alle Fragen in jeder Situation ist?

Scrum kann ganz einfach auf folgendes heruntergebrochen werden:

• Scrum ist Selbstorganisation. Wir sind angehalten uns selber die Regel zu geben, die wir für richtig halten.
• Scrum ist Kommunikation. Dadurch sollen wir anfangen uns auszutauschen, gemeinsam Probleme zu lösen und Wissen zu verteilen.
• Scrum ist kontinuierliche Verbesserung. Probleme sollen nicht auf die lange Bank geschoben werden, sondern aktiv gelöst.

Dafür gibt uns Scrum ein Rahmenwerk mit ein paar Regeln und Rollen. Umsetzen müssen wir es. Das ist schwer, aber auch sehr spannend.

Ein Freund meinte einmal zu mir, daß das doch alles "gesunder Menschenverstand" sei. Sicherlich ja, aber beherzigen wir den auch immer?

Alexander Kriegisch von Scrum-Master.de hat dem "Scrum on a Page" von William c. Wake aktualisiert und über seine Homepage uns allen zur Verfügung gestellt.

Scrum-On-A-Page faßt kurz für den täglichen Gebrauch die Scrum-Rollen, den Prozess und die wichtigsten Inhalte der Meetings und die Scrum-Artefakte zusammen.

Hier geht es zum Download...

Im PM Blog habe ich einen interessanten Verweis auf einen Vortrag von Jurgen Apello auf der Agile Eastern Europe conference in Kiew gefunden, der nach meiner Ansicht wunderbar die wesentlichen Prinzipien zusammenfaßt, mit der Software-Entwicklungs-Teams geführt werden sollten.

Jurgen Appelo, "So Now You’re an Agilist. What’s Next?", Agileee conference, 2009 from Alexey Krivitsky on Vimeo.

Für alle aus dem Raum Berlin und an Scrum-Interessierte dürfte interessant sein, daß die OOSE im nächsten Jahr auch ein Scrum-Master-Seminar mit der Möglichkeit zur Zertifizierung in Berlin durchführt. Für mich auf jeden Fall die Gelegenheit, mich als Scrum Master zertifizieren zu lassen, ohne nach Hamburg zu fahren. Eigentlich aber auch schade.

Hier geht es zur Anmeldung für das Berliner Seminar.

Eine normale Arbeitswoche hat fünf Arbeitstage und zwei Pole. Montag ist der eine Pol und Freitag der andere. Anfang und Ende, Alpha und Omega. Jeder Wochentag hat seine Eigenheiten und von Wochenendarbeiten wollen wir einmal nicht ausgehen.

Montag ist der Tag nach dem Wochenende und das ist wichtig. Wir betreten das Büro ausgeruht und mit neuer Kraft. Probleme die am Freitag unlösbar waren sind über das Wochenende nebenbei gelöst worden. Manchmal einfach nach dem Aufstehen am Samstag und wir fragen uns, warum wir das nicht gleich so gesehen haben. Abstand und Ruhe sind oft die besten Problemlöser.

Am anderen Ende der Woche steht der Freitag. Freitag ist der Tag vor Samstag und Sonntag, also dem Wochenende und das ist wichtig für den nächsten Montag. Siehe oben. Freitags sollten keine harten Nüsse geknackt oder immens wichtige Termine angesetzt werden.

Was wir am Montag und Freitag tun, aber nicht sollten

Den Montag sollten wir uns für die Dinge vorbehalten, die wir mit ausgeruht angehen wollen, die uns vielleicht schon seit einiger Zeit unter den Nägeln brennen oder letzte Woche liegen geblieben sind. Oft wird der Montag aber gleich mit Meetings vollgekleistert, die sich damit beschäftigen, war in dieser Woche zu erledigen ist. War das nicht schon letzte Woche klar, was ansteht? Die Woche hat doch schon begonnen und über das Wochenende hat sich meistens wenig geändert.

Dafür wird am Freitag oft versucht noch das zu schaffen, was noch vor Montag umgesetzt sein muß. Das beste Beispiel hierfür sind Deployments, die noch „schnell“ am Freitag live gehen müssen. Schauen Sie an solchen Tagen mal in das Gesicht Ihrer Kollegen, die sich gerade überlegen, was alles schief gehen könnte und überlegen, wie wahrscheinlich es ist, spätestes um 18:00 Uhr das Büro verlassen zu können.

Wie wir es besser machen können

Aber wie können wir es besser machen? Hier sind meine Tipps:

• Planen Sie ihre Woche in der vorhergehenden Woche. Ideal sind Donnerstag und Mittwoch, Freitag geht auch. Wenn Sie jetzt einwenden, daß das zu früh ist, um zu planen, sollten Sie daran denken, daß wir die ganz kleinen Dinge sowieso nicht planen können.
• Lassen Sie den Montag frei und geben Sie sich die Möglichkeit Dinge anzugehen und zu lösen, die liegengeblieben sind oder zu denen Sie über das Wochenende Lösungen gefunden haben.
• Fangen Sie am Freitag keine Aufgaben an, die nicht über das Wochenende liegenbleiben können. Oder möchten Sie am Wochenende das Produktivsystem fixen?

So, Sie müssen ja nicht einverstanden sein mit meinen Ansichten zur Einteilung der Woche, aber vielleicht habe ich Ihnen ja einen Anstoß zum Nachdenken über Ihre Woche gegeben.

Am Rande habe ich Gunter Dueck schon einmal hier im Blog gestreift. Da er seine DD auch als PDF bereitstellt, lade ich sie mir immer "für später", also wenn man mehr Zeit ist, herunter.

Im DD 99 setzt er sich mit Elite, deren Verantwortung auseinander und greift dabei bis auf Platon zurück. Er schließt mit:

Eigentum verpflichtet. Elite verpflichtet. Bildung verpflichtet. Adel verpflichtet, Stärkev erpflichtet.
Wer je das Privileg hatte, oben zu sein, hat damit eine Pflicht auf sich geladen. Elite ist nicht oben sein, sondern unten helfen und führen.

Gut, Dueck hat sein DD bezogen auf die Bundestagswahlen bezogen, aber greift das nicht auch auf Führung von Menschen in Unternehmen? Führung kommt von führen...

An diesem Wochenende haben wir uns Karten für das Berliner Gorki-Theater gekauft, um uns Anna Karenina von Lev Tolstoj anzusehen.

Um halbwegs vorbereitet in das Stück zugehen, wollte ich mir die wichtigsten Fakten zur Geschichte zusammengooglen, da der Roman mehr als nur einen Handlungsstrang hat und ich im Theater nicht in Gefahr kommen wollte, den Überblick zu verlieren.

Tolstoj leitet seinen Roman mit dem Satz ein: "Alle glücklichen Familien sind einander ähnlich; aber jede unglückliche Familie ist auf ihre besondere Art unglücklich." Daraus wird abgeleitet, daß für das gemeinsame Glück mehrere Dinge notwendig sind, die auch erfüllt sein müssen. Fehlt es an einem, kann es kein Glück geben.

Verallgemeinert bedeutet das:

• Für das Gelingen einer Sache sind immer mehrere Faktoren zu erfüllen.
• Fehlt einer der Faktoren, kann die Sache nicht gelingen.

Dieses Prinzip kennen wir aus unserere eigenen Erfahrung und es erklärt sehr einfach, warum Dinge wie zum Beispiel Projekte trotz vieler Erfolge und größter Anstrengungen an Kleinigkeiten scheitern können.

Jetzt endlich habe ich dafür einen griffigen Namen...

Durch Artikel im Projektmanagement-Blog und im Blog von Jens Coldewey bin ich über Youtube (nein hier gibt es keinen Link) auf Prof. Peter Kruse aufmerksam geworden.

In diesem Video erklärt Prof. Kruse sehr gut, warum Veränderungsprozesse auch immer durch die oberste Ebene einer Organisation mitgetragen werden müssen und eine Änderung von unten nie erfolgreich ist. Und falls doch, dann nur, weil die Führung durch eine Reihe von Krisen so geschwächt ist, daß sie dem Änderungsdruck von unten nichts entgegen setzen können.

Für uns und unsere Projekte bedeutet dies, daß Veränderungen nur erfolgreich sind, wenn wir die Unterstützung der wichtigsten Stakeholder haben oder einfach der richtige Zeitpunkt dafür gekommen ist.

Gernot Starke hat in seinem Blog einen Hinweis auf seinen auf der WJAX
gehaltenen Vortrag zum Thema Architekturkommunikation hingewiesen, der als Video online zur Verfügung steht.

Starke widmet sich in seinem Vortrag dem Zusammenhang von Architektur und Kommunikation und weiß das überzeugend zu vermitteln.

Nach seiner Ansicht ist eine der wesentlichen Aufgaben eines Architekten die Kommunikation mit allen am Projekt beteiligten Stakeholdern. Richtig dachte ich nur während des ganzen Videos. Gute Architekturen zu entwerfenist das eine, sie zum Leben zu erwecken und zu halten etwas anderes. Dafür
müssen alle miteingebunden werden, die davon betroffen seien könnten. Und leider muß es muß auch immer wieder wiederholt werden.

Hier ein paar nebenbei notierte Aussagen von Starke:

• Architektur beschäftigt sich mit Strukturen und Konzepten.
• Implizite Annahmen treten immer da auf, wo etwas nicht
  dokumentiert ist, wo es notwendig gewesen war. (Alt bekannt!)
• Implizite Annahmen schaffen Mißverständnispotential. (Ich nenne
  das einfach mal heterogene Projektentwicklung. Klingt doch
  netter.)
• Architektur ist nicht das Kodieren von selbigen, da Code
  allein ab einer gewissen Größe keine Basis für Verständnis
  ist.
• Verständnis (von Architekturen) muß erst geschaffen werden und
  kann erst danach gefördert werden.
• Dokumentation muß minimalistisch sein, womit gemeint ist, daß
  nur die relevanten oder stabilen Punkte dokumentiert werden sollten,
  die für das Verständnis der Anwendung notwendig sind.
• Dokumentation muß wartbar sein.

Starke schafft es diese Punkte überzeugend zu vermitteln.

Fazit: Anschauen!