Software Engineering Blog

Das Software Engineering Blog läuft auf einer inzwischen angestaubten Version von WordPress und es wird langsam Zeit mit der Zeit zugehen. Daher werde ich zwischen den Feiertagen die Zeit für ein Update nutzen. Daher kann es zwischenzeitlich zu Problemen kommen. Aber ein schon angelegtes Vollbackup sollte das Schlimmste verhindern helfen.

Am Montag war der letzte Berliner Scrumtisch in diesem Jahr und Andrea Tomasini sprach über Kanban. Seine Vorstellung von Kanban sorgte unter den wenigen vorweihnachtlichen Teilnehmern für intensive Diskussionen. Vielleicht schaffe ich es ja noch ein paar Zeilen zu meinen natürlich rein subjektiven Ansichten dazu zu schreiben. Ehrlich gesagt, ich habe mich mit Kanban dabei nicht anfreunden können, auch wenn mir einzelne Ideen gut gefallen haben.

Nach dem Vortrag hat mich Tomasini auf das Buch The Fifth Disciplin von Peter M. Senge aufmerksam gemacht. Schon beim ersten Blätter wußte ich, das dieses Buch etwas für mich ist und habe es flugs bei A..... bestellt.

Nach Senger ist die fünfte Disziplin Systemdenken und faßt Personal Mastery, Mental models, Building shared vision und Team Learning zusammen. Das sind die ersten vier Disziplinen. Es geht also darum übergreifend zu denken und zu handeln, um Dinge zu vernetzen und so in Bewegung zu bringen.

Was mir an der Wikipedia-Zusammenfassung zum Buch besonders gut gefallen hat, sind The 11 Laws of the Fifth Discipline, die ich hier einfach einmal reinkopiere...

1. Today's problems come from yesterday's "solutions."
2. The harder you push, the harder the system pushes back.
3. Behavior will grow worse before it grows better.
4. The easy way out usually leads back in.
5. The cure can be worse than the disease.
6. Faster is slower.
7. Cause and effect are not closely related in time and space.
8. Small changes can produce big results...but the areas of highest leverage are often the least obvious.
9. You can have your cake and eat it too ---but not all at once.
10. Dividing an elephant in half does not produce two small elephants.
11. There is no blame.

Ich kann hier nur elf Mal nicken, aber meine Lieblinge sind 1, 6, 7 und last-but-not-least 8.

Statusmails sind ein beliebtes Kommunikationsmittel, um Meilensteine oder wichtige Änderungen an alle Beteiligten zu kommunizieren. Richtig formuliert vermitteln sie schnell die wesentlichen Fakten und helfen uns besser den Stand an auch einen größeren oder nicht immer direkt beteiligten Personenkreis zu vermitteln.

Eigentlich ist das sehr gut, denn wir alle wissen, daß Kommunikation wesentlich über Erfolg oder Mißerfolg, Sieg oder Niederlage entscheidet.

Daher sollte ich eigentlich auch kein Problem mit ihnen haben. Habe ich aber. Das Problem ist, das es Mails sind. Widersprüchlich? Auf den ersten Blick sicherlich, aber ich habe auch mindestens ein gutes Argument dafür: Mails gehen in den Mailboxen ihrer Empfänger verloren.

Zum einen bin ich mir sicher, daß die meisten Statusmails ungelesen in vielen Mailboxen versauern, da die Empfänger gerade mit subjektiv wichtigerem beschäftigt sind. Das in der Mail behandelte Problem betrifft mich jetzt gerade nicht, das kann ich auch später lesen. Irgendwann ist diese Mail kann in der Inbox soweit hinten, daß wir uns gar nicht mehr an sie erinnern.

Was aber noch schlimmer ist, diese Statusmails sind immer nur für die verfügbar, die genau in diesem Augenblick an dem Projekt beteiligt sind. Wer später hinzukommt, hat keine Chance mehr an diese Informationen zu kommen. Und oft sind es aber genau diese Informationen, die Projektneulingen helfen zu verstehen, warum das Projekt jetzt da ist wo es ist und warum dies so und jenes so ist.

Kommunikation zwo.null

Ein Blog bietet hierfür eine wunderbaren Alternative. Chronologisch aufgebaut kann man sich in die Geschichte des Projektes einlesen, da die wichtigen Informationen zentral an einer Stelle gesammelt werden.

Ein berechtigter Einwand ist, daß nicht sichergestellt ist, daß das Blog auch gelesen wird, da man es ja explizit aufrufen muß (Pull-Prinzip), man bei Mails aber relativ sicher sein kann, daß jede Mitteilung auch beim Empfänger ankommt. Das stimmt, aber erhalten bedeutet noch nicht gelesen. Ich will damit nicht das Argument entkräften, denn ich teile die Ansicht auch. Doch wie wäre es mit einer Mailschnittstelle, die neue Blogeinträge einzeln oder aggregiert an einen Verteiler schickt? So könnten sinnvoll E-Mail und Blog als Kommunikationsmittel eingesetzt werden, ohne die bestehenden Vorteile zu verlieren.

Abschließend möchte ich aber noch einmal den wichtigsten Punkt hervorheben: Wie in einer Firma oder in einem Projekt kommuniziert wird ist ein Teil der Kultur der Organisation. Und ein Blog bleibt daher stehts nur ein Mittel zu Zweck.

Also, viel Erfolg und auch Spaß am eigenen Projektblog!

P.S.: Da ich nun nicht der erste bin, der sich zum Einsatz von Blogs in Projekten Gedanken gemacht hat, hier ein paar Links zum Thema:

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.