Veröffentlicht am

Wie starte ich ein Projekt?

Wie starte ich ein agiles Projekt? Nun, wenn bereits klar ist, dass ein Projekt gestartet werden soll, ist bereits ein wesentlicher Teil getan. Nun stellt sich die Frage, wie es weitergeht. Angenommen das Projekt wird mit Hilfe von Scrum umgesetzt. Wie entsteht nun das Product Backlog? Ab wann ist der Product Owner in das Projekt involviert?

Erst der Rahmen, dann das Bild

Wenn das Projekt gestartet werden soll, müssen grundlegende und richtungsweisende Dinge geklärt werden. Wer muss alles in das Projekt eingebunden werden, also wer sind die Stakeholder?

Welche Ziele verfolgt das Projekt? Welche Ziele sollen eben nicht damit erreicht werden?

Welchen Nutzen hat das Projekt für das Unternehmen oder für den Kunden, der es in Auftrag gegeben hat?

Wer wird am Ende der Anwender sein? Für wen wird es gemacht, also wer gehört alles zur Zielgruppe?

Diese und noch weitere Fragen müssen geklärt worden sein, bevor das Projekt überhaupt gestartet werden kann. Es bietet sich an, eine gleichbleibende Projektstruktur über alle Projekte des Unternehmens hinweg aufzubauen. Das kann in Form eines Project Inceptions, eines Anforderungstableus oder einer Projekt-Checkliste erfolgen.

Von der Idee ins Backlog

Wenn der Rahmen definiert worden ist, kann das Aufnahmen der Anforderungen beginnen. Dabei wird im agilen Umfeld kein Pflichtenheft erstellt, in dem bereits alles fertig ausformuliert worden ist. Dennoch muss auch im agilen Umfeld bereits ein grober Rahmen abgesteckt werden, aus dem sich das initiale Backlog befüllen lässt.

Die Anforderungen werden durch den Product Owner (gerne mit Unterstützung) aufgenommen und erfasst. Hierzu kann er zum Beispiel Epics verwenden oder die Anforderungen in Textform beispielsweise in Confluence erfassen.

Wenn die groben Anforderungen abgesteckt worden sind, dann können die ersten User Stories daraus generiert werden. Der Product Owner wird nun versuchen das Product Backlog so aufzubauen, dass die User Stories für die nächsten 2 bis 3 Sprints bereits im Product Backlog verfügbar sind.

Veröffentlicht am

Agiles und klassisches Projektmanagement verbinden

Brückenbauen – agiles und klassisches Projektmanagement verbinden. Ich persönlich bin der Meinung, dass sich beides nicht ausschließt. Agiles Projektmanagement hilft in vielen Situationen, doch ist es nicht der heilige Gral. Oftmals ist eine Kombination aus agilem und klassischem Vorgehen zielführend. Oder ein Unternehmen setzt agil und klassisch parallel ein – je nach Projekt und je nach Bedarf.

Praxis-Workshop Brückenbauen

Im Praxis Workshop „Wie Du Projekte und Agilität verbindest“ werden mit Hilfe von echten Fallbeispielen Impulse gesetzt, wie eine Kombination aus klassischem und agilen Projektmanagement im Alltag gelebt werden kann. Der Workshop findet über GoTo Trainings statt und die Registrierung erfolgt über eventbrite.

Für Leser dieses Blogs gibt es einen 50 %-Gutschein. Dazu einfach den Code Brueckenbauer_VIP_50 im Bestellvorgang eingeben.

Zur Anmeldung auf Eventbrite

Veröffentlicht am

Verbindung zwischen klassischem und agilem PM

Was sind verbindende Elemente zwischen klassischem Projektmanagement und agilem Projektmanagement? Wieso gibt es scheinbar einen Graben zwischen beiden Ansätzen? Oder sind sowohl klassisches als auch agiles Projektmanagement nur zwei verwandte Ansätze, die beide beherrscht werden müssen und sich nicht gegenseitig ausschließen?

Solche und andere Fragen wurden im Meet-Up „Wie verbindest Du Agilität und klassisches Projektmanagement?“ diskutiert. Der Austausch wurde von Antje Lehmann-Benz und Chris Schiebel organisiert und moderiert.Er stellt dabei den Auftakt zu einer Workshop-Reihe dar, in dem es um das Bauen von Brücken zwischen agilem und klassischem Projektmanagement geht.

