Agiles Projektmanagement 1-0-1 – Alles, was Sie über agiles Arbeiten wissen müssen

workshop
Share on linkedin
Share on facebook
Share on twitter
Share on reddit

Wollten Sie schon immer mal einen einfachen und verständlichen Überblick über agile Arbeitsweisen wie Scrum und Kanban bekommen? Hier ist Ihre Lösung: Lesen Sie unseren Guide zum Agilen Projektmanagement und finden Sie anwendbare Tipps und Kniffe – Agenda:

  1. Was ist agiles Projektmanagement?
  2. Welchen Mehrwert bietet agiles Management?

     

  3. Das agile Lexikon für Scrum und Kanban
    3.1 Scrum und seine Komponenten
    3.1.1 Die Rollen im Scrum Projektmanagement
    3.1.2 Die Tools/Artefakte im Scrum Projektmanagement
    3.1.3 Die Ergebnisse
    3.1.4 Besprechungen und Meetings im Scrum Projektmanagement
    3.1.5 No-Gos und Probleme im Scrum Projektmanagement
    3.2 Kanban und seine Schwerpunkte
    3.2.1 Tools und Methodik im Kanban
  4. Agiles Coaching und Agile Beratung
  5. Ausbildung in Scrum, Kanban und für agiles Management allgemein
  6. Agiles Management und klassische Projektentwicklung im Vergleich
  7. Bücher zum Thema agiles Arbeiten und agiles Management
  8. Die 10 besten Tools für agiles Projektmanagement
  1. Was ist agiles Projektmanagement?

Agiles Projektmanagement prägt die agile Produktentwicklung und nutzt agile Methoden wie Scrum und Kanban. Das Attribut “agil” bezieht sich auf die hohe Effektivität, die kennzeichnend für agiles Management ist. Es setzt hier bereits in der Bezeichnung einen erkennbaren Kontrapunkt zum klassischen Projektmanagement. Agiles Management zeichnet sich durch einen iterativen Prozess aus, bei denen im Projektverlauf kontinuierlich Ergebnisse produziert werden und das Planungsteam sich selbst eigenverantwortlich managt. Agiles Arbeiten stammt ursprünglich aus der Softwareentwicklung, findet aber aufgrund seiner hohen Flexibilität zunehmend Eingang in andere Arbeitsbereiche. Eigene Felder bilden auch das agile Coaching und die agile Beratung, die sich mit der Vermittlung und Entwicklung von Grundlagen für die agile Organisation befassen. Der agile Coach ist bei Scrum Schulung und Scrum Training sowie Ausbildungen in Kanban gefragt, da immer mehr Unternehmen sich für agile Organisation interessieren. Agiles Arbeiten kann auch flexible verschiedene Managementansätze kombinieren, indem einzelne klassische Elemente berücksichtigt oder Prozessverbesserungs-Ansätze wie DevOps (Kunstwort aus Development und IT-Operations im Bereich der Softwareentwicklung) ergänzt werden.

2. Welchen Mehrwert bietet agiles Management?

Agile Produktentwicklung und agiles Management haben nachweislich Vorteile gegenüber klassischen Projektmanagementansätzen. Das zeigen verschiedene Studien, die klassisches und agiles Arbeiten miteinander vergleichen. So zeigte eine Studie von CA Technologies aus dem Jahr 2016 beispielsweise, dass

  • eine agile Organisation bei Projekten die Zeit zum Ausbau neuer Projekte um 32 Prozent von 12 auf 8 Wochen reduziert.
  • agiles Arbeiten die Zeit zur Entwicklung und Veröffentlichung neuer Apps von 13 auf 8,5 Wochen um 34 Prozent reduziert.
  • DevOps eine Reduzierung der Zeit von 11 auf 8 Wochen schaffen.
  • agiles Management die Mitarbeiterproduktivität um 42 Prozent steigert, DevOps um 38 Prozent.
  • agile Organisation die operative Effizienz um 37 Prozent, DevOps um 40 Prozent steigert.

Eine Studie der GPM Deutsche Gesellschaft für Projektmanagement e.V. aus dem Jahr 2015 belegt unter anderem, dass

  • 50 Prozent der Anwender durch agiles Arbeiten ihr Unternehmen erfolgreicher als andere Unternehmen einschätzen.
  • 80 Prozent der Befragten Effizienz- und Ergebnisverbesserung durch agile Organisation sehen.
  • agiles Management eine höhere Erfolgsquote hat als klassisches Projektmanagementmethoden.
  • durchgängiges agiles Arbeiten erfolgreicher ist als die selektive Anwendung von agilen Methoden.

Scrum Projektmanagement und Kanban sind die beiden Hauptrichtungen für agiles Arbeiten. Deshalb geben wir hier einen Überblick über agiles Management mit den agilen Methoden Scrum und Kanban.

Scrum und seine Komponenten

Das Wort Scrum bezeichnet im angelsächsischen Bereich “Gedränge” oder “Rummel”. Es beschreibt auch eine Technik im Rugby, die außerordentliche Teamleistungen ermöglicht. Die Erfinder von Scrum die sollen diese Teamfokussierung im Sinn gehabt haben, als sie die Bezeichnung Scrum aufnahmen.

