Matthias Kuchem

In meinem letzten Artikel über die Problematik bei Projekten in die Zukunft gucken zu können, habe ich ja schon darauf hingewiesen, dass im agilen Kontext der Fortschritt durch kurze Experimente kommt. In meiner Vorlesung IT-Management kommen wir dann immer schnell an die Stelle, wie denn jetzt Softwarearchitekturen entstehen. Für die Nicht-ITler: Die Architektur ist quasi wie der Bauplan für die Software. Schließlich lernen die Informatikstudenten in mehreren Vorlesungen, wie eine gute Softwarearchitektur aufgebaut wird und wie wichtig es ist, das im Voraus zu machen. Auch hier ist wieder die Vorannahme, das vor der Entwicklung bekannt ist, wie das Ergebnis aussieht und deshalb wird dann die beste Architektur dafür gewählt.

Ich habe in meiner Studienzeit mal für ein Unternehmen gearbeitet, für das ich ein Verwaltungs-System entwickeln sollte. Mein Kontakt und Auftraggeber hat mir vorher genau erklärt, wie alles funktionieren soll und ich habe, wie ich es in der Uni gelernt habe, eine passende Architektur dazu entworfen. Ich fand das so eine tolle Lösung und hab mich gefreut das Anwenden zu können, was ich in der Uni lerne. Während des Projektverlaufs und insbesondere zum Ende hin, stellte sich jedoch heraus, dass die Anforderungen falsch und unvollständig waren. Ich musste deshalb immer wieder Korrekturen machen und den Funktionsumfang erweitern. Leider passte die Architektur nur überhaupt nicht zu dem, was jetzt letztlich verlangt wurde. Irgendwie habe ich das dann noch da reingequetscht nur das Ergebnis war Softwaretechnisch echt nicht toll. Selbstverständlich war aufgrund des Zeit- und Kostendrucks seitens des Auftraggebers explizit nicht gewünscht, dass ich die Architektur noch einmal überarbeite.

Ist jetzt also die gesamte Softwaretechnik überflüssig oder falsch? Wir können nunmal das Ergebnis zu Beginn nicht kennen – in komplexen Umgebungen. Ist alles falsch was die Studenten da lernen? Nein – natürlich nicht. Das agile Manifest fordert in den Prinzipien ganz explizit technische Exzellenz. Es ist sehr wichtig, dass die Entwickler ein gutes Verständnis von Softwarearchitekturen haben, damit sie überhaupt beurteilen können, wie qualitativ ihre Lösung ist. Nur wie kommt es jetzt zu einer guten Architektur, wenn wir diese nicht im Voraus planen? Indem wir mithilfe unserer Kenntnisse und einem besonderen Augenmerk die Architektur immer mit entwickeln und uns kontinuierlich auch Zeit dafür nehmen, die Softwarequalität auf einem guten Standard zu halten. Die Kenntnisse der Softwaretechnik sind dann eben die Grundlage, um kontinuierlich die passenden Lösungen und Anpassungen zu finden. Dazu gibt es heutzutage einige gute Lösungen und Stichworte, die in diesem Bereich weiterhelfen: Clean Code, Clean Architecture, Test Driven Development (TDD) und Behaviour Driven Development (BDD) fallen mir da als erstes ein.

Bei klassischen Wasserfallprojekten ist die Vorannahme, dass ich zu Beginn eines Projektes in die Zukunft gucken kann und deshalb einen detaillierten Projektplan usw. erstellen kann. Es gibt Projekte bei denen das relativ gut funktioniert. Wenn das Problem z.B. mit guten bekannten Praktiken und Methoden gelöst werden kann. In solchen Fällen machen klassische Projekte auch heute noch total Sinn. Wenn ich mal ein Haus baue, möchte ich gerne, dass da ein Architekt ist, der einen Plan hat und für einen guten Ablauf sorgt. Wenn das Dach drei mal überarbeitet werden muss, fände ich das nicht so toll → klassische Projektplanung.

Projekte auf die das zutrifft betreffen komplizierte Probleme. Auch sehr komplizierte Projekte lassen sich mit Wissen und Erfahrung meistern. Spannend wird es hingegen bei komplexen Projekten. Was ist denn, wenn schon zu Beginn des Projekts klar ist, dass überhaupt nicht klar ist, wie das ganze funktionieren soll? Wenn die Vorannahme die Zukunft voraussagen zu können offensichtlich völlig daneben liegt und nicht mit kleineren Plananpassungen ausgeglichen werden kann? Dann funktioniert das klassische Projektvorgehen einfach nicht.

