Agiles Projektmanagement und Scrum

Immer öfter hört man von agilem Projektmanagement, Scrum und ähnlichen Buzzwords, doch was steckt eigentlich hinter diesem Ausdruck? Was ist Agiles Projektmanagement und was gehört alles dazu?  

Agiles Produktmanagement ist der Oberbegriff für verschiedene agile Projektmanagement-Methoden, die ursprünglich in der Softwareentwicklung entstanden sind. In diesen Softwareentwicklungs-Prozessen haben Flexibilität, Vielseitigkeit sowie Klarheit und Transparenz oberste Priorität. Durch einen schnelleren Einsatz der konzipierten Systeme und Methoden sollen Risiken im Entwicklungsprozess minimiert werden. Dafür werden auch selbstorganisierte Teams eingesetzt und iterative (wiederholende) und inkrementelle (schrittweise) Methoden und Konzepte verwendet.

Das agile Projektmanagement möchte möglichst wenig Regeln aufstellen und wenig bürokratischen Aufwand betreiben, um effektiv arbeiten zu können. Dadurch sollen auch Modifikationen und Veränderungen ohne Risikoerhöhung möglich sein.

 

Was ist das Ziel von agilem Projektmanagement

Bei vielen herkömmlichen Methoden und Arbeitsprozessen (wie beispielsweise Rational Unitified Process und V-Modell) ist oft ein anstrengender Weg, bei dem sich an dem sich übergenau an die Einhaltung von Vorschriften geklammert wird, notwendig, bis es schließlich zum gewünschten Erfolg kommt.

Doch das Ziel einer agilen Softwareentwicklung ist es die Fortentwicklung und den Ablauf beweglicher, geschickter, betriebsamer und somit auch unkomplizierter zu gestalten.

 

Enstehung der agilen Projektmanagement-Methode

Anfang der 1990er Jahre gab es die ersten Ansätze zu agiler Softwareentwicklung, da es nun Zeit für neue Vorgehensweisen wurde. Mit schwergewichtigen und traditionellen Methoden wie beispielsweise dem starren Wasserfall-Prozess war man in der Softwareentwicklung nicht mehr zufrieden. Nach der Wasserfall-Methode wurden bereits am Projektanfang alle Voraussetzungen, Erfordernisse und Ansprüche genau festgelegt. Anschließend wurden Konzepte, Einteilungen und Pläne entwickelt und dann das Produkt hergestellt und eingeführt.

In unserer immer schneller werdenden und auch kurzlebigeren Zeit muss jedoch flink und flexibel auf Veränderungen und Anforderungen reagiert werden können.

Aus diesem Grund kam es vor über 25 Jahren zu revolutionären Änderungen und Verbesserungen in der Software-Branche. 1999 veröffentlichte Ken Beck das erste Buch zu Extreme Programming (XP). Dadurch war der Grundstein für andere flexiblere Konzepte und agile Softwareentwicklungen gelegt. Im Februar 2001 bei einem Meeting im US-Bundesstaat Utah wurde die Bezeichnung „agil“ erstmals auf diese Methode der Softwareentwicklung bewusst angewandt. Es trafen sich 17 Vertreter von unterschiedlichen

Das agile Manifest

Softwareentwicklungsmethoden, die das sogenannte „Agile Manifest“ niederschrieben. Die Autoren und Erstverfasser sind: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ronm Jeffries, Join Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland und Dave Thomas. Inzwischen umfasst die Liste der Unterzeichner des agilen Manifests über 1000 Menschen. Da sich das agile Projektmanagement nicht nur für die Planung, das Erschaffen und die Fortentwicklung von Software-Projekten eignet, setzen nach einer Umfrage aus dem Jahr 2016 von VersionOne 95 Prozent aller Unternehmen agile Methoden und Prozesse in anderen Projektarten ein.

 

Klassisches, hybrides und agiles Projektmanagement

Die Begriffe werden oft durcheinander gebracht oder falsch interpretiert. Die Buzzwords im Zusammenhang mit Agilität und Projektmanagement haben ihre eigenen Kreise gezogen. Hier eine kurze Definition.

 

Klassisches Projektmanagement

Als klassisches Projektmanagement versteht man Systeme, die sehr standardisiert, konform (übereinstimmend) und normiert sind. Sie sind als Referenz anerkannt. Zu klassischen Projektmanagement-Methoden gehören der Wasserfall-Prozess, standardisierte Projektmanagement-Systeme beziehungsweise allumfassend vorgezeichnete Konzepte mit festen hierarchischen Organisationen. Etablierte, dokumentierte Vorgehensweisen und Methoden, die allgemein anerkannt, gehören zum klassischen Projektmanagement.

 

Hybrides Projektmanagement

Als hybrides Projektmanagement bezeichnet man die Kombination von zwei oder mehreren Systemen, die für die Organisation, Vorgehensweise, Prozedur und Durchführung eines Projekts angewandt wird. In einem Projekt werden klassische (herkömmliche) und agile (flexible) Methoden miteinander vereint. Außerdem werden beim hybriden Projektmanagement Vorgehensweisen wie Critical Chain (erweitert das klassische Projektmanagement um zwei Elemente: Vermeidung von schädlichem Multitasking und korrekter Umgang mit Schätzungen, deren Streuungen und damit verbundenen Puffern) oder Theory of Constraints (auch Engpasstheorie oder Durchsatz-Management genannt: die Gesamtheit der Denkprozesse und Methoden zur Verbesserung der Leistungsfähigkeit von Systemen), Wasserfall-Methode, Lean Development (Strukturen, Prozesse und Werkzeuge werden auf Verschwendung, hin untersucht und Schwachpunkte und deren Auslöser werden durch Gegenmaßnahmen eingedämmt)  beziehungsweise Scrum zusammengefügt.

 

