Ich habe seit längerem bereits keine Beiträge mehr verfasst. Das soll sich nun wieder ändern. Allerdings steige ich hier nur mit einem Verweis auf eine Präsentation von Xing ein, die Traian Kaiser und Mark Weber zum SCRUM Day 2009 vorgestellt haben. Der Informationsgehalt ist ohne Tonspur nicht allzu groß, aber sehenswert ist sie dennoch.
Nachdem die Wikis sich inzwischen in vielen Unternehmen durchgesetzt haben, ist es vielleicht einmal Zeit einen kritischen Blick auf dieses Tool zu werfen.
Ich selbst habe 2005 ein Wiki eingeführt und war damals Feuer und Flamme für das allheilbringende Tool. Kommt doch mit einem Wiki ein echter Web 2.0 –Gedanke auf. Denn ein Wiki ist nach der Einteilung von O’Reilly eine Anwendung mit einem Web 2.0-Gehalt der Stufe 3. (Anwendungen, die nur online existieren und deren Funktionen auf Netzwerkeffekten basieren.) Zentrale inhaltliche Eigenschaft, ist die Entstehung der Inhalte durch die Benutzer. Soweit - so gut. Aber was passiert mit den Inhalten, die einmal in einem Wiki stehen?
Damit es auf Dauer in einem Unternehmen bestand haben kann, ist eine Form der Qualitätssicherung erforderlich. Diese erstreckt sich aber in den meisten Fällen nicht auf alle Bereiche des Wikis. So entstehen mit guter Absicht die unterschiedlichsten Dokumente. Das schöne daran – es können alle mitmachen (das liegt am Wiki). Dies birgt schon die erste Gefahr, dass Inhalte doppelt angelegt werden. Nachdem man es gemerkt hat, ärgert man sich, da die Arbeit nun umsonst war (liegt das auch am Wiki).
Was passiert aber mit den Dokumentationen, die in einem Projekt entstanden sind? Werden diese weiter gepflegt, wenn sich an den Systemen oder Prozessen etwas ändert? Dies geschieht meistens halbherzig – wir alle kennen die Gründe dafür (das liegt definitiv nicht am Wiki). Abgesehen davon, dass man selbst nicht mehr genau weiß, was alles im Wiki steht, hilft es neuen Mitarbeitern enorm sich in ein laufendes Projekt einzuarbeiten.
Binden diese neuen Mitarbeiter vorerst keine Ressourcen aus dem Team und haben dennoch die Möglichkeit einen Überblick zu bekommen – Volltextsuche sei Dank. So kann jeder, der zwei Stunden Ruhe haben, den Neuen mit dem Satz wegschicken: „Das steht doch im Wiki“ (das liegt am Wiki).
Sobald die zwei Stunden vergangen sind und die ersten Rückfragen entstehen, heißt es dann: „Das machen wir schon lange nicht mehr so, das solltest du nachdokumentieren“ (das liegt nicht am Wiki).
Und so bleibt ein Großteil der nicht ganz so häufig gelesenen Dokumentation doch aktuell – aber das liegt natürlich nicht am Wiki. Der Neue im Team hat dann auch den Überblick – nachdem er alles gelesen und nachdokumentiert hat – dank des Wikis.
Ich kann mir ein Arbeiten ohne die Wikis nicht mehr vorstellen. Es ist so einfach abteilungsübergreifend Dokumente zur Verfügung zu stellen, die von allen Beteiligten angereichert werden können.
Welche Inhalte in ein Wiki gehören muss man allerdings vorab festlegen, denn es sinnvoll diese nach Themen zu gliedern. Die Suche liefert bessere Ergebnisse und die Benutzer können die volle Stärke dieses Tools nutzen.
Haben Sie andere oder ähnliche Erfahrungen gemacht? Lassen Sie es mich wissen!
Auf dem Xing Blog habe ich drei Artikel gefunden, in denen Traian Kaiser über die Einführung von Scrum berichtet.
Hintergrund dabei ist natürlich, die damit verbundene Möglichkeit, Kundenwünsche zeitnah umzusetzen und die Ship It!-Strategie besser verfolgen zu können.
Das größte Hindernis bei der Einführung von Scrum bestand wohl darin, die agilen Werte richtig zu kommunizieren und die neuen Rollen den vorherrschenden Jobbeschreibungen zuzuordnen.
Das benötigte Wissen haben die Projektmanager und einige Lead Engineers durch Scrum-Trainings erhalten. Traian Kaiser beschreibt weiter, dass die Prozesse im Unternehmen und der Ablauf der Produktentwicklung angepasst werden mussten - sich die Umstellung aber insgesamt gelohnt hat, und sie nun für die Zukunft gerüstet sind.
So kann also eine Scum-Einführung in einem Unternehmen aussehen. Die beschriebenen Hindernisse, wie das Verinnerlichen der agilen Werte, ist sicherlich eine der größten Herausforderungen für ein Unternehmen, welches nach Scrum arbeiten möchte. Ich habe die Erfahrung gemacht, dass es tatsächlich schwierig ist Scum in Reinform anzuwenden. Daher bediene ich mich vereinzelter Konzepte von Scrum und nenne es Scrumish 
Die Artikel sind alle mal lesenswert und zeigen, dass es nicht so einfach ist, Scrum unternehmensweit einzuführen.
Ich habe auf Slideshare eine interessante Präsentation zum Thema Deployment gefunden. Interessant aus zwei Aspekten. Zum einen, da wir uns derzeit auch mit dem Thema “Releasemanagement” auseinandersetzen und zum anderen, weil Flickr laut der Präsentation zehn Mal pro Tag deployed! Das halte ich persönlich für eine starke Leistung, die sicherlich gut vorbereitet wurde.
In der Präsentation geht Flickr auf die technischen Aspekte ein, die ich interessant finde. Hier kann man sich sicherlich noch die ein oder andere Anregung holen. Das wirklich Spannende liegt aber wieder mal in der Zwischenmenschlichen Kommunikation der Beteiligten - nämlich der Entwickler und der Administratoren. Die zentrale Botschaft lautet hier:
Schaffe eine Kultur, die von Respekt, Vertrauen und einer gesunden Einstellung zu Fehlern geprägt ist und in der das Thema “Schuldzuweisung” ein Fremdwort ist. Nur so können die Entwickler und Administratoren an einem guten Geschäftsergebnis mitwirken.
Dann sind die restlichen technischen Spielereien nur Administrivialitäten:
Die Präsentation ist auch optisch ein echter Hingucker - also viel Spaß damit.
Agile Softwareentwicklung scheint nun endlich aus den Kinderschuhen zu sein. Wenn selbst eine Firme wie Microsoft sich bei der Entwicklung von Windows 7 auf dieses Vorgehen festlegt. So ist es derzeit bei Spiegel-Online nachzulesen. Die Redmonder setzten vor drei Jahren auf das Thema Extreme Programming und versuchten dadurch die Fehler der Vergangenheit zu vermeiden.
So ist Microsoft neben Google und ebay ein weiteres großes Unternehmen, das auf Agilität in der Softwareentwicklung setzt. Dass ich ein großer Freund von Agilen Methoden bin, hat der ein oder andere vielleicht bereits bemerkt. Für mich der Schlüssel zu guter Software, da wir uns in kleinen Schritten dem Ziel nähern. Leider kenne ich aber immer noch Unternehmen, die strikt nach den Phasen der Softwareentwicklung (Analyse, Design, Realisierung und Test) eine SAP-Einführung planen.
Das große Problem dabei entsteht, durch die Aussicht alles Technische umsetzen zu können und die Softwareentwicklung wie den Bau eines Hauses zu sehen. Zumindest hat Microsoft damit eine weitere Lanze für agile Softwareentwicklung gebrochen. Ich hoffe andere Unternehmen folgen dem Beispiel und lassen die Phasenmodelle dort wo sie hingehören – in die 70er und 80er.