Hier geht es zur Workshop-Reihe und der Anmeldung „Wie du Projekte und Agilität verbindest“:

Eventbrite-Seite öffnen

Ich persönlich bin überzeugt, dass sich klassisches Projektmanagement sehr gut mit agilem Projektmanagement verbinden lässt. Die 4 Kernelemente sind meiner Meinung nach:

  • Daily Standups zur täglichen Synchronisation
  • Transparenz schaffen
  • Retrospektiven durchführen
  • Team-Mitgliedern vertrauen schenken

Durch diese kleinen Punkte kann bereits viel bewirkt werden. Der Schritt komplett auf eine agile Arbeitsweise umzustellen ist dann nicht mehr sehr groß. Und vielleicht an der Stelle auch gar nicht mehr nötig.

Agile Praktiken im klassischen Umfeld anzeigen

Veröffentlicht am

Agile Praktiken im klassischen Umfeld einsetzen

Auch in eher klassisch geprägten Projekten lassen sich agile Praktiken leicht einfügen. Die nachfolgenden vier Praktiken lassen sich dabei sehr schnell umsetzen und schaffen einen direkten Mehrwert in der Projektarbeit.

  • Daily Standup durchführen
  • Transparenz in der Planung schaffen
  • Retrospektiven durchführen
  • Team-Mitglieder in Aufwandsschätzungen mit einbeziehen

Daily Standup durchführen

Durch den täglichen Austausch und der Neu-Fokussierung geht das Ziel der Mission nicht verloren. Das Team wächst näher zusammen und es wird eine Transparenz in der Arbeit geschaffen. Werden eher kleinere Projekte von wenigen Personen durchgeführt, kann ein Daily auch mit der ganzen Abteilung über Projektgrenzen hinweg durchgeführt werden.

Transparenz in der Planung

Roadmap, Projektplan und die Aufgabenliste sollten alle Projektmitglieder zugänglich sein. Zudem ist eine gemeinsame Planung ratsam, da das das Wir-Gefühl noch weiter stärkt und das Team an eine gemeinsame Vision glauben lässt.

Retrospektiven durchführen

Zur kontinuierlichen Verbesserung der Team-Abläufe und Arbeitsprozesse. Eine Retrospektive als Leassons Learned am Projektende nur mit dem Ziel, das nächste Projekt besser zu machen, ist nicht hilfreich.

Team-Mitglieder in Aufwandsschätzung mit einbeziehen

Das Team besteht aus Experten, die das meiste Fachwissen haben. Der Projektleiter ist gut beraten, diese Experten mit in die Aufwandsschätzung mit einzubeziehen und auf ihre Schätzungen zu vertrauen.

Veröffentlicht am

Scrum in einem 20%-Projekt

Sie möchten ein Projekt mit Scrum umsetzen und haben nur 20% Kapazitäten dafür? Nachfolgend ein Vorschlag, wie ein Scrum-Projekt mit nur 20% verfügbarer Zeit umgesetzt werden könnte.

Zeitplan

Tagesplan für ein 20%-Projekt mit Scrum
20% Projekt mit Scrum

In dem Beispiel wird für das Projekt ein kompletter Tag fest für ein Projekt geblockt. Hier der Donnerstag. Von 9 bis 17 Uhr steht an diesem Tag alles im Zeichen des Projekts. Andere Aktivitäten sollten vermieden, bzw. höchstens in der Zeit vor 9 Uhr durchgeführt werden.

Backlog Refinement

Das Backlog Refinement wird eingesetzt, um den nächsten Sprint vorzuplanen. Zusätzlich findet eine Sichtung der bestehenden Tickets statt und mit Stakeholdern werden Rückfragen geklärt. Im Beispiel ist das Backlog Refinement dienstags von 10 bis 11 Uhr angesetzt.

Sprint Planning

Die Planung des Sprinttages findet im Sprint Planning statt. Für das Sprint Planning sind 30 Minuten vorgesehen und es findet von 9 bis 9:30 Uhr statt.