Die Scrum-Welt besteht beim Personal aus einer Trias, die im Vergleich mit dem klassischen Projektmanagement ohne einen Projekteiter auskommt. Diese personelle Dreiteilung bedingt die hohe Selbstständigkeit von Scrum Teams. Scrum Projektmanagement arbeitet mit klaren und einfachen Rollenverteilungen und nur sehr wenigen fixen Elementen. Neben den drei Rollen gibt es drei Ereignisse und vier Artefakte. Die wenigen für Scrum festgelegten Regeln werden allerdings strikt eingehalten und umgesetzt, um das Scrum Projektmanagement erfolgreich zu machen.

Der iterative Charakter von Scrum besteht in einer ständigen Anpassung des Prozesses während der Produktentwicklung. Hier sind die Stichworte Transparenz, Überprüfung und Anpassung wichtig.

Transparenz heißt dabei, dass der Status Quo und Hindernisse eines Projektes regelmäßig und für alle sichtbar dokumentiert werden.

Überprüfung steht für eine fortlaufende Ablieferung und Bewertung von Projektergebnissen und Funktionalitäten.

Anpassung meint in diesem Kontext, dass Anforderungen an das Produkt, Pläne und Vorgehensweisen nicht feststehen, sondern kontinuierlich und detailliert angepasst werden. Das Scrum Projektmanagement kann die Komplexität von Aufgaben nicht per se reduzieren, sie aber in kleinere und weniger komplexe Bestandteile aufteilen.

Das Scrum Projektmanagement hat seine Wurzeln in den Arbeiten der beiden Japaner Ikujiro Nonaka und Hirotaka Takeuchi. Mit der 1990er Jahre nahmen verschiedene andere Personen den Scrum Gedanken auf und entwickelten die Methode in der Softwareentwicklung weiter. Das erste Buch zum Scrum Projektmanagement und seiner Methode erschien 2001 von Ken Schwaber und Mike Beedle.

Verwandt ist agiles Management allgemein und auch Scrum mit den Grundprinzipien des Lean Management. Bei diesem “schlanken Management” wird eine größere Wertschöpfung vor allem durch eine optimierte Zusammenarbeit erreicht.

Die Rollen im Scrum Projektmanagement

Unterschieden werden im Scrum Projektmanagement diese Rollen:

Product Owner – das ist der Kunde/Anwender beziehungsweise deren unmittelbarer Repräsentant, der seine Vorstellungen für die agile Produktentwicklung in das Projekt einbringt und den ROI (Return of Investment) verantwortet. Er ist damit insgesamt verantwortlich für den wirtschaftlichen Erfolg des Produkts und entwickelt die Produktvision sowie die Anforderungen an das Produkt. Er managt die Stakeholder. Unter anderem steht er idealerweise während des Sprints dem Development Team zur Verfügung, um etwaige Fragen zu beantworten. Er nimmt am Ende die Product Increments als Sprint-Ergebnisse ab.

Development Team – hier findet die eigentliche Entwicklung und Projektarbeit eigenständig und funktionsübergreifend statt. Die Aufgaben können wie folgt zusammengefasst werden: Das Entwicklungsteam leistet selbstständig die eigentliche Entwicklungsarbeit, die es gemeinsam verantwortet. Es sind hier im Idealfall im Team alle technischen Kompetenzen vertreten, um die Entwicklungsarbeit optimal umzusetzen (Cross Functionality). Das Team verhandelt mit dem Product Owner den Aufgabenumfang der einzelnen Inkremente (Sprints). Es hat die Verantwortung dafür, wie die Aufgaben tatsächlich erledigt werden. Das Team besteht aus höchstens 9 und mindestens 5 Mitgliedern.

Scrum Master – er ist der agile Coach und Teamentwickler, der dem Entwicklungsteam beisteht und für eine Optimierung der Arbeitsumgebung sorgt. Außerdem stellt er organisatorische Behinderungen und Störungen des Arbeitsablaufes ab. Seine Aufgaben lassen sich so beschreiben: Er fungiert als Moderator und Teamentwickler des Entwicklungsteams. Er unterstützt die Team Selbstorganisation. Es gehört auch zu seiner Funktion, für die Einhaltung der Scrum Regeln und störungsfreies agiles Arbeiten zu sorgen. Er gilt als Organisationsentwickler für die agile Organisation, der in seinem Unternehmen für Scrum-freundliches Umfeld und entsprechende Verbesserungen eintritt. Im organisatorischen Bereich kümmert er sich um die Stakeholder des Unternehmens. Auch kann es ihm obliegen, in Teilen eine Scrum Schulung und Einführung zu gestalten.

Was der Scrum Master im Scrum Projektmanagement nicht ist: Er ist kein Projektleiter und hat keine autoritäre Weisungsbefugnis gegenüber dem Team. Er sollte deshalb auch nicht aus der Management Ebene des Unternehmens stammen.

Große und kleine Scrum Projekte und das angepasste Scrum Projektmanagement:

Bei größeren Scrum-Projekten sind mehrere Development Teams üblich, die parallel arbeiten. Hier betreut ein Scrum Master unter Umständen mehrere Development Teams gleichzeitig. Dagegen gibt es für jedes Team einen Product Owner sowie übergeordnet einen Chief Product Owner. Dieser trägt die Gesamtverantwortung für das Projekt und hat die finale Entscheidungshoheit gegenüber den anderen Product Ownern.

Die Tools/Artefakte im Scrum Projektmanagement