Agiles Projektmanagement

Beim agilen Projektmanagement werden Systeme eingesetzt, die Projekte und Prozesse leichtgewichtiger, flexibler (beweglicher) und variabler (veränderbar) machen. Dafür wurde das agile Manifest und deren zwölf Prinzipien entwickelt. Zu agilen Projektmanagement-Methoden gehören unter anderem Kanban und Scrum, die wirkungsvoll und effektive Prozesse und Ausführungen, engagierte und motivierte Mitarbeiter und zufriedene Kunden garantieren. Agiles Projektmanagement lebt von einer kontinuierlichen Veränderung und stetigen Entwicklung, bei das ganze Mitarbeiter-Team integriert ist.

 

 

Was ist das agile Manifest?

Dem agilen Projektmanagement liegt das agile Manifest zugrunde. Priorität (Vorrang) wird auf die Einbeziehung der Stakeholder (Interessengruppe) gelegt. Während des gesamten Projekts findet eine Kommunikation mit den Stakeholdern statt, um ihn zu informieren sowie regelmäßig Zwischenstände und  Ergebnisse mitzuteilen. Wer Projekte zukünftig agil organisieren und durchführen möchte, sollte den Überzeugungen und Werten des agilen Manifests folgen.

 

„Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit  haben wir diese Werte zu schätzen gelernt:

 

– Individuen und Interaktionen mehr als Prozesse und Werkzeuge

Alle die im Projekt involviert (beteiligt) sind, stehen im Vordergrund. Stakeholder sollen nicht durch engstirnige und stark eingegrenzte Methoden und Prozesse in seinem Freiraum eingeschränkt werden. Dies ist bei klassischen Projektmanagement-Methoden meistens der Fall. Nach einem agilen System sind am Prozess mitarbeitende Personen und Teams in permanentem Kontakt und tauschen sich fortwährend aus, sodass das Projekt vorankommt.

 

– Funktionierende Software mehr als umfassende Dokumentationen

Agiles Produktmanagement bevorzugt, dass immer funktionsfähige Resultate herstellt. Ausführliche Berichte, Analysen und Auswertungen werden hier vermieden, damit die Softwareentwicklung intakt (funktionsfähig) und zügig durchgesetzt werden kann. Ein förderliches und nützliches Projektergebnis hat eine größere Bedeutung als eine detailgenaue Berichterstattung und Dokumentation. Stakeholder profitieren mehr von einem Erzeugnis, das sie in den Händen halten können, als von ausführlichen Erfassungen und Aufzeichnungen des Produkts.

 

– Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung

Auch hier soll der Stakeholder von größerer Bedeutung sein als zeitraubende und kostspielige Vertragsverhandlungen. Durch die Kommunikation und Verbindung zwischen Team und Stakeholder kann direkt und frühzeitig mit dem Arbeitsprozess angefangen. Stakeholder können Wünsche und Änderungen in das agile Projektmanagement fortlaufend einbringen. Diese können dann im flexiblen System eingearbeitet werden, ohne den Projektverlauf durch zusätzliche Vertragsverhandlungen zeitweilig oder ganz zu intermittieren (auszusetzen).

 

– Reagieren auf Veränderung mehr als das Befolgen eines Plans

Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.“

Wenn alles von Anfang bis ins Detail geplant wird und das Klammern an eine Vorgehensweise und an ein Konzept im Vordergrund steht, steigt das Risiko, dass auf Modifikationen (Änderungen) und Abwandlungen der Stakeholder nicht richtig eingegangen werden kann. Um Stakeholdern aber wirklich zufriedenstellende Resultate abzuliefern, ist es wichtig auf dessen Anforderungen, die im Laufe eines Prozesses ändern können, flexibel und schnell zu reagieren. Das anfängliche Ausmaß und der gesamte Bereich des Projekts kann sich durch andere oder neue Erwartungen und Wünsche der Stakeholder auch verändern. Alle Werte des agilen Manifests sind erheblich. Auch wenn der vordere Teil der Leitsätze Priorität hat, so darf der hintere Teil nicht unberücksichtigt bleiben. Die ständige Wechselbeziehung und Kommunikation zwischen Stakeholder und Team ist wichtiger als Prozesse, Werkzeuge (Tools) und Vertragsverhandlungen. Trotzdem sollte zwischen dem vorderen und hinteren Teil der Leitsätze eine Balance hergestellt werden. Nur so kann ein Unternehmer mit seinem Team erfolgreich ein agiles Projektmanagement durchführen.

 

Die Gruppe von IT-Spezialisten, die das agile Manifest verfasst haben, betonen, dass der hintere Teil nicht vernachlässigt wird, sondern der vordere Teil des Leitsatzes Priorität (Vorrang) hat. Dies wird durch die Verbindung der Leitsätze mit „mehr als“ deutlich. Beide Inhalte sind jedoch von Bedeutung, jedoch hat der erste Teil im Zweifelsfall Vorrang und ist von größerer Dringlichkeit.

 

 

Was sind die 12 Prinzipien zum agilen Manifest?

1. Die Zufriedenstellung der Auftraggeber hat oberste Priorität. Diese wird durch frühe und kontinuierliche Auslieferung und Sendung von wertvoller, förderlicher Software erreicht.

2. Veränderungen werden auch zu einem späteren Zeitpunkt in den Entwicklungsprozess eingebunden. Dies stellt letztendlich einen Wettbewerbsvorteil des Kunden dar.

3. Die Lieferung von funktionierender Software sollte in regelmäßigen und kurzen zeitlichen Intervallen (einige Wochen oder Monate) erfolgen.