Ein wesentlicher Bestandteil von komplexen Umgebungen ist, dass ich im Voraus nicht genau wissen kann, was passiert, wenn ich etwas tue. Deshalb brauchen wir hier nicht planen. Stattdessen machen wir Experimente. Denn immerhin können wir im Nachhinein feststellen, wie das Resultat zustande gekommen ist. Jeder kennt das ja auch aus dem Alltag: „Nachher ist man immer schlauer“. Das ist ein wesentliches Element von Agile.

Jede Iteration im agilen Kontext ist ein kleines Experiment. Da ich nicht weiß, wie die Zukunft aussieht, mache ich eine sehr kleine Annahme und probiere aus was passiert. Wenn es gut geht, alles super, auf zum nächsten Experiment. Wenn es schief geht, alles super, wir haben gelernt und das in sehr kurzer Zeit. Mit dem neuen Wissen, auf zum nächsten Experiment.

Fazit: Bei komplexen Problemen sollte auf keinen Fall klassisch geplant werden, da die Vorannahme der Planung grundlegend falsch ist.

In meinem letzten Artikel über das Gesetz der Nähe bin ich über die Aussage „die sollen nicht reden, sondern arbeiten / programmieren“ gestolpert, welche mich zu dem heutigen Artikel veranlasst. In den klassischen Strukturen geht es immer darum, alles am Ergebnis zu messen. Dementsprechend produziert ein Entwickler kein Ergebnis, wenn er redet statt zu programmieren. Natürlich muss auch der Entwickler mal was anderes machen als programmieren. Dazu gibt es ja das Pflichtenheft (Umsetzungskonzept), so dass er immer wenn er sich mit Anforderungen beschäftigt auch ein Ergebnis produzieren kann, das auch leicht abgerechnet werden kann. Dann schreibt er eben. Denn das Pflichtenheft lässt sich ja aus dem Lastenheft (Fachkonzept) ableiten, wodurch die Arbeit der Anforderer in messbare Ergebnisse gepackt wird.

Im agilen Kontext konzentrieren wir uns statt dem Ergebnis (engl. output) auf den Nutzen (engl. outcome). In dieser Betrachtungsweise hat das Reden einen großen Mehrwert, wenn damit Nutzen erreicht wird. Das Klären von Anforderungen z.B. hat einen großen Mehrwert und geht mündlich deutlich einfacher und schneller, als nur durch das Verfassen irgendwelcher Konzepte. Das ist jetzt noch ein einfaches Beispiel, weil sich die Stunden gut messen lassen und auch der Erfolg auf das Ergebnis einigermaßen leicht festgehalten werden kann.

Jetzt kommen wir zur Rolle des Scrum Masters oder Agile Coaches. Ein Mitarbeiter, der natürlich auch bezahlt werden will und kein einziges Ergebnis (im Sinne von output, was dem Kunden verkauft werden kann) produziert. Seine Rolle orientiert sich vollkommen am Nutzen für das gesamte Team. Da prallen dann häufig mal zwei Welten aufeinander, wenn in einer klassischen Organisation begründet werden soll, wieso jetzt Geld für ein Scrum Master benötigt wird. Es wird verlangt zu erklären, welches Ergebnis er produziert, oder wie genau er das Ergebnis verbessert. Nur genau das ist ja nicht so leicht zu sagen, weil er sich am Nutzen für das Team orientiert.

Genau so finde ich es immer wichtig, dass die mir unterstellten Entwickler für alles Zeit nehmen, was Wirkung zeigt. Dazu gehört auch mal ein kleines Päuschen zum snacken und mit Kollegen quatschen. Oder den Kollegen Urlaubsbilder zeigen. Oder oder oder. Das alles trägt zu Teambuilding bei, dem Wohlbefinden der Mitarbeiter, der (intrinsischen) Motivation und noch vielem mehr. Alles Dinge die zusammen eine große Wirkung, bzw. einen großen Nutzen haben und nicht vernünftig gemessen werden können.

Fokussier dich immer auf den Nutzen. Hast du noch andere Beispiele wo das zutrifft? Schreib es in die Kommentare!

Hier die wissenschaftliche Formulierung: Die Wahrscheinlichkeit, dass zwei Menschen miteinander kommunizieren, ist invers proportional zu der Entfernung zwischen ihnen. Das sagt das Gesetz der Nähe (law of propinquity). Im Grunde ist es nur eine nette Formulierung dafür, dass es wahrscheinlicher ist, dass Menschen miteinander reden, wenn sie nah beieinander sind. Gut, dass es dafür ein Gesetz gibt, da wären wir sonst nicht drauf gekommen.