Product Backlog / Produktanforderungen

Das Scrum Projektmanagement startet mit der Erstellung des Product Backlogs. Es gilt als die zentrale Sammelstelle für alle Anforderungen an das Produkt und unterliegt der Verantwortung des Product Owners.

Das Product Backlog ist eine priorisierte Liste mit User Stories. Die User Stories sind Wünsche und Forderungen an das Endprodukt, die vom Product Owner dokumentiert werden. Dabei geht es um eine ausgearbeitete, möglichst genaue Beschreibung der Anforderungen und nicht etwa nur um Stichpunkte oder Listen. Je genauer das Product Backlog gefasst wird, desto besser kann das Entwicklungsteam damit arbeiten und die Vorteile durch die agile Organisation erlebbar machen. Es geht hier am Anfang noch nicht um die technische Umsetzung des Produkts. Diese wird später im Sprint Backlog thematisiert.

Priorisierung wichtig

Sobald der erste Teil von Anforderungen ermittelt worden ist, werden die User Stories in einem nächsten Schritt priorisiert, also nach ihrer Wichtigkeit geordnet. Die oberste User Story ist demnach die, die der Product Owner zuerst umgesetzt sehen möchte. Das Kriterium für die Priorisierung ist üblicherweise der Geschäftswertbeitrag, den die Umsetzung der jeweiligen User Story dem Unternehmen liefert.

Das Scrum Projektmanagement ist zeitlich dadurch charakterisiert, das in jedem Entwicklungszyklus (Sprint) eine vom Development Team festgelegte Anzahl der obersten User Stories aus dem Product Backlog in einem Product Increment umgesetzt wird. Um das erreichen zu können, müssen die User Stories im obersten Bereich vom Arbeitsaufwand so gestaltet werden, dass ihre Realisierung in den kurzen Sprintzyklen möglich wird. Der Ausarbeitung der User Stories kommt hier größte Bedeutung zu.

Weiter unten im Product Backlog sammeln sich Einträge unterschiedlichster Größe: Etwa weitere User Stories, Epics als sehr umfangreiche User Stories und Themes als User Stories, die zu einem gemeinsamen Themenbereich gebündelt werden.

Sobald diese Einträge in den oberen Bereich des Product Backlog verschoben werden, müssen auch sie in fein gegliederte User Stories zerteilt werden, um ihre Umsetzbarkeit sicherzustellen. Auch an dieser Stelle zeigt sich, dass im Scrum Projektmanagement kontinuierlich gearbeitet wird und einzelne Prozesse immer wieder optimiert werden. Diese dauerhafte und fortwährende Optimierung ist typisch für agiles Arbeiten sowie agile Organisation. Sie macht agile Produktentwicklung so effizient und so exakt anpassbar an die Vorstellungen des Anwenders.

Sobald eine User Story in die technische Umsetzung überführt wird, scheidet sie sie aus dem Product Backlog aus und weiter unten aufgeführte Einträge rücken nach oben nach.

Das Product Backlog ändert sich fortlaufend. Aber auch andere Entwicklungen haben Einfluss auf Product Backlog. Neue User Stories ergeben sich aus den vorhergehenden Ergebnissen der Umsetzung. Hier ändert sich dann die Priorisierung aufgrund sich ändernder Rahmenbedingungen. Manches, was zunächst wichtig erschien, wird jetzt unwichtig. Für das Produkt als unwichtig erkannte User Stories werden aus dem Product Backlog entfernt. Die sorgfältige Führung und Anpassung des Product Backlogs ist ein Herzstück für erfolgreiches Scrum Projektmanagement.

User Stories – Die Einträge im Product Backlog

Das wichtigste Kriterium bei der Erstellung und Gestaltung des Product Backlogs ist die Perspektive des Kunden oder Anwenders. User Stories geben dem Anwender die Möglichkeit, in seinen Worten auszudrücken, was er sich wünscht und vorstellt. Das Wort Story steht im Scrum Projektmanagement tatsächlich für eine Geschichte, die der Anwender schreibt. Agiles Arbeiten macht hier ein Eingehen auf die Anwenderperspektive möglich, weil dieser so intensiv in den ganzen Prozess einbezogen wird und fortwährend dabei ist. Ein Scrum Training und eine Scrum Schulung werden stets großen Wert darauf legen, diesen Aspekt für agile Produktentwicklung zu betonen. Er ist kennzeichnend für agiles Management und einer der großen Vorzüge in diesem Feld.

Deshalb werden die Anforderungen an das Produkt in Form von User Stories erstellt und in das Product Backlog eingetragen. Während bei der Einführung von Scrum die technische Umsetzung der Anforderungen noch in das Product Backlog eingetragen wurde, wird das heute anders gehandhabt. Technische Aspekte und Fragen der Umsetzung durch das Team gehören ins Sprint Backlog, wo sie einen festen Platz haben.

Auch die Gestaltung der User Stories folgt einfachen, aber festen Regeln wie sie allgemein wichtig für agiles Management sind.  Eine User Story soll die Anteile

  • Rolle
  • Funktionalität
  • Geschäftswertbeitrag