Dabei wird das Meeting gemeinsam mit den Stakeholdern durchgeführt und am Ende des Meetings gibt das Scrum-Team ein Commitment ab, was bis 16 Uhr umgesetzt sein wird.

Session I

Von 9:30 bis 12:00 findet die erste Umsetzung der geplanten Tickets statt.

Mittagspause

Die Mittagspause ist von 12 bis 13 Uhr angesetzt. Hier sollte das Projektteam zusammenbleiben und die Zeit für eine gemeinsame Mittagspause nutzen.

Daily Stand Up

Im Zentrum stehen die Fragen: Was wurde bisher umgesetzt und was steht jetzt an? Welche Hindernisse gibt es?

Das Scrum-Team stimmt sich auf den zweiten Teil des Projekttages ein.

Maximal 15 Minuten von 13 bis 13:15 Uhr.

Session II

In der zweiten Session von 13:15 bis 16:00 Uhr werden die übrigen Aufgaben zur Umsetzung des Commitments ausgeführt.

Sprint Review

Den Stakeholdern werden die gemeinsamen Arbeitsergebnisse von 16:00 bis 16:30 Uhr präsentiert. Daraus können neue Aufgaben entstehen, die im nächsten Backlog Refinement weiter diskutiert und geplant werden könnten.

Sprint Retrospective

Das Team reflektiert den Projekttag und arbeitet Optimierungen im Ablauf aus. Für die Retrospektive sind 30 Minuten von 16:30 bis 17:00 Uhr angesetzt.

Bedingungen

  • Konzentriertes Arbeiten am Projekttag muss ermöglicht werden. Unterbrechungen und Kontext-Wechsel vermeiden.
  • Aufgaben lassen sich soweit herunterbrechen, dass sie in den beiden Sessions umgesetzt werden können.
  • Die Stakeholder haben immer Zeit, sowohl beim Sprint Planning, Sprint Review, dem Backlog Refinement als auch bei spontanen Rückfragen am Projekttag zur Verfügung zu stehen.

Welche Erfahrungen haben Sie mit agilen 20%-Projekten gemacht? Hinterlassen Sie einen Kommentar!

Kommentar hinzufügen

 

Kann Scrum in kleinen Projekten eingesetzt werden?

Scrum ist eigentlich dafür ausgelegt, dass sich ein Team komplett auf das Projekt fokussieren kann. Hier wird von einer 100%-Tätigkeit für das Projekt ausgegangen.

Doch es gibt Gründe, weshalb das nicht immer klappt und genau so umgesetzt werden kann. Für solche Projekte soll der hier vorgeschlagene Weg eine mögliche Lösung, um kleinere Projekte dennoch geordnet mit Hilfe von Scrum bewältigen zu können.

Wie kann ein Projekt agil umgesetzt werden, wenn nur 20% Arbeitszeit zur Verfügung stehen?

Wenn nur eine begrenzte Zeit zur Verfügung steht, sollte diese Zeit nach Möglichkeit gebündelt in das Projekt investiert werden. Der hier skizzierte Vorschlag erfordert einen Tag in der Woche, an dem intensiv an dem agilen Projekt gearbeitet wird.

Kann der agile Projekttag auch auf einem anderen Tag als Donnerstag liegen?

In der Skizze liegt der Projekttag auf einem Donnerstag. Allerdings ist das nur ein Beispiel und der Projekttag kann an jedem beliebigen Wochentag angesetzt werden.

Kann ein Scrum-Projekt auch an zwei Tagen in der Woche umgesetzt werden?

In dem vorliegenden Beispiel wird ein 20%-Projekt beschrieben. Ebenfalls ist auch ein 40%-Projekt, bzw. Scrum an 2 Tagen denkbar. Die Sessions würden dann länger gehen. Auch würde mehr Zeit für Planning, Review und Retrospektive zur Verfügung stehen. Wie viel Zeit genau benötigt wird, hängt von verschiedenen Faktoren ab. Ggf. könnte in einem Projekt, dass nur an 2 Tagen pro Woche stattfindet, mit 45 Minuten pro Meeting gestartet werden. In der Retrospektive ist die Zeit dann zu reflektieren und ggf. anzupassen.