4. Während des Projekts findet eine fast tägliche Zusammenarbeit und Kommunikation zwischen Entwicklern und Fachexperten statt. Hilfreich dabei ist ein gemeinsamer Besitz-Code, sogenannte Collective Code Ownership. Bei diesem trägt das Entwicklungsteam gemeinsam die Verantwortung für den Code. Jedes Team-Mitglied kann an jeder Stelle Modifikationen ausführen.

5. Das Mitarbeiter-Team und Beteiligte am Projekt bekommen ein adäquates (angemessenes) Arbeitsumfeld und ausreichend Unterstützung, um motiviert und engagiert ihre Aufgaben zu erfüllen.

6. Die Funktionsfähigkeit der Software ist das bedeutendste Fortschrittsmaß.

7. Das Einhalten eines gleichmäßigen Arbeitstempos von Entwicklern, Benutzern und Auftraggebern ist für eine nachhaltige Entwicklung notwendig.

8. Die Agilität (Wendigkeit) und Beweglichkeit wird durch ein permanentes Augenmerk auf eine exzellente (hervorragende) Technik und gutes Design erhöht.

9. Einfachheit und Funktionalität sind essentiell (grundlegend) und maßgebend.

10. Teams organisieren sich selbst bei der Planung und Umsetzung des Projekts. Sie bringen Prozesse selbstständig auf den Weg. Dadurch entstehen die besten System-Strukturen, Anforderungen und Designs.

11. Am Projekt beteiligte Mitarbeiter und Teams denken in regelmäßigen Abständen über das eigene Verhalten nach. Durch diese Selbstreflektion ist eine Effizienzsteigerung (Erhöhung des Wirkungsgrades) möglich.

12. Informationen und Details sowie Änderungen der Projekts werden am besten in persönlichen Gesprächen und Meetings besprochen. Face-to-Face ist jeder Technik und digitalen Kommunikation nach Möglichkeit vorzuziehen.

 

Wer sind die Repräsentanten agiler Prozesse?

Softwareentwicklungsprozesse sollen durch die Verringerung von Bürokratie und erhöhte  Aufmerksamkeit von menschlichen Kriterien und Standpunkten effektiver gestaltet werden. Befürworter des agilen Projektmanagements sind sich sicher, dass nur noch flexibel auf Änderungen der Stakeholder eingegangen werden kann. Schließlich liegt die Betonung bei dieser Methode auf „agil“.

Bei den meisten agilen Prozessen wird versucht die reine Entwurfsphase auf ein Mindestmaß zu vermindern und im Entwicklungsprozess so früh wie möglich zu durchführbarer und leistungsfähiger Software zu gelangen. Diese wird dann mit dem Team in regelmäßigen, kurzen Abständen dem Kunden zur gemeinsamen Koordination (Abstimmung) unterbreitet. Somit kann schnell und agil auf Wünsche und geänderte Anforderungen des Kunden reagiert werden. Alle agilen Prozesse haben gemeinsam, dass sie Verfahrensweisen und Prozeduren verwenden die den bürokratischen und zeitlichen Aufwand sehr gering halten.

Zu den namhaften Repräsentanten agiler Prozesse gehören:

– Extreme Programmierung (XP) Extreme Programming ist eine Verfahrensweise, bei der das Lösen einer Programmieraufgabe vorrangig ist. Ein formalisierter Ablauf wir bei XP in den Hintergrund gestellt.

– Feature Driven Development (FDD) Feature Driven Development wurde als eine schlanke Methode eingeführt, um große zeitkritische Projekt durchzuführen. Seitdem wurde FDD stets weiterentwickelt.

– Adaptive Software Development (ASD) Adaptive Software Development ist eine Realisierung des Grundsatzes der kontinuierlichen Anpassung an fortwährende Erwartungen und Ziele. Neu entwickelte Programmversionen werden nach vier Wochen getestet, ob sie eine Fortentwicklung darstellen.

– Crystal Crystal ist keine einzelne Methode, sondern eine Gruppierung von Methoden, mit Ausführungen und in verschiedenen Farben. Durch die Unterteilung wird zu den Projektumständen ein entsprechender Regelsatz ausgewählt.

– Agiles Testen Agiles Testen von Software wird während der Entwicklungsphase eines Projekts durchgeführt. Das Hauptaugenmerk liegt auf der Unterstützung des Entwicklungsteams und werden die Prinzipien des agilen Manifests angewandt.

– Behavior Driven Developemt (BDD) Behavior Driven Development bedeutet verhaltens- oder anforderungsgerechte Softwareentwicklung. Dabei soll die Kooperation zwischen Business-Analyse und Qualitätsmanagement in Softwareentwicklungsprojekten vertiefen.

– Kanban &  Scrum Unter diesen agilen Prozessen müssen Kanban und Scrum besonders hervorgehoben werden, denn sie haben in Unternehmen die größte Verbreitung gefunden.

 

Was ist Kanban im Detail?

Auf einem sogenannten Kanban Board werden Erwartungen und Ziele der Stakeholder nach ihren Status (Zustand) erfassen. Es stellt den aktuellen Stand der Dinge dar.

Dadurch wird der Arbeitsfluss nach der Kanban Methode für alle am Prozess beteiligten Personen veranschaulicht. Eine Anforderung wird auf einer Haftnotiz niedergeschrieben und wird dann von Zustand zu Zustand auf dem Kanban Board befördert. Hierbei spielen die Obergrenzen der Erwartungen und Ziele in den jeweiligen Zuständen eine wichtige Rolle. Es wird beispielsweise determiniert, dass maximal drei Anforderungen bearbeitet und modifiziert werden können.