berücksichtigen. Es geht dabei allgemein um den Nutzen und den Mehrwert für dem Anwender. So können Wünsche des Kunden oder Stakeholders beschrieben werden, ohne das technische Vorkenntnisse vorhanden sein müssen. Auch besticht das Scrum Projektmanagement durch seine Einfachheit und seine Nähe zum Kunden-/Anwenderwunsch, etwas, dass agile Organisation so attraktiv für viele Unternehmen macht. Die Umsetzbarkeit einer User Story richtet sich an den INVEST-Aspekten aus:

  • Independent
  • Negotiable
  • Valuable
  • Estimable
  • Short
  • Testable

Oder auf Deutsch, wie folgt: Verhandelbar, wertvoll, abschätzbar, kurz und testfähig.

Auch die drei C’s sind Garanten für ein gute User Story:

Card – Die wichtigsten Daten einer User Story kommen auf eine Karte festgehalten. Das sind die Priorität, die Akzeptanzkriterien und der Arbeitsaufwand für die Umsetzung einer User Story. Dieser wurde gesondert in einer Schätzklausur ermittelt.

Conversation – Der Product Owner und das Development Team tauschen sich ausführlich über die User Story aus, so dass deren Sinn und Ziel von allen verstanden werden kann.

Confirmation – Akzeptanzkriterien werden festgehalten, unter deren Einhaltung in entsprechenden Akzeptanztests der Product Owner am Ende die Umsetzung der User Story im Product Increment bestätigt und abnimmt.

Eine ideale Beispiel-User-Stroy sieht daher wie folgt aus (Beispiel ist die Entwicklung einer Textverarbeitungssoftware): “Als Autor möchte ich nach dem Start der Anwendung mein zuletzt bearbeitetes Dokument sehen, um Zeit zu sparen.”

Agiles Schätzen – Die Aufwandsbewertung

Eine entscheidende Komponente für jede Planung ist das Abschätzen des Arbeitsaufwandes, der hinter den Einträgen im Product Backlog steckt. Die Schätzung vermittelt einen ersten Eindruck dazu, welchen zeitlichen Umfang Arbeiten im Projektverlauf haben können.

Im Scrum Projektmanagement verzichtet man dabei auf konkrete Vorhersagen zu Arbeitsstunden. Agiles Arbeiten beschränkt sich hier auf die Bestimmung von relativen Größen. Man vergleicht dabei die Größe der einzelnen Einträge untereinander. Durch die relativen Aufwandsgrößen ist es einfacher, flexibel Pläne an geänderte Rahmenbedingungen anzupassen, was agile Produktentwicklung im besonderen Maße leisten kann.

In der Schätzklausur wird jeder Eintrag im Product Backlog eingeschätzt und bewertet. Für die Beschreibung des Aufwands werden Story Points eingesetzt, die meist in einer Skalierung nach Fibonacchi ausgedrückt werden – 1,2,3,5,8,13,21,34. Auch Kleidergrößen kommen manchmal anstelle der Story Points zum Einsatz: XS, S, X, XL und so weiter.

Sprint Backlog – Der Weg im Detail

Zu Beginn jedes Sprints werden die Einträge aus dem Product Backlog ausgewählt, die im aktuellen Sprint bearbeitet und abschließend in ein auslieferbares Produkt Increment überführt werden sollen. Auslieferbare Produkte sind funktional in einem gewissen Rahmen abgeschlossen und wurden getestet.

Ausgewählt wird im Sprint Planning Meeting. Daran nehmen das Team, der Product Owner und der Scrum Master teil. Das Entwicklungsteam hat das letzte Wort zu der Frage, welche Einträge im kommenden Sprint bearbeitet werden sollen. Es kann sich dabei außer im ersten Sprint an der in den vorangegangenen Sprints erzielten Entwicklungsgeschwindigkeit – Velocity orientieren.

Zur Optimierung für agiles Management wird das Sprint Backlog als sogenanntes Taskboard an einer gut sichtbaren Position im Arbeitsbereich zu platziert. Links werden die priorisierten und umzusetzenden User Stories gelistet, rechts die notwendigen konkreten Arbeiten für die Umsetzung. Es gibt dann eine weitere Spalte für die Arbeit, die gerade gemacht wird und eine für solche, die erledigt ist. (Work in Progress/ Done). Auch hier beweisen das Scrum Projektmanagement und die agile Organisation ihre Überlegenheit in der einfachen wie effektiven Visualisierung, die jederzeit erkennen lässt, wo das Projekt steht. Für örtlich verteilte Team sind softwarebasierte Sprint Backlogs üblich. Ein Taskboard kann beispielsweise wie folgt aussehen:

Das Sprint Backlog

Es listet die Einträge, die im laufenden Sprint bearbeitet werden sollen, nachdem sie dem Product Backlog entnommen wurden. Hier werden auch die technischen Maßnahmen (Tasks) zur Umsetzung und Implementierung beschrieben. Das Sprint Backlog wird vom Product Owner und vom Entwicklungsteam gestaltet.

Die Abläufe im Scrum Projektmanagement

SprintingSprints sind zeitliche Entwicklungsintervalle für Projektergebnisse. Ein Sprint kann zwei, drei oder maximal vier Wochen lang umfassen. Kürzere Sprints schaffen gerade in komplexen Produktentwicklungen die Grundlage für agiles Arbeiten.

Sprint Burndownn Chart der Arbeitsfortschritt im SprintDas Sprint Burndown Chart visualisiert den noch verbleibenden Arbeitsaufwand und zeigt den Status quo im Projekt. Ein Sprint Burndown Chart sieht beispielsweise wie folgt aus:

Bildergebnis für sprint burndown chart

 

Velocity / Die ArbeitsgeschwindigkeitDie Velocity erfasst die Story Points von User Stories, die das Team in einem Sprint in einem Product Increment umgesetzt hat. Hieraus lassen sich Velocity Werte-errechnen. Gemittelt können die Velocity-Werte eine wegweisende Größe sein, um Restprojektlaufzeiten immer wieder abzuschätzen und zu bewerten.

Die Ergebnisse

Definition of Done

Sie stellt einen strengen Maßstab dafür dar, wie ein Sprint als erfolgreich bewertet wird. Er ist nur dann ein Erfolg, wenn alle User Stories in ein Product Increment umgesetzt wurden. Dieses wird das im Sprint Review präsentiert.

“Definition of Done” steht konkret für Kriterien, welchen alle umgesetzten User Stories im Product Increment unterworfen werden. Sie wurden vom Development Team nach Rücksprache mit dem Product Owner definiert und stellen die Qualität des Produktes sicher.  Solche Kriterien sind etwa:

  • Die Akzeptanzkriterien der User Stories wurden erfüllt.
  • Die Release-Dokumentation ist fertiggestellt.
  • Das Product Increment ist getestet worden.
  • Definierte spezielle Richtlinien, Standards und Normen wurden eingehalten. Die User Stories sind zu 100 Prozent umgesetzt, bevor sie es in das Sprint Review Meeting schaffen.

Nicht abgeschlossene Tasks gehen zurück ins Product Backlog und werden im nächsten Sprint beendet. Man spricht hier von einem Technical Debt. Ist der Technical Debt zu groß, wird das Projekt zunehmend komplexer und die Velocity kann sich verringern.

Das Product Increment

An jedem Sprint-Ende soll ein getestetes und nutzbares Product Increment stehen, dass der Product Owner abnehmen kann. Alle Product Increments zusammen ergeben das finale Produkt, das zum Start im Product Backlog definiert wurde.

Release Planning Product Backlog als Grundlage

Scrum Management und agiles Arbeiten steht für die ständig Anpassung von Planungen und Anforderungen. Dabei wird die Planung im Laufe des Projekts immer weiter verfeinert, weil sie anfänglich oft nur in einem ungenaueren Rahmen möglich ist.

Wie beschrieben wird das Product Backlog ständig angepasst. Bei der Velocity wird mit immer genauer werdenden Schätzungen gearbeitet, die allmählich ein konkretes Release Planning erlauben.

Besprechungen und Meetings im Scrum Projektmanagement

Jeder agile Coach und Scrum Experte wird einen Aspekt von Scrum besonders hervorheben: Besprechungen und Meetings werden im Scrum Projektmanagement sehr effizient gestaltet. Sie finden in festgesetzter Abfolge statt und werden zeitlich begrenzt. Dabei wird Wert auf Pünktlichkeit aller Beteiligten und auf die Einhaltung von Regeln gelegt. Es wird Aufmerksamkeit und Effizienz verlangt. Ergeben sich komplexere Fragen, die noch ausführlicher geklärt werden müssen, wird dazu eine neue Besprechung angesetzt. So bleibt die agile Organisation stets effektiv und präzise. Meetings ufern weder zeitlich noch thematisch aus.

No-Gos und Probleme im Scrum Projektmanagement

Das Scrum Projektmanagement folgt Regeln. Es sind nicht viele, und sie sind wenig komplex, dafür aber sehr wichtig. Ihre Einhaltung ist Grundlage des Erfolgs in jedem Scrum Projekt. Daneben muss auch das Zusammenspiel der Rollen hier besonders gut begriffen werden. Jedes Scrum Training wird etwa darauf hinweisen, dass beispielsweise eine Person nicht mehrere Rollen ausfüllen kann.

Auch sind gewisse Interessenkonflikte bei der Rollenbesetzung zu beachten. Gehört zum Beispiel der Scrum Master dem Management des Unternehmens an, kann sich das negativ auf das Scrum Projektmanagement und seinen Erfolg auswirken.

Wer meint, dass agiles Management gleichbedeutend mit einer lässigen Attitüde ist, liegt falsch. Ein Scrum Projektmanagement erfordert höchste Disziplin und Konzentration in der jeweiligen Funktion, die eingenommen wird. Der Druck ist durch die zeitliche Straffung enorm und wird dauerhaft während des Projekts aufrechterhalten. In manchen Bereichen müssen Anpassungen vorgenommen werden, da Scrum ursprünglich auf agile Produktentwicklung im Softwarebereich ausgerichtet ist.

Oft müssen Scrum Teams auch erst zusammenwachsen, was nicht immer konfliktfrei möglich ist. Die Selbstständigkeit des Teams ist hier gleichermaßen eine Stärke als auch eine potenzielle Schwäche. Agile Produktentwicklung ist anspruchsvoll und setzt auf das Engagement aller Beteiligten.

Das Scrum Projektmanagement kann eine ausführlichere Scrum Schulung oder die Begleitung durch einen erfahrene Scrum Coach voraussetzen, wenn Teams zusammenfinden, die keine Erfahrung mit Scrum haben. Hier kann ein umfassendes Kick-Off Meeting sinnvoll sein.

