Jetzt ist es aber Zeit das Software Engineering Blog zu Grabe zu tragen. Wollte ich anfangs vorallem zu Themen des Software Engineerings schreiben, sind die Themen mit der Zeit vielfältiger geworden und über den schmalen Bereich des Software Engineerings hinausgegangen, sodaß der Name inzwischen nicht mehr zum Blog paßt. Name und Konzept passen inzwischen nicht mehr zueinander. Weiterhin habe ich in den letzten Monaten auch kaum die Zeit für neue Inhalte gefunden, unter anderem deshalb, weil ich auch wieder begonnen habe für Magazine zu schreiben und mich mit meinen Themen für Konferenzen zu bewerben.

Doch ein Ende kann auch ein neuer Anfang sein. Daher habe ich entschieden, daß Software Engineering Blog einzustellen und mit einem neuen Blog, unter einem neuen Namen, wieder zu beginnen. Mit logbuch@freiheitsgrade werde ich auch in Zukunft bloggen, so wie es die Zeit und die Ideen zu lassen. Inhaltlich wird sich das Blog nicht wesentlich unterscheiden, doch der neue Name spiegelt die Themenbreite besser wieder, als es der aktuelle kann. Auch werden die Artikel wohl eher kürzer sein, als die bisherigen im SWE-Blog.

Das SWE-Blog werde ich irgendwann abschalten und damit auch die meisten Inhalte. Es wird wieder Zeit, daß Vergessen neu zu erlernen. Auch im digitalen Leben.

Kultur ist ein oft gebrauchtes Schlagwort, mit dem ich mich vor einiger Zeit begonnen habe auseinanderzusetzen, als ich mich fragte, was wohl die eigentliche Grundlage für erfolgreiche Projekte ist.

Die obige Präsentation habe ich für den ersten Scrum Day 2010 in München vorbereitet, an dem ich mit dieser Präsentation auf der Reservebank für eventuell ausgefallene Redner teilgenommen habe. Gott-Sei-Dank war dies nicht der Fall und daher werde ich ihn am 17. November auf dem Scrum Day in Berlin halten. Dann aber wohl in einer überarbeiteten Form.

Dadurch ist leider wenig Zeit für das Bloggen geblieben, wobei es doch so viel Interessantes gegeben hat. Spontan fällt mir dabei der Post Glaskugel: Architektur in 2020 von Gernot Starke ein. Fünfzig-fünfzig denke ich dabei. Aber eigentlich doch super, endlich wird IT sexy Ich höre schon auf so manchem Campus Gespräche wie "Mein Freund studiert Software-Architektur!" "Ah, nimmst Du mich mal mit, das finde ich unheimlich interessant und vielseitig." Endlich Schluß mit Situationen wie "Was, Du bist IT'ler? Mit Dir kann man sich doch normal unterhalten...." Es kommen goldene Zeiten auf uns zu!

Nacht!

Was hat aber Unternehmenskultur jetzt mit agiler Entwicklung zu tun? Sehr viel! Liest man sich das agile Manifest durch, kann es nach meiner Meinung so zusammengefaßt werden, daß es für unseren Erfolg wichtiger ist, wie wir miteinander umgehen, als welche detailierten Prozesse wir versuchen einhalten. Wie wir mit einander umgehen, daß lernen wir in unserer Umgebung. Wir sehen, wie die anderen sich in unserer Umgebung verhalten, welche Strategien erfolgreich sind oder zumindest vor Schaden schützen, und passen uns daran an. Das paßt gut zur Definition von Kultur in Organisationen, wie ich sie bei Sonja Sackmann gefunden habe:

Organisationskultur ist die von einer Gruppe gemeinsam gehaltenen grundlegenden Überzeugungen, die deren Wahrnehmung, Denken, Fühlen und Handeln bestimmen und insgesamt typisch für die Gruppe sind.