Andererseits scheint ja genau das in Projekten häufig vernachlässigt zu werden. Im Bereich agiler Projekte sind Projekträume und ähnliche Konstellationen ja vollkommen normal geworden. Sicherlich auch, weil schon das agile Manifest in den Prinzipien schon darauf eingeht, dass das Gespräch von Angesicht zu Angesicht, die effizienteste und effektivste Methode ist Informationen zu vermitteln. Insbesondere in eher klassisch geprägten Organisationen ist es hingegen noch eher die Norm, dass alle halt da sitzen, wo sie sitzen. Der Alltag ist häufig geprägt von der Linienorganisation und die Mitarbeiter sitzen eben bei ihrem Linienvorgesetzten.

Mithilfe des Gesetzes oder einfach kurz darüber nachdenken kommen wir schnell zu dem Schluss, dass die Kommunikation in einem Projekt vermutlich viel besser ist, wenn alle direkt nebeneinander (in einem Raum) sitzen, als wenn alle Projektmitglieder größere Distanzen zwischen sich haben, eventuell auch an ganz unterschiedlichen Standorten sind. Warum werden also nicht immer die Projektmitarbeiter zusammengesetzt?

Das hat viele Gründe und ich bin schon fast am Ende der 10 Minuten angekommen. Deshalb hier nur schnell eine Liste von Stichworten und Behauptungen, die mir dazu einfallen: Kosten / Nutzen, weniger Veränderung für die Mitarbeiter, „die sollen nicht reden sondern arbeiten / programmieren“, „ist doch klar was gemacht werden soll“, 100% Projektgeschäft für Mitarbeiter ist die Ausnahme und ein ganz wesentlicher Punkt: ortsunabhängiges Arbeiten, z.B. zur Vereinbarkeit von Beruf und Familie.

Wann ist denn jetzt der Projektraum gut? Wie kompensiere ich die Entfernung und sorge für bessere Kommunikation? Fragen über Fragen. Hast du auch welche? Oder Antworten? Ab in die Kommentare damit!

Heute habe ich das NewWork+@Ruhrpott MeetUp moderiert und als „Impulsvortrag“ hatten wir Dr. med Claudius Nassabi und Nina Finken zum Thema Ayurveda da. Ich finde es ja immer wieder interessant auch mal über den Tellerrand zu gucken und ehrlich gesagt wusste ich vorher nicht genau, was Ayurveda eigentlich ist. Bisher hab ich nur mal auf der Speisekarte bei einem Inder „ayurvedische Gerichte“ gesehen oder von irgendwelchen Ayurveda-Massagen und -Kuren gehört.

In NewWork eingegliedert haben wir es unter der These, dass es zur persönlichen Leistungsfähigkeit beitragen kann und das ist eben auch im Unternehmen ganz wesentlich. Alle sollen sich wohl fühlen und Energie haben. Die Frage des Abends war deshalb: „Ist Ayurveda ein Ansatz um das zu erreichen?“. Die persönliche Leistungsfähigkeit ist auch eine der Dimensionen der modernen Arbeitswelt aus dem Intrinsify-Netzwerk, welches sich rund um NewWork dreht (7+1 Dimensionen der modernen Arbeitswelt).

Jetzt weiß ich, dass es den Menschen ganzheitlich betrachtet und auch individuell. Ernährung ist ein Grundpfeiler und gleichzeitig eben nur ein Teil davon. Es ist auch nicht die eine Art sich zu ernähren und dann ist jeder gesund. Ayurveda betrachtet ganz individuell die Situation und Bedürfnisse. Zumindest mal in meinen Worten wiedergegeben, was ich in der kurzen Zeit verstanden habe.

In einer Vertiefungssession beim anschließenden OpenSpace haben wir dann noch mal mehr die Brücke zur Arbeit geschlagen, als das individuelle Wohlbefinden der Mitarbeiter. Ayurveda betrachtet ja auch den Körper ganzheitlich und Claudius hat vorgeschlagen, mal ein Unternehmen als Körper zu betrachten. Genau wie im menschlichen Körper ist es wichtig, dass alles im Fluss ist. Auch viele andere Ayurveda-Elemente können da übertragen werden. Das ist auf jeden Fall ein interessanter Ansatz.