Kanban und seine Schwerpunkte

Kanban ist eine agile Methode zur Produktionsablaufsteuerung. Sie hat ihren Ursprung im Toyota-Produktionssystem (TPS). Kanban steht für das japanische Wort “Signalkarte” und weist auf einen wesentlichen Eckpfeiler der Methode hin. Die Kanban-Karte listet alle notwendigen Informationen. Diese sind im Kanban:

  • Kanbanart
  • Kanban-ID
  • Karten-Anzahl
  • Artikelnummer
  • Artikel-Text
  • Menge
  • Lieferant
  • Lagerort (Quelle und Ziel)
  • Empfänger
  • Barcodes
  • Produktbild

Kanban zielt auf eine Optimierung von Produktivität, Qualität und Flexibilität in der Produktion ab. Sie ist steht für eine agile Organisation, bei der Arbeit ohne Wertzuwachs und Fehler vermieden werden sollen.  Das Kanban-Prinzip wurde durch Prinzipien aus der Lean Production, dem Lean Development und der Theory of constraints für IT-Projekte nutzbar gemacht. Dabei geht es anders als im Scrum Projektmanagement weniger um iterative Prozesse, als um eine kontinuierliche Bearbeitung von Abschnitten in einer Entwicklung und deren Visualisierung. Die Stärken von Kanban liegen dabei unter anderem in der perfekten Visualisierung der Wertschöpfungskette und einer Begrenzung des Work in Progress.

Tools und Methodik im Kanban

Die Wertschöpfungskette wird auf dem Kanban-Board visualisiert. Dieses Board listet händisch oder elektronisch die einzelnen Prozessteilschritte in Spalten auf. Die einzelnen Aufgaben (Tasks) werden auf Karteikarten und/oder Post-its notiert sowie pro Zeile auf das Board geklebt, beziehungsweise mit Symbolen im elektronischen Kanban notiert. Kameras werden gern zur Kontrolle des Boards auf Veränderungen eingesetzt.

Die Aufgaben/Anforderungen können als User Story, Feature, Use Case oder in beliebiger verständlicher Form dargestellt werden. Die User Story beschreibt hier im Gegensatz zum Scrum Projektmanagement keine Anforderungen, sondern die Aktivität eines Nutzers in einem System. Dabei steht die Frage, wer was tut, um welches Ziel zu erreichen, im Vordergrund. Ein Feature beschreibt ein Leistungsmerkmal oder eine Funktion in einer Softwareapplikation.  Ein Use Case beschreibt den Anwendungsfall. Eine grafische Fassung des Anwendungsfalls mit der Unified Modeling Language kann ergänzend eingesetzt werden.

Abläufe der Bearbeitung: Nach dem Pull-Prinzip aus der Lean Production braucht der der Bearbeiter für den jeweils nachfolgenden Arbeitsschritt die abgeschlossene Aufgabe des vorhergehenden Arbeitsschritts. Hier wandern deshalb Karteikarten/Post-its auf dem Kanban- Board von links nach rechts, bis alle Tasks abgeschlossen sind. Für die Gestaltung des Kanban-Boards gibt es keine Vorschriften. Kanban bietet hier eine große Bandbreite individueller Anpassungsmöglichkeiten an ein Projekt.

Begrenzung des Work in Progress

Das Kanban-Board schafft Transparenz und ermöglicht das rasche Identifizieren von Engpässen. Engpässe behindern den gleichmäßigen Arbeitsfluss. Mit einer Limitierung von des Work in Progress wird Abhilfe geschaffen, damit der Engpass nicht noch größer und bedeutender wird. Visuell erscheint die Limitierung in einer Reduzierung der Kartenanzahl in der entsprechenden Spalte des Kanban Boards. Der Identifikation von Engpässen, die visuell sichtbar wird, ermöglicht es, in Projekten schnelle Anpassungen vorzunehmen. So werden Verzögerungen in der Projektdurchführung erkennbar und vielfach auch vermieden.

Kanban ist ein besonders nützliches Instrument, wenn die agile Organisation auf Teilprojekte angewendet werden soll, die visuell gut überschaubar sein müssen.

Anders als das Scrum Projektmanagement ist Kanban keine ganz so umfassende und große Methode, was es aber besonders flexibel einsetzbar macht.

4. Agiles Coaching und Agile Beratung

Rund um die Thematik agiles Arbeiten ist ein dynamisches Feld von Coaching und Beratungsangeboten entstanden. Ob Scrum Schulung oder Einführungen in die agile Organisation, ein großer Teil der ständigen Weiterentwicklung für agiles Management findet in diesem Bereich statt. Agile Organisation und agile Methoden sind auch heute noch für viele Unternehmen neu. In der oben zitierten Studie der GPM Deutsche Gesellschaft für Projektmanagement e.V. aus dem Jahr 2015 gaben 75 Prozent der befragten über 600 Unternehmen an, agiles Management erst seit wenigen Jahren und oft nicht in Reinform einzusetzen. Der agile Coach wird deshalb mit großer Wahrscheinlichkeit noch für einige Zeit sehr gefragt sein. Das liegt auch daran, dass mit Entwicklungen wie der Digitalisierung von Unternehmen noch mehr Flexibilität und Passgenauigkeit von Produktentwicklungen sowie in Prozessen verlangt wird.

