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:
- Vorbereiten der Infrastruktur mittels einer großen Anzahl von Tools wie beispielsweise CFengine, Bcfg2, System Imager, Cobbler etc.
- Geteiltes Wissen zum Versionsstand.
- Automatisierung von Build und Deployment.
- Einsatz von Feature flags und private Betas, arbeiten im Trunk.
- Visualisierung des Systemzustandes und der Einsatz von Metriken.
- Informationsaustausch der Entwickler und der Administratoren.
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.