Quelle: https://leankit.com/

 

Es gibt aber keine fixe Anzahl an Erwartungen, die innerhalb eines Zeitabschnitts, erfüllt werden müssen. Dies ist anders beispielsweise beim Scrum-Projekt und Sprint Backlog. Dafür können sich die Mitarbeiter des Teams selbstständig und in Eigenregie neue Anforderungen aus dem Kanban Board besorgen, wenn sie wieder ausreichend freie Systemressourcen und Betriebsmittel haben.

Scrum hat sich im Laufe der Jahre zu einen der bekanntesten Methoden für agiles Projektmanagement entwickelt, da sich auch für Projekte außerhalb der Softwareentwicklung eignet. Aus diesem Grund benutzen und arbeiten sehr viele unternehmen mit Scrum Prozessen.

 

 

Was ist Scrum im Detail?

Der Begriff „Scrum“ kommt eigentlich aus der Sportart Rugby. „Scrum“ bedeutet angeordnetes Gedränge und ist in verschiedenen Varianten des Rugby-Sports die Standardsituation, um das Spiel nach kleineren Regelverstößen, einem unerlaubten Vorwärtsspielen des Balles oder nach einem Aus neu zu beginnen.

Scrum im agilen Projektmanagement ist ein Vorgehensmodell, das mit wenig Regeln klar kommt und auf Veränderungen schnell reagieren kann. Dieses kleine Regelwerk beschreibt fünf Aktivitäten, drei Artefakte und drei Rollen, welche den Kern („core“) umfassen. Dies alles ist im Agile Atlas, welcher die Grundlagen beschreibt, und im detaillierteren Leitfaden Scrum Guide erklärt. Jeff Sutherland und Ken Schwaber erschufen und realisierten Scrum bereits in den 1990er Jahren. Im Jahre 1995 veröffentlichten sie den ausführlichen Scrum Guide. „The Definitive Scrum Guide to Scrum: The Rules of the Game“ beinhaltet auch die Definition von Scrum:

„Ein Rahmenwerk, mit dessen Hilfe Menschen komplexe adaptive Aufgabenstellungen angehen können, und durch das sie in die Lage versetzt werden, produktiv und kreativ Produkte mit dem höchstmöglichen Wert auszuliefern.“

Quelle: http://scrum.org

Im Fokus von Scrum steht, dass ein Projekt nicht von Anfang an bis Ende spezifisch und akkurat (mit äußerster Sorgfalt) durchdacht und organisiert wird. Produktentwicklung erfolgt iterativ, also in wiederkehrenden Schritten. Diese kurzen Feedback-Schleifen werden als Sprints bezeichnet. Dadurch kann der gegenwärtige Status und Zustand des Prozesses kontrolliert und schnell reagiert werden. Bei Veränderungen und Erneuerungen ist das Team in der Lage auf die Anforderungen der Stakeholder einzugreifen. Um umfangreiche Softwareentwicklungsprojekte zu organisieren und handzuhaben, müssen die einzelnen im Scrum definierten Rollen kooperieren und kommunizieren.

 

Welche Rollen gibt es Scrum-Prozess?

Das Leitwerk (Guide) des Scrum nennt drei zentrale Rollen: Scrum Master, Product  Owner und Scrum Team (Entwicklungsteam).  In weiteren, nachfolgenden Publikationen werden aber auch Kunde, Anwender und Management als Scrum-Rollen genannt.

 

Der Scrum Master

Der Scrum Master ist für die Durchführung und Verwirklichung des Projekts zuständig. Das heißt, dass er letztendlich für den Erfolg des Scrums verantwortlich. Er kooperiert mit dem Scrum-Team, aber er gehört meist nicht dem Entwicklungsteam direkt an. Scrum-Regeln werden vom Scrum Master eingeführt und auch deren Befolgung von ihm kontrolliert. Außerdem hilft er Lösungen von Störungen und Hemmnissen zu finden. Der Scrum Master schafft gute Arbeitskonditionen für das Scrum-Team und setzt sich für dessen Selbstorganisation ein.  Er soll ein förderliche Führungskraft gegenüber der Gruppe darstellen und unterstützt die Zusammenarbeit zwischen Scrum Team und Product Owner. Jedoch gibt der Scrum Master dem Team keine Arbeitsanweisungen, Beurteilungen oder spezifische Kritiken. Er ist eher als Coach für den agilen Entwicklungsprozess anzusehen und das führt aufgrund verschiedener Teams und Konstellationen situativ (situationsbedingt). Nach dem Umstellen der Abläufe, dem Zusammenwachsen des Scrum Teams und dem Einlernen der Rollen übernimmt der Scrum Master seine Rolle als Change Manager.

 

Der Product Owner

Der Product Owner ist zuständig für den wirtschaftlichen Erfolg und dem Gelingen des Projekts. Er verantwortet die sogenannte Produktvision, die Erwartungen und Ziele sowie das Product Backlog. Der Product Owner strukturiert und realisiert das Produkt mit dem Zweck, den maximalen Nutzen und Profit daraus zu ziehen. Die zu entwickelnden Produkteigenschaften werden vom Product Owner erarbeitet und konkretisiert. Er legt fest, welche Merkmale am Ende eines Sprints zu einem Resultat kommen müssen. Der Product Owner entscheidet allein über das Produkt, seine Merkmale und Eigenschaften sowie die Sequenz der Implementierung und Entwicklung. Auf diesem Weg koordiniert er Eigenschaften, Deadlines der Auslieferung und Kosten und bringt diese Faktoren möglichst ins Gleichgewicht. Der Product Owner benutzt das Product Backlog, um die Produkteigenschaften festzulegen. In dem Product Backlog trägt er die Erwartungen und Ziele an das Produkt ein. Dies erfolgt in Kooperation mit dem Scrum Team und den Stakeholdern. Das Product Backlog wird von dem Product Owner im Product Backlog Refinement in regelmäßigen Abständen geordnet aktualisiert. Der Product Owner ist die verantwortliche Person für das Produkt. Aus diesem Grund muss er immer wieder mit den Stakeholdern kommunizieren, um deren Anforderungen, Änderungen und Wünschen nachzukommen.

 