Ein für uns sehr leicht nachvollziehbares Beispiel in der Softwareentwicklung ist der Umgang mit Fehlern. Defekte, das klingt doch wesentlich neutraler, gibt es in jeder Software, denn Software-Entwicklung ist zu komplex, um keine Fehler zu machen und sei es, daß es ab einem bestimmten Punkte nicht mehr wirtschaftlich vertretbar ist, eine Software gegen jeden Fehler abzusichern. Gute Projekte und Entwicklungsteams unterscheiden sich aber im Umgang mit Fehlern. Keiner macht gerne Fehler, denn das Fehlermachen wird negativ bewertet und oft in der einen oder anderen Form bestraft. Das kann ganz diffizil sein, beispielsweise wenn gleich gesagt wird: „Paß auf, nicht wieder die gleichen Fehler zu machen.“ Neulich habe ich in einem Projekt einen Softwarefehler gefunden und wollte zu dem für die Komponente verantwortlichen Entwickler gehen mit der Bitte, den Fehler zu beseitigen. Er sei im Urlaub sagten mir seine Kollegen, worauf hin ich meinte, daß das schlecht sei, denn er sei der Einzige, der den Fehler beheben könne, sagten sie, daß das vielleicht ja auch gut wäre, dann würde es vielleicht ja auch weniger Fehler geben. Ja, ja, der Truckfaktor. Aber, Wissensverteilung, Risikominimierung und Teamarbeit sind ja jetzt nicht mein Thema. Dieses Beispiel zeigt aber sehr gut, wie der Umgang mit Fehlern symptomatisch für die Kultur in einem Team ist. In einer solchen Umgebung werden Fehler bestraft, was dazu führt, Fehler zu vertuschen, zu leugnen, als nicht so wichtig hinzustellen, als sie zu beheben und daraus zu lernen.

In ihrem Buch „Soft Skills für Software-Entwickler: Fragetechniken, Konfliktmanagement, Kommunikationstypen und -modelle“ haben Uwe Vigenschow und Björn Schneider eine kleine Taxonomie von Fehlerkulturen aufgestellt, in der zwischen funktionaler und dysfunktionaler Fehlerkultur unterschieden wird.

Welche Fehlerkultur herrscht bei Ihnen?

Jetzt gibt es ein neues Buch von Roman Pichler: "Agile Product Management with Scrum", das zuerst auf Englisch bei Addison-Wesley erscheint, da Pichler mittlerweise in Großbritannien lebt. Eine deutsche Übersetzung ist bereits angekündigt und ich hoffe, daß diese von Pichler selber vorgenommen wurde.

Thema des Buches ist agiles Produktmanagement (Produktpolitik). Also all die Tätigkeiten, die bei einer Produktentwicklung notwendig sind, um ein Produkt erfolgreich weiterzuentwickeln.

Leider kann ich noch nicht allzuviel zum Buch selber sagen, da ich es erst heute bestellt habe und nach Angaben von Amazon die Lieferung erst im Mai erfolgen soll. Empfehlen kann ich aber in dem Zusammenhang "Management von IT-Produkten", auf das ich in diesem Blog-Artikel schon einmal hingewiesen habe. Das Buch gibt einen sehr guten Überblick über alle notwendigen Tätigkeiten im Umfeld von IT-Produkten. Der Anspruch des Buches dabei ist es eine Einführung in die Grundlagen zusammen mit einem theoretischen Überblick zu geben. Das gelingt den Autoren auch sehr gut, vorallem da sie sich bewußt sind, daß dies nur die Grundlage für eigenes Handeln sein kann. Pichlers Buch könnte da eine gute Ergänzung sein.

Ab einer bestimmten Ebene sieht man einfach nicht mehr durch, welche Antwort sich worauf bezieht, da sie sich ja nur durch Anzahl der > unterscheiden (Voraussetzung ist natürlich, daß ein vernünftiger Mail-Client benutzt wird ).

Wer das Problem kennt, der sollte sich Quote Colors ansehen. Diese kleine Thunderbird-Erweiterung färbt die Zitate entsprechend ihrer Stellung ein. So bilden sich leicht übersichtliche farbliche Blöcke, die helfen die Übersicht zu bewahren.

Meine Empfehlung, weil es einfach auch gut aussieht und hilft die Übersicht zu bewahren.

Derzeit läuft der Call-Of-Papers für die Konferenz. Wer also eine gute Idee für einen Talk auf Englisch und Zeit am 7. oder 8. Juni haben sollte und noch einen guten Grund sucht, um nach Berlin zu kommen, der kann sich gerne bei Berlin Buzzwords bewerben. Das ist übrigens auch die günstigste Art Zugang zur Konferenz zu bekommen. Momentan sind noch Karten zum Early-Bird-Preis von 297,50 € zu haben.