Kennst du Ayurveda schon? Hast du Erfahrungen damit? Wie beziehst du das auf das Thema Arbeit? Schreib es in die Kommentare!

Immer wieder mal ist mir die Übung rund um das Rad des Lebens (engl. Wheel of Life) begegnet, bei der die eigenen Lebensbereiche eingeschätzt und der momentane Stand eingeschätzt wird. Dazu gehören z.B. Finanzen, Familie, Freunde, Beruf(ung) usw. Ich überlege mir also, wo will ich in diesem Lebensbereich hin und wie weit bin ich da schon.

Interessant fand ich da bei einer der Übungen die Variation, auch noch für jeden Bereich ein Vorbild zu benennen. Dabei ist mir aufgefallen, dass ich die Ideen zu meinen Zielen in vielen Bereichen aus Sachbüchern habe, bzw. von deren Autoren. Es heißt ja immer „zeig mir die 5 Menschen mit denen du dich am meisten umgibst und ich sag dir wer du bist“. Zu einigen Themen habe ich sehr viele Sachbücher gelesen. Gleichzeitig gab es damals in meinem Umfeld niemand, der in dem Bereich auch nur annähernd die gleichen Ziele hatte wie ich. Das Ergebnis ist, dass die Autoren und deren Texte unterbewusst zu meinen Vorbildern in den Bereichen geworden sind. Vorher war mir das gar nicht klar. Beim Lesen setzen wir uns ja den Gedanken der Autoren aus, genauso wie wenn wir uns mit anderen Menschen unterhalten.

Bücher erweitern unseren Horizont und geben uns ganz neue Möglichkeiten. Wenn ein neues Thema aufkommt, beschäftige dich mit den Menschen, die auf diesem Gebiet besonders gut sind. Wie sind sie dahin gekommen? Wer sind sie? Sind sie gute Vorbilder in dem Bereich? Hier ist eben der spannende Punkt. Die Lebensbereiche sind so allgemeine Themen, dass es da ganz unterschiedliche Betrachtungsmöglichkeiten und Meinungen gibt. Es macht durchaus Sinn, da nicht einfach das erstbeste Buch oder den erstbesten Autor zu nehmen, dessen Ansicht gerade trendy ist. Stattdessen lohnt es sich etwas zu suchen, das zu einem selbst passt. Ziele lassen sich auf unterschiedlichsten Wegen erreichen. Für den Bereich Finanzen z.B. gibt es viele Möglichkeiten. Ein Vorbild das Reichtum durch ausbeuten anderer predigt ist da vielleicht ungünstig – nur um mal ein Extrembeispiel zur Verdeutlichung zu nennen.

Heute war ich auf dem Liberating Stuctures Meetup zum Thema Commitment. Das ist auch so ein interessantes Plastikwort, wo jeder sagt „Ja klar, Commitment. Wollen wir. Brauchen wir.“ Jetzt bin ich kein großer Freund davon die eine Wahrheit bei einer Begriffsdefinition für mich zu beanspruchen und gleichzeitig gibt es ja durchaus interessante Aspekte, auf die wir uns vielleicht einigen können.

Den Begriff finde ich an sich vor allem deshalb so spannend, weil er ja immer wieder zu den agilen Werten gezählt wird – wo auch immer die jetzt herkommen. Ganz konkret ist jedenfalls im Scrum Guide die Rede von Commitment und wie wichtig das ist. Es ist also eine gute Idee seinem Scrum Team zu sagen, dass es notwendig ist, dass sie commited sind. Nur was heißt das jetzt eigentlich.

Genau da ist schon ein wesentlicher Punkt. Für mich kann Commitment nur aus mir selbst heraus entstehen. Für mich ist Commitment etwas, wozu ich mich aus freien Stücken entscheide. Es kann also eben nicht von außen entschieden werden, ob ich committed bin.

Es gibt ja auch immer wieder die Leute die meinen alles übersetzen zu müssen. Da kommt dann sowas wie Selbstverpflichtung heraus. Meiner Meinung nach passt das nicht zu Commitment, weil für viele Menschen Verpflichtung und damit Selbstverpflichtung negativ konnotiert ist. Commitment hingegen ist etwas positives, worüber man sich freut. Auch Engagement habe ich als Übersetzung gesehen und auch das passt irgendwie nicht. Zu committment gehört für mich eben auch manchmal, es doch noch durchzuziehen, auch wenn ich nicht mehr so engagiert oder motiviert dabei bin. Da passt dann die Verpflichtung wieder besser. Deshalb vielleicht einfach nicht übersetzen. Das machen wir im agilen Kontext tendenziell ja eh lieber nicht – genau um diese Uneindeutigkeiten zu minimieren.