Das Scrum Team

Das Entwicklungsteam liefert die Systemfunktionalität des Produkts ab und zwar in der geforderten Reihenfolge und nach dem gewünschten Ablauf des Product Owner. Außerdem ist das Scrum Team für die Einhaltung des festlegten Qualitätsstandards, wobei es sich aber selbstorganisiert.

Die Backlog Einträge führt das Scrum Team selbstständig durch. Der Scrum Master schreibt dem Team nicht vor, wie die Backlog Einträge erledigt und eingereicht werden. Das Scrum Team sollte interdisziplinär besetzt sein und dadurch fachübergreifend tätig sein zu können.

Ein erfolgreiches Entwicklungsteam besteht unter anderem aus Developer, Konstrukteuren, Testern, Architekten, Datenbankexperten, Dokumentationsspezialisten.

Dadurch sind Scrum Teams fähig, das Ziel und Ergebnis eines Sprints selbstständig zu erreichen. Sie sind nicht auf andere Personen und deren Vorgehensweisen angewiesen und können somit unabhängig arbeiten.

Damit ein Scrum Team auf positive Resultate blicken kann, ist es erforderlich, dass aus fähigen Team-Mitgliedern besteht, die sich nicht nur als Experten auf ihren Fachgebieten sehen, sondern auch als Allrounder.

Ein gutes Scrum Team besteht aus drei bis neun Mitgliedern und bildet eine Einheit und Geschlossenheit, so dass auch negative Entwicklungsprozesse oder Ergebnisse nicht auf einzelne Personen zurückgeführt werden. Damit alle erforderlichen Fähigkeiten, Potenziale und Verantwortungsbereiche vom Entwicklungsteam gestemmt werden kann, muss es eine gewisse Größe haben. Jedoch darf es auch nicht zu groß sein, damit es nicht zu Koordinationsproblemen und Schwierigkeiten mit der Abstimmung kommt. Außerdem berechnet das Scrum Team den Umfang der Eintragungen und Inputs im Product Backlog beziehungsweise im Product Backlog Refinement. In modernen Unternehmen werden immer mehr Mitarbeiter in Gruppen für agile Projektmanagement-Entwicklungen eingesetzt.

Manche Team-Mitglieder haben von Zeit zu Zeit Probleme mit der Annahme und Bejahung von interdisziplinären Anforderungen. Viele Personen möchten mit ihren Expertenwissen nicht in andere Themenbereiche eingeteilt werden. Sie sehen es nicht als eine Bereicherung an, über den Tellerrand zu blicken und Arbeiten von anderen Spezialisten zu übernehmen. Doch der Grundgedanke und die Idee von agilem Projektmanagement mit Scrum System liegt darin, dass nicht individuelle Experten den Prozess vorantreiben, sondern ein geschlossenes Team, das fachübergreifend zusammenarbeitet. Unvorhersehbare Einflüsse können von einem interdisziplinären Scrum Team besser und schneller eingeschätzt werden. Das Team reagiert auf Veränderungen flexibler und kompetenter.

Wenn ein Team-Mitglied einen Sachverhalt, eine Herausforderung oder eine Problematik nicht für sich bewerkstelligen kann, dann kann ein anderes Team-Mitglied Hilfe leisten und unterstützend einwirken, damit das Sprint-Ziel erreicht wird.

Ist ein Team-Mitglied für einen längeren Zeitraum verhindert, so ist eine fachübergreifende Gruppe besser in der Lage, das mangelnde Know-how und die fehlende Expertise auszugleichen. Stakeholder sind Rollen außerhalb vom Scrum System. Zu den Stakeholdern gehören Kunden, Anwender (User) und Management. Aufgrund der Unterteilung in verschiedene Rollen können die Stakeholder und deren Aufgabengebiete besser differenziert werden.

 

Das Management

Das Management sorgt für die richtigen Rahmenbedingungen und das passende Arbeitsumfeld. Es stellt Räume, Bürozimmer und entsprechende Arbeitsmittel und Ressourcen zur Verfügung. Doch das Management sollte sich nicht nur um materielle Utensilien kümmern, sondern generell eine unterstützende Funktion darstellen.

Das Scrum Team soll durch das Management vor äußeren Arbeitsanforderungen geschützt werden. Das Management ist für eine angemessene Besetzung des Scrum Teams mit Spezialisten verantwortlich und unterstützt den Scrum Master, um Probleme zu lösen und Schwierigkeiten zu beseitigen.

 

Die Kunden

Kunden können externe Individuen oder Gruppen sein, aber auch interne Fachabteilungen. Ihnen wird das fertige Produkt am Ende eines Entwicklungsprozesses zur Verfügung gestellt. Kunden und Product Owner sollten während des gesamten Projekts in engem Kontakt und in ständiger Kommunikation miteinander stehen. In der Anfangsphase eines Entwicklungsprozess muss der Product Owner sich ein möglichst genaues Bild von den Erwartungen und Zielen des Kunden haben. Bereits nach den ersten Sprints kann sich der Kunde die neuen Funktionalitäten und aktuellen Fortschritte an seinem Produkt anschauen und hierzu auch seine Meinung, sein Feedback und gegebenenfalls Änderungswünsche mitteilen. Der Product Owner ist dafür zuständig, dass die Kunden durch die Lieferung und Überbringung des gewünschten Produkts zufrieden gestellt werden.

 

