*SHIFT_resources - das Spiel mit den offenen Karten

*SHIFT_resources - so oder so ähnlich würde der Claim auf den Werbeplakat von Nissan aussehen, wenn ...

Erfahrungsgemäss ist mit der Einführung von agilem Vergehen á la Scrum das Offenlegen der Resourcen am Projekt ein zweiseitiges Schwert, weil ...

Der Product Owner trifft pro Iteration bei der Planung und Vorführung, wahlweise auch bei der Retrospective, auf das gesamte Team. Damit ist eines sofort ersichtlich - Resource-Shifting beim Software Anbieter - Pluspunkt!

Den Minuspunkt gibts beim Software Anbieter - der muss sich sehr wohl überlegen, ob und wie oft er Resourcen auf dem Projekt wechselt. Auch ein Resource-Sharing wird schnell ersichtlich, denn bei der Planung wird das Team dem Rechnung tragen, wenn 1, 2 oder 3 Entwickler nur 80% am Projekt arbeiten.

Zusammenfassend kann man sagen: wer ein Projekt nach SCRUM abwickelt, spielt bezüglich Resourcen mit offenen Karten - man muss!

Scrum Einführung - leider erfolglos

Gestern war für mich kein sehr erfolgreicher Tag, denn ich konnte ein Projekt-Team nicht davon überzeugen, agile zu arbeiten ...

Es geht um eine Webapplikation, die entwickelt werden soll. Der Funktionsumfang ist klar, Zeit und Budget auch. Das Projekt dazu wurde im Oktober 07 gestartet, Entwicklungsbeginn war Anfang Dezember. Das Projekt soll Ende Februar 08 abgeleistet sein. Ich arbeite seit Entwicklungsbeginn an diesem Projekt. Vorgehen: Wasserfall!

Projektteam (fix):

• 2 Software Engineers
• ein Projektleiter und einen Kunden-Projektleiter

sporadisch (auf Abruf):

• bis zu 3 Publisher
• ein Designer
• ein Flash-Spezialist

Alle Teammitglieder arbeiten an diversen anderen Projekten, sind also nicht 100% auf diesem Projekt.

Man weiss per heute bereits, dass dieses Projekt nicht in Zeit und Budget realisiert werden kann. Darum wurde die Entwickel-Crew gestern um 2 Software Engineers aufgestockt, d.h. +50%. Man geht davon aus, dass man damit nur halt so lang brauchen wird, so die Annahme.

Ich habe die Gelegenheit genutzt, um dem Team SCRUM vorzustellen. Ziel sollte es sein, dem Team zu vermitteln, dass man durch SCRUM das Risiko eines Misserfolgs minimieren kann, indem man regelmässig in definierten Intervallen lauffähige Funktionen entwickelt und dem Kunden zeigt. Damit stellt man einen engen und nachhaltlichen Kontakt zum Kunden her, schafft Vertrauen und fördert die Kommunikation und gibt dem Kunden die Chance, früh auf neue Bedürfnisse zu reagieren, neu Ideen einzubringen, sie zu priorisieren, etc.
Letztendlich fanden alle die Idee vom agilen Arbeiten sehr interessant, doch niemand hatte genug Vertrauen und Mut, es jetzt zu versuchen. Ausschlaggebend war, dass man einen so engen Kontakt zum Kunden besser unterbindet, weil man weiss, dass immer wieder neue Anforderungen erhoben werden, wenn man frühzeitig Funktionen präsentiert - GENAU! Das ist der Unterschied - bei agilem Arbeiten heisst es "Changes are welcome!". Das Team hat gegen SCRUM gestimmt ...

Daraufhin habe ich den Kontakt zu Kollegen aus der "agilen Ecke" gesucht - mein Misserfolg ist bekannt und auch erklärbar:

• Druck
• Ungewissheit
• Transparenz
• Disziplin
  

Das sind so die grössten Hindernisse, die bei der Einführung von SCRUM im Weg stehen. Nächsten mal werde ich auf diese Punkte deutlicher eingehen ...

Was heisst agiles Vorgehen?

Nach dem agilen Manifest gilt das Prinzip, dass man dem Kunden in regelmässigen Intervallen funktionsfähige, getestet, dokumentierte und brauchbare Artefakte liefert, die einen Mehrwert darstellen.

Wie kommt man von einem klassischen Wasserfall zum agilen Projekt?
Ein Praxisbericht: Schritt 1: man macht den Wasserfall zunächst iterativ.

Bei einem interativen Wasserfall werden pro Iteration Artefakte erarbeitet, die in der kommenden Iteration weiterverarbeitet oder verfeinert werden (Bild oben). Damit bleiben alle Nachteile von phasen- orientiertem Projektvorgehen erhalten: Abkapseln von Anaytikern, Kunden, Testern und Entwicklern sowie Behinderung der direkten Kommunikation aller Beteiligten. (A=Analyse,D=Design,P=Produktion,T=Test)

Da man mit dem iterativen Wasserfall jedoch keine funtionstüchtigen Artefakte mit einem Mehrwert für den Kunden liefert, kommt man zwangsläufig zum Schritt 2: der iterative Mini-Wasserfall (Bild unten).

Um dem agilen Manifest gerecht zu werden und die klassische Vorgehensweise beizubehalten, macht man alle Phasen pro Iteration.
Auch hier gewinnt man nicht viel, denn erfahrungsgemäss ist die Zeit am Ende einer Iteration sehr knapp und Testing fast unmöglich. Dazu kommt, dass die Teammitglieder so noch immer entkoppelt arbeiten und wichtige Kommunikation ausbleibt.

Untersuchen Sie genau Ihre Vorgehensweise. Finden Sie sich teilweise in diesen Aussagen wieder, dann haben Sie kein agiles Vorgehen!