Da bin ich jetzt gerade an der Motivation vorbeigekommen. Commitment scheint auch weiterzugehen, wenn die Motivation weg ist. Spontan würde ich andersrum jedoch sagen, dass Motivation mit Commitment startet. Erst wenn ich mich zu etwas committe bin ich motiviert dabei. Der ist jetzt vielleicht auch zu einfach, weil Commitment dafür wiederum zu schwammig ist.

Faszinierend wie viele Aspekte da zusammenkommen und das ist nicht annähernd alles, was wir auf dem MeetUp dazu rausgefunden haben. Das ist ja ein generelles Problem bei so Worten die nicht anfassbar sind. Vertrauen, Projekt, Verantwortung, Transparenz. Jeder versteht unter solchen Worten etwas anderes.

Ich erlebe es bei Problemen in der Entwicklung öfters, dass die Schuld auf die schlechten oder falschen Anforderungen geschoben wird. Damit natürlich direkt oder indirekt auf den Kunden, der ja sagt, was er haben will. In der heutigen Zeit, in komplexen Umgebungen, ist es nur gar nicht so leicht im voraus festzustellen, was genau eigentlich gebraucht wird. Das zeichnet ja gerade viele Probleme der heutigen Zeit aus: Wir wissen im Voraus einfach nicht, was die richtige Lösung ist.

Jeff Sutherland, einer der Gründer des agilen Frameworks Scrum, nennt als einen der Gründe für die Entwicklung von Scrum das Gesetz von Humphrey. Demnach weiß ein Kunde oder Benutzer erst was er möchte, wenn er sieht was er in der Produktion bekommt (vielleicht nichtmal dann). Ich kann leider keine vernünftige Quelle für das Gesetz finden und kann das nur aus eigener Erfahrung und der Logik der komplexen Umgebungen bestätigen. Das ist erstmal eine Gegebenheit die es zu akzeptieren gilt.

Genau deshalb bringt es einfach nichts, sich darüber aufzuregen, dass die Anforderungen schlecht oder falsch waren. Sie waren aus der Perspektive und zu der Zeit in der sie geschrieben wurden vermutlich genau richtig. Nur haben wir in der Entwicklung eben neue Erkenntnisse gewonnen und gelernt, dass diese Idee nicht so gut war. Im Nachhinein sind wir eben schlauer. Hier kommt Agilität ins Spiel und einige Maßnahmen die in agilen Umgebungen ergriffen werden um damit besser umzugehen.

Eine Lösung sind kurze Iterationsschleifen, also das häufige echte Ausliefern an den Kunden, der dann direkt Feedback geben kann. Wenn eine Anforderung oder Lösung sich dann als ungünstig herausstellt, erfährt das Team das innerhalb einer Iteration, also z.B. 2 Wochen. Wir begrüßen dann die neue Erkenntnis und die Veränderung die uns auf diesem Wissen basierend ermöglicht wird. Das steht im Gegensatz zu einem klassischen Projekt, wo der Nutzen typischerweise erst am Projektende realisiert wird und diese Fehlannahme eventuell erst nach Monaten oder Jahren auffällt.

Im vorigen 10 Minuten Beitrag über Produktentwicklung habe ich schon über das Product Backlog geschrieben, welches sich inzwischen in der agilen Welt stark verbreitet hat. Ähnlich verhält es sich mit User Storys, mit denen das Product Backlog üblicherweise gefüllt wird. Diese entstanden ursprünglich im Zusammenhang mit dem agilen Framework eXtreme Programming (XP), welches unter anderem von Ron Jeffries entwickelt wurde. Als das entwickelt wurde, gab es den Begriff agil in diesem Sinne noch nicht, aber das ist eine andere Geschichte.

Effektiv kommt also quasi jeder der sich im agilen Kontext bewegt zwangsläufig mit User Storys in Berührung. Den Effekt den ich dabei häufig beobachte ist die folgende Aussage: „Das sind Anforderungen die in einer speziellen Form aufgeschrieben werden“. Das ist jetzt nicht grundsätzlich falsch, nur das was daraus gemacht wird ist zum Teil fatal. Das Ergebnis ist dann eben häufig, dass alles was früher in einem Lastenheft oder Fachkonzept stand, irgendwie in diese User Storys gepresst wird. Nur geht dann der ganze Sinn dieser schönen Praktik verloren.