Die Anwender

Anwender werden auch User genannt und sind die Benutzer des Produkts. Ein User ist nicht automatisch ein Kunde. Ein Anwender beurteilt das Produkt aus der Sicht des Nutzers. Aus diesem Grund ist der Anwender sehr wichtig für das Scrum Team. Beim Sprint Review und Product Backlog Refinement sollen Kunde und Anwender beteiligt werden. Denn dadurch kann das Produkt getestet werden und entsprechende Rückmeldungen und Stellungnahmen dazu abgegeben werden.

 

Was sind Scrum-Artefakte?

Sogenannte Artefakte stehen im Scrum breit, um ein Scrum-Projekt zu steuern. Eine Definition findet man im Scrum Guide: „Die Artefakte von Scrum repräsentieren Arbeit oder Wert auf verschiedene nützliche Weisen, die Transparenz und Gelegenheit zur Überprüfung und Anpassung schaffen.

Die in Scrum definierten Artefakte sind spezifisch dafür entwickelt worden, die Transparenz über Schlüsselinformationen zu maximieren, die sicherstellen, dass Scrum Teams erfolgreich ein `done` (fertiges) Inkrement liefern können.“ Nach dem Scrum Guide zählen als Artefakte das Product Backlog, das Sprint Backlog und das Produktinkrement. In weiterführender Literatur findet man weitere Artefakte wie das Burndown-Chart, das Impediment Backlog und „Done“. Letzteres wird im Scrum Guide nicht als Artefakte definiert, sondern als selbstständiges Hilfsmittel und Instrument. Beim „Done“ werden Inputs im Product Backlog und die Inkremente als „erledigt“ angegeben.

Das Impediment Backlog ist eine Verfahrensweise und Methode, mit der der Scrum Master öffentlich alle Störungen und Behinderungen in den Arbeitsprozessen sammelt. Das Impediment Backlog stellt eine Liste von Hemmnissen und Blockaden dar sowie Aufgaben zu deren Lösung und dem aktuellen Zustand.

Die Hauptaufgabe des Scrum Masters ist die Erledigung und Entfernung von Impediments. Ein Hilfsmittel zur Fortschrittsmessung stellt das Burndown-Chart dar und wird auch vereinzelt als Artefakt angesehen.

 

Das Product Backlog

Das Product Backlog ist eine strukturierte und systematische Aufstellung und Gliederung der Erwartungen und Ziele an das Produkt. Das Product Backlog ist energiegeladen und wird permanent weiter entwickelt. Im Product Backlog haben alle Arbeiten und Entwicklungsprozesse, die das Scrum Team zu erledigen hat, ihre Wurzeln. Für die Instandhaltung und Wartung des Product Backlogs ist der Product Owner zuständig. Ebenso legt er die Sequenzen und die Ordnung der Einträge fest. Die Erwartungen im Product Backlog sollen fachlich und anwenderorientiert sein. Außerdem erhebt das Product Backlog nicht den Anspruch der Vollständigkeit. Am Anfang eines Projektes und dessen Entwicklungsprozesses beinhaltet das Product Backlog die bekannten und wichtigsten Anforderungen. Die Bewertung und Ordnung der Inputs geschieht durch Kriterien wie Grundvoraussetzung, Notwendigkeit, Misserfolgswahrscheinlickeit und ökonomischer Nutzen. Im Sprint werden dann vorrangige Eintragungen bearbeitet.

 

Das Sprint Backlog

Das Sprint Backlog stellt den gegenwärtigen Plan und die Strategie dar. Dieser ist umfasst die zu erledigenden Aufgaben im Sprint. Der Sprint Backlog beinhaltet die Inputs (Einträge) des Product Backlogs, die für den Sprint ausgesucht wurden. Außerdem umfasst er die dafür notwendigen Aufgaben wie beispielsweise Entwicklungsprozess, Test, Kontrolle, Dokumentation. Mitglieder des Scrum Teams  aktualisieren in regelmäßigen Abständen nach Durchführung und Abwicklung einer Teilaufgabe oder Aufgabe den Sprint Backlog. Dadurch wird der aktuelle Status der Bearbeitung und Erledigung übersichtlich für alle Beteiligten, oftmals in einem Taskboard, dargestellt.

 

Das Product Inkrement

Die Summe aller Product Backlog Einträge wird als Inkrement bezeichnet. Diese Inputs wurden in aktuellen und vorherigen Sprints bearbeitet. Am Ende eines Sprints muss das neue Inkrement in einem verwendbaren Status sein. Es muss ebenso der Bedeutung von „Done“ erfüllen.

 

Was sind Scrum-Meetings?

Im Scrum gibt es neben den verschiedenen Rollen und Artefakte auch vier Scrum Meetings zur Projektsteuerung. Dazu gehören das Sprint Planning, das Daily Scrum, das Sprint Review und die Sprint Retrospektive. Diese vier Scrum Meetings sind im Scrum Guide beschrieben und unter dem Oberbegriff „Scrum Ereignisse “ oder Scrum Aktivitäten aggregiert. Das Leitwerk möchte damit klarstellen, dass es sich um Arbeit und keine Treffen handelt. Alle Scrum Ereignisse unterliegen festgelegten Zeitfenstern, sogenannten time boxes. Diese müssen eingehalten werden und dürfen nicht überschritten werden.

 

Das Sprint Planning