An dieser Stelle möchte ich noch erwähnen, daß ich bei der Organisation der Konferenz durch die Begleitung der Konferenz auf XING, Facebook und Co. mitwirke. Dies aber aus reinem Enthusiasmus für ein spannendes Thema und somit ohne irgendwelchen finanziellen Vorteile daraus zu erhalten. Der Eintrittspreis ist so ausgelegt, daß er die Konferenzkosten deckt.

Aber bald werden wir schreiben "Berühr mich!" und werden das ganz ernst meinen. Ich habe ja im letzten Artikel schon geschrieben, daß ich der festen Meinung bin, daß die neue Generation von Touch-Screens unsere Arbeit mit Computern verändern werden. Und für uns Software-Entwickler heißt das auch wieder: Auf zu neuen Ufern. Und dabei haben wir ja das letzte Ufer noch gar nicht richtig erkundet. Aber das ist ein anderes Thema.

Multi-Touch für Java!

Hier ist ein Demo, das sehr gut zeigt, was heute auch im Java-Ökosystem möglich ist.

Das Frauenhofer IAO-Institut hat für Java MT4J entwicklet, auf dem das obige Demo beruht. Also, was hält uns auf! Her mit den neuen Ideen!

Oft habe ich bis jetzt beobachtet, daß ein Whiteboard während einer langen Diskussion immer wieder beschrieben wird, um diese dann gleich wieder abzuwischen, da der Platz wieder benötigt wird. Kurz vorher wird noch gefragt: "Alles klar? Kann ich das wieder abwischen?" Dummerweise steckt die Information genau in diesem Moment noch in unserem Kurzzeitgedächtnis und die Wahrscheinlichkeit ist hoch, daß es über dieses nicht hinauskommt. Das heißt nichts anderes, als das es morgen vergessen sein wird.

Wir dokumentieren dieses Wissen nur in wenigen Fällen. Und wenn, dann auch meist falsch. In den meisten Fällen werden einfach Fotos gemacht und diese in irgendeinem Verzeichnis abgelegt. Leider versauern sie dann dort auch. Das ist nicht schade, denn meist sagen die Bilder anderen ohne irgendeinen Kommentar auch nichts.

Aus diesem Grund habe ich vor einiger Zeit eine PowerPoint-Vorlage erstellt, mit denen man sehr einfach Whiteboard-Diskussionen dokumentieren kann. Im Grunde bietet die Vorlage nicht mehr, als ein paar Layoutvorlagen für Bilder in Hoch- und Querformat mit einem Textfeld für Notizen. Hinzu kommt noch eine Titelfolie, auf der man Dinge wie Teilnehmer und Datum bei Bedarf eintragen kann und ein paar weitere Folien für ausführlichere Kommentare.

Die Anwendung

Was wird noch gebraucht? Eine Digitalkamera oder ein besseres Handy. Damit wird das Whiteboard während der Besprechung abfotografiert und die Bilder anschließend in die PowerPoint-Vorlage eingefügt und soweit wie notwendig kommentiert. Anschließend sollte die PowerPoint noch als PDF abgespeichert werden, denn für die Verteilung an Externe sind solche offenen Formate wesentlich besser geeignet.

So lassen sich Diskussionen und Entscheidungen effizient und effektiv dokumentieren und können auf professionell verteilt werden. Und das ohne viel Aufwand.

Beispiel

Auf den Bildern in diesem Artikel ist ein kleines Beispiel für den Einsatz der Powerpoint-Vorlage enthalten und ganz am Ende sind ein paar Download-Links für das Beispiel und die Vorlage selber enthalten.

Beispiel für die Titelseite einer Whiteboard-Dokumentation.

Folie für eine ausführlichere Dokumentation in Textform.

Beispiel für die Verwendung mit einem hochformatigen Bild.

Beispiel für die Verwendung mit einem querformatigen Bild.

Auf der letzten Folie können ein paar Schlußbemerkungen festgehalten werden.

Eine gute Alternative zu dieser Vorlage ist die Dokumentation in einem Blog. In meinem Artikel Tod den Statusmails, es lebe das Blog habe ich hierzu auch schon einmal etwas geschrieben.