3

10 Software-Auswahlkriterien für Lean Projekte

Gastbeitrag von Philip Schilling

Lean Project Management bedeutet nach allgemeiner Auffassung, Werte für den zentralen Stakeholder zu schaffen und dabei Verschwendung so gut wie möglich zu vermeiden. Nach ISO 10006 sind Stakeholder eines Projektes alle Personen, die ein Interesse am Projekt haben oder von ihm in irgendeiner Weise betroffen sind. Dabei arbeiten aktive Stakeholder direkt am Projekt mit (z.B. Projektleiter, Teammitglieder) oder sind direkt vom Projekt betroffen (z.B. Kunden, Lieferanten, Geschäftsführung). Insbesondere dieser Personenkreis muss durch entsprechende Werkzeuge in der für das Lean-Management typischen Fokussierung auf ergebnisorientiertes Handeln unterstützt werden.

Weiterlesen

0

Was zeichnet Hochleistungsteams aus? II

SiegertypenIn meinem Blogeintrag vom 30. Juli 2010 habe ich auf eine Ausgabe Abenteuer Wissen vom ZDF verwiesen, in der es um Hochleistungsteams geht. Leider hat das ZDF die Mediendateien aus der Mediathek entfernt, so dass ein Zugriff nicht mehr möglich war. Heute habe ich zufällig auf YouTube die Videos gefunden und möchte Sie hier nochmal zur Verfügung stellen. Auch 3,5 Jahre nach Veröffentlichung hat das Thema nichts an Aktualität verloren.

Weiterlesen

2

Hilft agiles Projektmanagement dem Weihnachtsmann?

Santa

Ich habe mich vor ein paar Tagen mit dieser Frage beschäftigt, als mein Sohn mir wieder seine Weihnachtswünsche mitgeteilt hat, die vollkommen von der ursprünglichen Planung abweichen.  Dabei ist mir erst die Nähe zum Projektgeschäft aufgefallen und die gemeinsamen Probleme, wenn man die Sache nicht richtig angeht.

Fangen wir mal vorne an. Im Rahmen einer Anforderungsanalyse  (Blättern durch den Spielzeugkatalog) entstehen erste Ideen. Die daraus entstandenen Anforderungen werden bei uns in ein Lastenheft (Wunschzettel) geschrieben.  Dann folgt eine kurze Diskussion darüber, dass nicht alle Anforderungen in der gegebenen Zeit umgesetzt werden können, da die Ziele vollkommen überzogen sind. Zur Umsetzung aller Anforderungen müssten noch weitaus mehr Meilensteine gesetzt werden als in dem ursprünglichen Zeitplan (Nikolaus und Weihnachten). Meilensteine wie Ostern, Geburtstag und nochmal Weihnachten… Also haben wir den Rahmen festgelegt und uns auf den Liefertermin geeinigt – Weihnachten eben.

Das Projektteam (meine Frau und ich) hat also versucht die Anforderungen umzusetzen und dabei in täglichen Meetings (Abends auf dem Sofa) den Projektfortschritt untereinander abgestimmt.  So agil sind wir schon. Die Rückkopplung zum Kunden habe ich übernommen, indem ich hin und wieder mal nachgefragt habe, ob die Anforderungen noch stabil sind. Tatsächlich habe ich vor ein paar Tagen festgestellt, dass sich die Wünsche vollkommen geändert haben.   Nun sollte es ja im agilen Projektumfeld keine große Schwierigkeit geben, wenn sich die Anforderungen ändern. Vermutlich steht auch ein Scrum-basiertes Projekt vor dem Aus, wenn die Anforderungen sich um 180° drehen.  Wir haben so allerdings noch die Möglichkeit Teile der ursprünglichen Planung zu verwerfen und auf die neuen Anforderungen einzugehen. Das Change-Management  wird auch wieder auf dem Wunschzettel durchgeführt. Dabei ist mir aufgefallen, dass es sinnvoll ist auch bei so kleinen Projekten die Anforderungen mit einem Datum zu versehen.

Für mich stellt sich nun die Frage, ob der Weihnachtsmann agil arbeiten  sollte oder eher klassisch Phasenorientiert. Ich bin zu der Überzeugung gekommen, dass ein agiles Vorgehen auch hier hilft. Denn neben den geänderten Anforderungen hat man so großen Einfluss auf die Erwartungshaltung des Kunden – und das ist nicht nur Weihnachten wichtig.

4

Was zeichnet Hochleistungsteams aus?

Siegertypen

Wie Hochleistungsteams  funktionieren wurde vorgestern in der ZDF-Sendung “Abenteuer Wissen” am Beispiel von Regatta-Segeln erklärt. Der Beitrag ist noch online verfügbar und weist aus meiner Sicht viele Parallelen zur agilen Softwareentwicklung auf. Insbesondere die Retrospektive wurde in dem Beitrag als einer der zentralen Schlüssel für den Erfolg von Teams identifiziert. Dabei gilt sowohl die Selbstreflektion jedes Einzelnen, als auch die der ganzen Gruppe.

Bevor aus einer Gruppe allerdings ein Team wird ist es notwendig, dass alle ein gemeinsames Ziel vor Augen und auch verinnerlicht haben. Das heißt, in den Köpfen der Mitglieder ist zum einen ihre Teilaufgabe hinterlegt, zum anderen aber auch das Big Picture. (Für das Big Picture in der Softwareentwicklung eignet sich der “Elevator Pitch” hervorragend).

Wichtig ist für die Teambildung der richtige Charakter der Mitglieder.  Man braucht Leute mit den richtigen Wesenszügen und Kompetenzen, denen man vertrauen kann. Alle müssen sie unter einer klaren Führung zusammenarbeiten. Ein Team ist kein Ort der Selbstprofilierung oder individueller Machtstrategien.

Wer nähere Informationen zu dem Thema sucht, findet sicherlich was auf dem Blog von Winfried Berner. Dort habe ich einen interessanten Beitrag über die Geheimnisse gut funktionierender Arbeitsgruppen gefunden, der das Thema aus Sicht von Projektteams erläutert.