Das Sprint Planning wird aufgrund seiner Struktur und der verschiedenen Themen oftmals in zwei Teile gegliedert. Im ersten Teil des Meetings steht die Beantwortung der Frage „Was kann im kommenden Sprint entwickelt werden?“ im Vordergrund. Es findet eine Prüfung statt, wie viele Einträge des Product Backlogs im bevorstehenden Sprint umgesetzt werden sollen. Im zweiten Teil geht es darum, „wie wird die Arbeit im folgenden Sprint erledigt?“ Das Scrum Team plant hierbei, wie es diese Erwartungen und Anforderungen im Detail durchführen und realisieren kann.

 

Das Daily Scrum

Das Scrum Team trifft sich täglich für zirka eine Viertelstunde, am besten am Arbeitstag-Anfang. Bei diesem Daily Scrum sind oft auch der Scrum Master und Product Owner anwesend. Jedoch verhalten diese sich passiv. Der Sinn und Zweck des Daily Scrums ist die Kommunikation und der Informationsaustausch über aktuelle Entwicklungsprozesse.

 

Das Sprint Review

Am Ende eines Sprints steht das Sprint Review, bei dem das Scrum Team das Inkrement kontrolliert, um gegebenenfalls das Product Backlog zu assimilieren und auszugleichen. Der Stakeholder und das Scrum Team diskutieren die Resultate und besprechen die weiteren Vorgänge.

 

Die Sprint Retrospektive

Das Scrum Team überprüft gemeinsam die vorangegangenen Verfahrensweisen und Methoden, um zukünftig leistungsfähiger und wirksamer zu arbeiten. Diese Sprint Retrospektive stellt somit einen Rückblick dar. Der Scrum Master unterstützt das Team, indem er Verbesserungsvorschläge im Meeting einbringt, die die Gruppe im nächsten Sprint sinnvoll umsetzen kann. Diese Verbesserungsmaßnahmen werden geplant und dokumentiert.

 

Wie sieht ein Scrum-Arbeitsablauf aus?

 

Am Anfang steht die Vision

Am Beginn eines Projekts, welches nach der Scrum Methode gesteuert wird, steht die Entwicklung einer Produktvision. Ohne eine Vorstellung und einem Zukunftsbild von einem gewünschten Produkt, kann kein zufriedenstellendes Resultat erzielt werden. Die Vision kann am Projektbeginn noch unpräzise sein. Diese wird dann im Laufe des Entwicklungsprozesses weiter konkretisiert und Details werden vertieft. Der Product Owner legt das Product Backlog auf der Grundlage der Produktvision fest.

 

Die Hauptarbeit erfolgt in den Sprints

In den Sprints findet die tatsächliche Produktentwicklung statt. Der Produkt Owner stellt dem Scrum Team das Product Backlog am Anfang eines Sprints vor. Das selbstorganisierte Scrum Team bestimmt dann eigenständig, wie es die Anforderungen und Erwartungen im bevorstehenden Sprint umsetzen möchte. So entsteht das Sprint Backlog.

 

Finale Sprints

Das Scrum Team gibt am Ende des Sprints den Stakeholdern eine Präsentation. In einem Review stellt es die Extension (Ausweitung) und Steigerung der Funktionalität vor. Dadurch können Stakeholder die Funktionalität und Leistungsmerkmale überprüfen und in diesem Zuge auch Wünsche und Änderungen einbringen, welche anschließend vom Scrum Team vorgenommen werden können. Außerdem analysiert das Scrum Team den Entwicklungsprozess und die Kooperation im vorherigen Sprint. Es findet also zum Schluss eines Sprints die Retrospektive statt. Gegebenenfalls können so Korrekturen und Überarbeitungen veranlasst und entwickelt werden.

Quelle: https://www.it-daily.net/

 

Was sind gute Gründe für agiles Projektmanagement?

Seit Jahren profitieren Unternehmen und Betriebe von agilem Projektmanagement und bestätigen damit, dass es sich um eine nachhaltige Entwicklung handelt.

1. Agiles Projektmanagement erkennt Schwierigkeiten im Ansatz Eine rechtzeitige Erkennung und Analyse von Problemen ist beim Einsatz agiler Methoden und flexibler Systeme möglich. Die permanente Kommunikation zwischen allen am Projekt beteiligten Personen erstickt kontroverse Ansichten und Konflikte im Keim. Teams, die in zielführenden Meetings und in Selbstorganisation arbeiten, können schnell auf Wünsche und Änderungen der Anwender und Kunden reagieren. Die Produktqualität wird mit einer agilen Vorgehensweise erheblich gesteigert.

2. Agiles Projektmanagement unterstützt und stärkt Mitarbeiter Grundsätzlich sollen beim agilen Projektmanagement Menschen Priorität haben. Dies ist bereits klar in dem Agilen Manifest formuliert. Alle beteiligten Personen wie beispielsweise Kunden, User und auch Mitarbeiter sollen im Vordergrund stehen. Dadurch wird die Wertschätzung menschlicher Fähigkeiten und Qualitäten enorm gesteigert. Speziell im Scrum ist dies durch selbstorganisierte Teams mit Eigenverantwortung und flachen Hierarchien möglich. Agiles Projektmanagement kann somit auch als eine moderne Denkweise und Einstellung verstanden werden. Denn dabei wird die Führungsebene auf den neuesten Stand gebracht, bringt Mitarbeiter zur nötigen Motivation und steigert den Erfolg des Unternehmens.