Die Grundidee von User Storys ist, dass es eine Einladung zum Gespräch ist. Es erzählt eine Geschichte und Menschen hören und erzählen gerne Geschichten. Indem also eine Geschichte rund um eine Anforderung formuliert wird, wird die Idee dazu transportiert. Wenn jetzt versucht wird, alles rund um die Anforderung exakt zu spezifizieren, warum dann noch reden? Das ist ja das Dilemma, weshalb dieses Konzept entstanden ist. Das Gespräch zwischen Anforderern und Umsetzern soll ja gerade unterstützt werden.

Ron Jeffries schlägt die Formel der drei Cs für gute User Storys vor: Card, Conversation und Confirmation. Card, also Karte bezieht sich darauf, dass die User Story eine greifbare Einheit sein sollte, üblicherweise eine Metaplankarte oder ein Post-It. Sie beschränkt außerdem bewusst den Platz, damit eben nicht alle Details darauf geschrieben werden können. Conversation, also Gespräch soll die Grundlage sein. Daher kommt der Spruch mit „User Story ist eine Einladung zum Gespräch“. Confirmation, also Bestätigung bezieht sich auf die Akzeptanzkriterien. Es ist üblich auf der Rückseite der Karte mit der User Story Kriterien zu definieren, welche erfüllt sein müssen, damit diese Story als erfüllt gilt. Diese Kriterien entstehen am besten auch in Folge des Gesprächs und unterstützten das gemeinsame Verständnis, welches darauf basierend erlangt wurde. Sie bilden dann übrigens auch eine Grundlage für testgetriebene Entwicklung.

Ich würde mich so freuen, wenn ich mehr gute User Storys sehen würde und weniger so detaillierte User Storys, dass sie zusammen eine vollständige Spezifikation ergeben.

In der schwarz / weiß Welt gibt es klassisches und agiles Projektmanagement. Eigentlich ist das an sich jedoch schon missverständlich. Agile Entwicklung ist eben grundsätzlich eine andere Betrachtungsweise, so dass der Begriff agiles Projektmanagement viele fehlerhafte Konzepte impliziert. Es fängt schon damit an, dass wir in der agilen Welt keine Projekte machen, sondern Produkte entwickeln.

Das Wort Projekt ist in den Köpfen vieler Menschen elementar mit dem magischen Dreieck aus Kosten, Umfang und Zeit verbunden. Wenn es genauer sein soll, können wir natürlich auch die 6 Dimensionen aus PRINCE2 nehmen: Kosten, Umfang, Nutzen, Qualität, Zeit und Risiko. Diese Werte sind bei einem klassischen Projekt fix (mit ein paar Puffern in der Praxis natürlich). Im Agilen wollen wir jedoch bewusst in der Lage sein, auf Änderungen zu reagieren. Deshalb ist bei agilen Projekten der Umfang und der Nutzen nicht fix. Stattdessen ergreifen wir verschiedene Maßnahmen, um sicherzustellen, dass immer der größtmögliche Nutzen im Verhältnis zu den anderen Dimensionen entsteht.

Dazu hat sich im agilen Kontext das Product Backlog etabliert. Darin halten wir sowas wie Anforderungen an das Produkt fest, in denen wir insbesondere den Nutzen benennen. Dieses Backlog wird fortlaufend priorisiert und ermöglicht uns darüber die Steuerung des Projektverlaufs. Jetzt kommt ein ganz wesentlicher Punkt: Das Product Backlog ist dem Produkt zugeordnet und nicht dem Projekt. Es enthält alle Anforderungen und Ideen für das Produkt, auch solche die nicht im Rahmen des Projekts umgesetzt werden. Das Product Backlog wird auch nach dem Projekt zur Pflege und Weiterentwicklung des Produkts weiter genutzt. Einen Projektplan gibt es in „agilen Projekten“ im klassischen Sinne nicht, fast alles wird aus dem Product Backlog abgeleitet – obwohl der Begriff Projekt für viele auch Projektplan impliziert.

Andererseits wäre es natürlich möglich, das Product Backlog als moderne Form eines Projektplans aufzufassen. Die Welt ist eben nicht schwarz / weiß. Das sind nur ein paar kleine Beispiele dafür, warum der Begriff agiles Projektmanagement einfach ungünstig ist. Im wesentlichen ist es agile Produktentwicklung. In der Praxis werden dann häufig Projektmanagementansätze darübergestülpt, so dass eine hybride Form aus agil und klassischem Wasserfall entsteht.