Hier bieten agiles Arbeiten und die agile Produktentwicklung entsprechende Vorteile. Kaum ein Unternehmen wird ganz an agilem Management vorbekommen, wie die GMP Studie ebenfalls aufgezeigt hat.

Daneben entstehen außerhalb von Coaching- und Beratungsleistungen für agiles Management immer mehr Angebote für Software-Tools zur Verfügung, die Prinzipien von Scrum und Kanban einfach anwendbar machen. Hier punktet gerade Kanban mit überzeugender visueller Software und verschiedenen Werkzeugen, die jede Projektdurchführung straffen und klassische Projektplanung gut ergänzen können.

5. Ausbildung in Scrum, Kanban und für agiles Management allgemein

Zurzeit ist die Ausbildung für agiles Arbeiten und agiles Management noch nicht vereinheitlicht. Verschiedenste Anbieter sind mit eigenen Zertifizierungen und auch Ausbildungen für einzelne Rollen im Scrum Projektmanagement vertreten. Oft ist es hier der agile Coach, der auch ausbildet. Anders als Kanban setzt Scrum als Projektmanagement Wissen und Erfahrung voraus, um diese spezifische agile Organisation erfolgreich umzusetzen. Jeder Scrum Master vervollständigt seine Fähigkeiten mit jedem weiteren Projekt, das erfolgreich umgesetzt wird.

6. Agiles Management und klassische Projektentwicklung im Vergleich

Agile Organisation von Projekten und agile Produktentwicklung kann anhand verschiedener Faktoren mit klassischen Managementmethoden verglichen werden.

Agiles Management arbeitet mit einem festen Rahmen für Zeit und Aufwand, wobei der Umfang der Arbeit variabel ist. Klassisches Projektmanagement hält dagegen Zeit und Aufwand variabel und den Umfang fest.

Klassisch werden Projekte linear nach der Wasserfallmethode bearbeitet. Agiles Management setzt auf iterative Prozesse.

Klassisch steht der Prozess an sich fest, agil wird er laufend angepasst und optimiert.

Im klassischen Projektmanagement sinkt der Einfluss des Kunden/Stakeholders im Verlauf des Projektes. Die agile Organisation von Projekten billigt ihm einen konstanten Einfluss zu und richtet sich intensiv an seinen Bedürfnissen aus.

7. Bücher zum Thema agiles Arbeiten und agiles Management

The Lean Startup von Eric Ries bietet eine sehr gute Einführung in das Thema Agilität.

The Lean Product Playbook: How to innovate with Minimum viable Products von Dan Olsen lässt besonders Firmengründer und Start-Ups von den Vorzügen einer agilen Organisation lernen, bevor sie vermeidbare Fehler machen.

Theory of Constraints von Eliyahu M. Goldratt hilft schon bestehenden Unternehmen auf den agilen Weg.

Kanban and Scrum: Making the Most of Both von Henrik Kniberg und Mattias Skarin informiert umfassend zum Scrum Projektmanagement.

Agile Contracts: Creating and Managing Successful Projects with Scrum von Andreas Opelt, Boris Gloger und Wolfgang Pfarl unterstützt Unternehmen bei der Einführung von agilen Methoden.

Founders at Work: Stories of Startups’ Early Days von Jessica Livingston sollte am besten vor der Gründung eines Unternehmens gelesen werden, um gleich den agilen Einstieg zu finden.

The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail von Clayton M. Christensen überzeugt Zweifler und Kritiker von neuen Methoden sowie Technologien.

8. Die 10 besten Tools für agiles Projektmanagement

