Author: danny quick

3

Scrum – ein Erfahrungsbericht von Xing

Veröffentlicht am von danny quick

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.

0

10mal täglich deployen – am Beispiel von Flickr

Veröffentlicht am von danny quick

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:

  1. Vorbereiten der Infrastruktur mittels einer großen Anzahl von Tools wie beispielsweise CFengine,  Bcfg2,  System Imager, Cobbler etc.
  2. Geteiltes Wissen zum Versionsstand.
  3. Automatisierung von Build und Deployment.
  4. Einsatz von Feature flags und private Betas, arbeiten im Trunk.
  5. Visualisierung des Systemzustandes und der Einsatz von Metriken.
  6. Informationsaustausch der Entwickler und der Administratoren.

Die Präsentation ist auch optisch ein echter Hingucker – also viel Spaß damit.

8

Agile Softwareentwicklung – eine weitere Lanze gebrochen

Veröffentlicht am von danny quick

lanzeAgile 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.

0

Von Risiko- und Krisenmanagern

Veröffentlicht am von danny quick

Ich habe eben im Guerilla Projektmanagement Blog einen Beitrag zum Thema „Fehler die Showstopper sind“ gelesen, der mich dazu bringt, dieses Problem in der Firmenkultur nochmal zu thematisieren.

Wie Sven Rimbach in seinem Beitrag erwähnte, gibt es eben Fehler die vor Projektende das gesamte Projekt aus dem Zeitplan werfen.  Hätte man sich also vorher damit auseinander gesetzt, welche Fehler den Projekttermin gefährden, wären sie vermutlich auch nicht in der Ausprägung aufgetreten. Ein einfaches Ursache-Wirkung-Prinzip.

Warum verzichten dennoch so viele Projekte auf eine Top-10 Risikoliste? Ganz einfach, schon in der Antike wurde der Überbringer schlechter Nachrichten geköpft. Also werden die Risiken zwar wahrgenommen, aber ignoriert. Stattdessen werden Pläne ausgearbeitet, wie die aufgetretenen Probleme beseitigt werden können. Die Beteiligten glauben vermutlich sogar sie würden ihre Risiken managen.

So ist es vielleicht an der Zeit den Unterschied einmal deutlich zu machen. Tom DeMarco beschreibt im Buch Bärentango die Begriffe wie folgt:

“Ein Risiko ist ein Problem, das erst noch auftreten muss, und ein Problem ist ein Risiko, das bereits aufgetreten ist.”

Tatsächlich ist da viel Wahrheit dran. Denn jemand er in einem Projekt die ganze Zeit den Teufel an die Wand malt und die “tolle Stimmung” zerstört, der ist nicht gut angesehen. Aber jemand der die fertigen Pläne in der Schublade hat, wenn das „Kind erst in den Brunnen gefallen ist“, wird als Krisenmanager gefeiert.

Jedenfalls ist das der bequemere Weg – solange niemand die Ursachen hinterfragt.