3. Agiles Projektmanagement stellt die Bedürfnisse der Kunden in den Mittelpunkt Weltweite Vernetzung und wirtschaftliche Prozesse unterliegen in unserer heutigen Zeit permanenter Veränderungen. Aus diesem Grund bietet agiles Projektmanagement viele Vorteile. Flexibel organisierte Projekte können in selbstorganisierten Teams schnell bearbeitet werden. Auf kurzfristige Veränderungen können am Projekt beteiligte Personen rasch reagieren, da der Entwicklungsprozess auf immer wieder neue Anforderungen und Wünsche angepasst werden kann.

 

Agiles Projektmanagement in der Praxis umsetzen

Unabhängig von der gewählten Methode kann agiles Projektmanagement in Unternehmen mit folgenden Erkenntnissen und Vorgehensweisen in der praktischen Arbeitswelt umgesetzt werden.

Einsatz eines selbstorganisierten Teams mit Eigenverantwortung Ein wichtiges Element beim agilen Projektmanagement ist der Einsatz von Teams, die aus verschiedenen Spezialisten bestehen. Der Erfolg liegt hauptsächlich auf einem gut funktionierenden, agilen Team. Dieses muss vom Projektführer wirksam eingesetzt werden. Er sollte dem Team eine gemeinsame Mission mit einer entsprechenden Vision und einem gemeinsamen Ziel geben. Außerdem sollte das Team mit der nötigen Kompetenz ausstatten.

Ein agiles Team besteht aus Mitarbeitern, die selbst genügend Know-how und Fachwissen besitzen, dass sie auf keine weitere externe Unterstützung angewiesen sind, um Schwierigkeiten und Probleme in den Griff zu bekommen.

Der Projektleiter und entsprechende Führungskräfte schaffen dem Team eine gutes Arbeitsumfeld und stattet dieses mit den notwendigen Ressourcen und Utensilien aus. Auch wenn das Team viel in Eigenregie arbeitet, sollte es eine gewisse Struktur bekommen. Die Zusammenstellung muss so passend gestaltet werden, dass alle Rollen möglichst optimal eingesetzt werden und bei längeren Wegbleiben eines Team-Mitglieds dieses sofort ersetzt werden kann. Agiles Projektmanagement basiert auf Teams mit Experten, die aber auch in anderen Bereichen innerhalb des Projekts arbeiten und somit flexibel agieren können. Wird ein Team neu zusammengestellt, dann können Coaches und externe Spezialisten helfen, dass dieses zu einer gut kooperierenden Gruppe mit Zusammenhalt und Kommunikation zusammenwächst. Außerdem kann es zu Beginn förderlich sein, wenn ein neues Team eine gewisse Anleitung zur Eigenverantwortung und Selbstorganisation bekommt.

Anwendung von agilen Retrospektiven Projektleiter sollten mit agilen Teams gewonnene Erkenntnisse und Resultate in einer Retrospektive zusammentragen. Daraus können alle am Projekt Beteiligten profitieren und auf zukünftige Entwicklungsprozesse anwenden. Das Projektteam kann sich dabei in strukturierter Form austauschen und notwendige Maßnahmen für weitere Prozesse vornehmen. Die Retrospektive ist ein Meeting, welches auf die vergangenen Prozesse zurückblickt und positiv auf Fortschritte schaut. Agile Retrospektiven fördern die Selbstorganisation des Teams, können meist mit wenig Aufwand umgesetzt werden und stellen somit ein sehr sinnvolles und effektives Instrument dar.

Inanspruchnahme von agilen Metriken Im agilen Projektmanagement bringen veränderte Anforderungen der Kunden auch einen Wandel in der Projektsteuerung mit sich. Dazu werden immer mehr agile Metriken eingesetzt. Durch die Auswahl, das Verfolgen und das Übernehmen von bestimmten Parametern wird die Motivation und das Engagement aller am Projekt beteiligten Personen, insbesondere dem agilen Team, vermittelt. Zu agilen Metriken gehören unter anderem:

Velocity berechnet die Geschwindigkeit, die ein agiles Team im Entwicklungsprozess beziehungsweise im Verlauf eines Sprints erreicht.

Happiness Index misst den Einfluss negativer Faktoren wie beispielsweise Schwund im Team, Überstimmen von Team-Entscheidungen, Veränderungen im Entwicklungsprozess.

Burndown-Charts ermitteln den Projektfortschritt.

Technische Schulden schätzen sogenannte Altlasten in einem Programmcode, welche zukünftig vermieden und eliminiert werden sollen. Diese Metriken haben ihre Daseinsberechtigung und zeigen verschiedene Gesichtspunkte und Kriterien des Projektprozesses sowie der Team-Performance und dessen Entwicklung. Sie fokussieren sich auf diverse Sektoren und Kompetenzen im agilen Projektmanagement. Die meisten agilen Metriken sind förderliche Instrumente für ein agiles Team und sollen ihm helfen, seine eigenverantwortliche Arbeit zu optimieren.

 

Kritik / Fazit

Wie bei jeder Methode oder System gibt es auch beim agilen Projektmanagement kritische Betrachter. Unternehmen beschränken sich oftmals bei der Umsetzung von agilen Projekten auf die Einführung von Scrum und bemerken nach einiger Zeit, dass die unternehmerischen Prozesse nicht zu der ausgesuchten agilen Methode passen und schließlich nicht harmonieren. Außerdem glauben viele Unternehmer und Projektleiter, dass agile Vorgehensweisen jegliche Probleme und Schwierigkeiten bei Entwicklungsprozessen und in deren einzelnen Phasen darstellen. Doch dies ist nicht der Fall, denn die hauptsächlichen Hindernisse gelten für agile Methoden genauso wie für klassische Verfahren. Somit gehört zu einem erfolgreichen agilen Projektmanagement die Berücksichtigung und Verbindung aller Leitsätze, Prinzipien und Elemente.