Agile Tools können die Führung eines agilen Projektes  um vieles leichter machen. Wir haben uns die 10 besten Tools im Markt angeschaut: 

  1. Clarizen macht agiles Management besonders schnell. Die Integrierten Funktionen bilden eine leistungsstarke Mischung in allen Phasen des Projekts. Dazu kommen zeitsparende Workflows zum Einsatz. Clarizen ist ein besonders überzeugendes Tool, wenn es um sich im Kern wiederholende Projekte und Prozesse in der Produktentwicklung geht. Das Produkt erleichtert insbesondere die schnelle Anpassung an sich ändernde Bedingungen und Ziele. Clarizen bietet eine Free Trail und kostet ab $60/Nutzer/Monat. 

  2. Trello erweist sich als ein einfaches und starkes Kanban Werkzeug. Als frei zu nutzendes Werkzeug bereichert es agiles Management überzeugend und intuitiv erfassbar. Es gibt zusätzlich eine Bezahlversion mit noch größerer Funktionalität. Die Business Version punktet hier mit Funktionen wie Github integration, SalesForce, Slack, Gantt Charts, Timesheets sowie Berichts- und Analysefunktionen. Trello ist frei verfügbar. Die Bezahlversion startet ab $9.99 pro Nutzer pro Monat.

  3. GitScrum ist ein relatives neues Tool für agiles Arbeiten. Es hat einige Funktionen und Eigenschaften zu bieten, die anderen Tools fehlen. Hier sind beispielweise eine Zeiterfassungsfunktion oder eine Suchfunktion für Fehler im Prozess zu nennen. Agile Organisation und Scrum Projektmanagement werden mit GitScrum besonders effektiv. Agile Produktentwicklung wird sehr gut nachvollziehbar. GitScrum ist besonders gut für die Arbeit von Teams geeignet, weil es das Teilen und Hochladen von Dateien sowie Infos erleichtert. GitScrum kostet ab $12 pro Monat pro 10 Nutzer. Bis zu 3 Nutzern ist es frei verfügbar.

  4. Jira ist ohne Zweifel eine der großen Hausnummern, wenn es um agiles Arbeiten, agiles Management und agile Produktentwicklung geht. Das Tool bietet in umfassender Form alles, was nötig und wünschenswert ist, um agile Organisationsowie Scrum Projektmanagement zu einem Erfolg zu machen. Es zählt zu den besten Tools. Dabei ist Jira nicht für agiles Management geeignet, sondern auch für klassisches Projektmanagement und Nichtentwicklungsprojekte eine perfekte Wahl. Jira kann individuell konfiguriert und damit in seine Funktionen auf verschiedene Bedürfnisse angepasst werden. Das Tool ist einer der Favoriten für agiles Arbeiten, Scrum Projektmanagement und Projektmanagement an sich. Jira bietet einen 7 Tage Trail und kostet $7 pro Nutzer pro Monat (Cloud Version).

  5. Taiga ist ein feines Open Source Tool. Agiles Management und Scrum Projektmanagement werden damit besonders einfach und komfortabel. Das Tool ist stark auf die agile Organisation ausgerichtet, fällt aber im Vergleich mit Schwächen im Berichtswesen auf. Auch seine Integration überzeugt noch nicht vollständig. Hier ist noch Entwicklungspotenzial

    Taiga startet ab $5 pro Monat pro Nutzer.

  6. Pivotal Tracker ist ein besonders einfach zu nutzendes Kanban Tool. Im Fokus stehen das Task Management und die Geschwindigkeit. Das Tool eignet sich besonders für agile Produktentwicklung und das Management verschiedener Projekte zu gleichen Zeit. Es besticht mit sehr guten Analyse- und Berichtsfunktionen, die jederzeit den Überblick über den Projektstand und das Team ermöglichen.

    Pivotal Tracker ist umsonst aber kostet in der Bezahlversion (Mit Teams von bis zu 3 Mitgliedern) $12.50 pro 5 Nutzer pro Monat. 

  7. Nostromo ist ein neues Tool, das auf Kanban Projekte zugeschnitten ist. Mit seinen einfachen und schnell zu erfassenden Funktionen wirkt es wie eine gedopte Version von Trello – agiles Arbeiten und agiles Management machen damit richtig Spaß. Dafür sorgt vor allem die im Vergleich mit Trello noch ausgefeiltere Time Tracking Funktion. Nostromo kostet $10 pro 2 Nutzer pro Monat.

  8. Hansoft lässt sich für agile Produktentwicklung und agile Organisation besonders gut an individuelle Vorstellungen sowie Bedürfnisse anpassen. Sein Backlog Management ist exzellent. Die Zusammenarbeit im Team ist mit Hansoft sehr gut zu managen. Dafür sorgen unter anderem auch die intuitiven Dashboards. Hier sind die Informationen dann greifbar, wenn sie gebraucht werden. So soll agile Organisation sein. Hansoft ist kostenlos für bis zu 5 Nutzer.

  9. Auch Blossom ermöglicht in einer Kanban Umgebung und bei einem örtlich verteilten Team gute Anpassungen an individuelle Vorgaben. Agile Produktenwicklung wird damit einfach sowie effizient bewältigt. Das Programm arbeitet sehr gut mit GitHub, HipChat, Flowdock und zusammen. Über ein API integriert es sich einfach mit anderen Programmen für agiles Arbeiten. Blossom bietet einen 14-tägige Testphase und kostet anschließend $19 pro 5 Nutzer pro Monat.

     

  10. Ravetree ist ein sehr umfassendes Programm, das viele starke Funktionen für agiles Arbeiten, Scrum Projektmanagementund agile Produktentwicklung mitbringt. Es lässt beispielweise mit integriertem CRM keine Wünsche im Scrum Projektmanagement und für agile Produktentwicklung offen. Mit Ravetree lässt sich Scrum Projektmanagement ebenso wie ein Kanban Projekt hervorragend umsetzen, weil das Produkt alle relevanten Funktionen für agiles Management selbst integriert hat. Es ist kein Zugriff auf andere Tools nötig, und es sind keine weiteren Add-Ons notwendig, um eine exzellente Funktionalität zu erreichen. Ravetree startet bei $29 pro Nutzer pro Monat (bei jährlicher Zahlung).

Unter dem Strich machen alle vorgestellten Tools agile Organisation und agiles Management einfacher sowie effektiver. Je nachdem, ob der Schwerpunkt für agile Produktentwicklung auf Scrum Projektmanagement, Kanban oder Hybridformen liegt, findet man ein passendes Programm für die eigenen Bedürfnisse. Diese Vielfalt ermöglicht nicht nur Scrum Projektmanagement auf höchstem Niveau. Die kleineren Programme für agiles Arbeiten sind oft intuitiver zu bedienen, bringen aber nicht alle Funktionen selbst mit.

Senden Sie mir: "Mit
5 Schritten in 5 Tagen
Agile Methoden inte-
grieren"

Melden Sie Sich für unseren Newsletter an

Melden Sie sich für unseren Newsletter an und werden benachrichtigt, sobald wir neue Inhalte für Sie haben