Agiles Produkt- und Projektmanagement hin oder her. Es geht darum, den Kunden zu erreichen.
Ein Produkt, das kein Problem einer tatsächlich existierenden, identifizierbaren Person löst, ist kein Produkt, an dem es sich zu arbeiten lohnt.
Marc-Uwe Kling
TL;DR:
Hier geht es zum agilen Manifest: https://agilemanifesto.org/iso/de/manifesto.html
Hand auf’s Herz: Wer kennt das agile Manifest? Okay, 1-5 Entwickler. Nicht berauschend viele.
Und wer von den Projektmanagern? Vermutlich nur ein Bruchteil. Und ich sehe auch den Grund dafür. Aber dazu später mehr.
Definition Agile Entwicklung
Es geht darum, etwas besser zu machen. Nein, nicht irgendwo im speziellen. Grundsätzlich in Produkten. Und vor allem in denen, die irgendwie mit Softwareentwicklung zusammenhängen.
Die Idee ist relativ einfach: Wir legen den Fokus auf Interaktionen mit den Leuten, die eine funktionerende Software haben wollen. Und damit die Software auch nicht nur technisch, sondern vor allem für den Kunden funktioniert, arbeiten wir mit ihm zusammen. Wir reagieren sogar auf die Veränderungen, die dabei entstehen.
Inspect & Adapt: agile Basis
Auch ein wichtiger Teil sind die Prozesse und Werkzeuge, die wir dazu einsetzen. Falls ein Prozess nicht passt, passen wir diesen an. Und falls ein Werkzeug nicht das Richtige für diese spezielle Situation passt, ersetzen wir es.
Inspizieren und adaptieren, zu gut deutsch 🙂
Dokumentation
Ganz klar: eine Dokumentation sollte umfassend sein, wenn es nötig ist. Insbesondere bei technischen Schnittstellen, die dem Kunden zur Verfügung gestellt werden.
In vielen Fällen jedoch kann man sich solch eine Dokumentation ersparen. Und zwar genau dann, wenn die Applikation selbsterklärend ist. So selbsterklärend, dass der Kunde sie ohne Schwierigkeiten einfach nutzen kann.
Wie man das schafft? Ganz einfach: durch Zusammenarbeit mit dem Kunden.
Vorsicht, Falle: Agilität bedeutet nicht, Dokumentation wegzulassen und dadurch diesen Punkt abzuhaken. Agilität bedeutet an dieser Stelle, so wenig Dokumentation wie möglich zu benötigen.
Zusammenarbeit
Was wir uns von Zusammenarbeit erhoffen, haben wir gerade schon gesehen. Am Beginn einer Zusammenarbeit steht zudem meist noch der vertragliche Aspekt ins Haus.
Verträge sind wichtig, sie regeln Bedingungen wie Zahlungsmodalitäten, klären rechtliche Eckpunkte und weitere Dinge. Im agilen Sinne ist es auch, dies festzuschreiben. Nicht alles lässt sich doch im Vorhinein regeln. Da hilft es auch nicht, so zu tun, als ob.
Besser ist es, nur die tatsächlichen Fakten und Bedingungen mit aufzunehmen. So machen sich beide Seiten das Leben einfacher, wenn einzelne Punkte nachverhandelt werden müssen.
Es gilt also auch hier: so viel wie nötig, so wenig wie möglich. Denn Anpassungen werden kommen.
Sind über eine konstruktive Zusammenarbeit leichter handzuhaben, als über Rechtsabteilungen, die Verträge anpassen müssen.
Letzten Endes kostet es sonst vor allem das, was beide Seiten zu wenig haben: Zeit.
Planung ist wichtig, auch im Agilen
Immer wieder höre ich, dass im agilen Umfeld nicht geplant wird.
Das ist falsch. Denn Planung passiert, aber anders. Warum?
Der größte und wichtigste Unterschied ist der zwischen Projekten und Produkten.
Nein, Produkte werden nicht in Projekten umgesetzt. Zumindest nicht, wenn wir von agiler Softwareentwicklung sprechen.
Projekte gehen davon aus, dass zu Beginn der Scope feststeht, was entwickelt werden soll, damit ein Kunde damit arbeiten kann.
Die Entwicklung eines Produktes geht davon aus, dass nicht zuverlässig vorhergesagt werden kann, wie die Software am Ende genau aussieht. Vielmehr ist ein systematisches, geplantes herantasten das Mittel der Wahl.
Projektmanager und Agilität
Also liegen Projektmanager und Product Owner gar nicht so weit auseinander?
Ganz genau!
In vielen Unternehmen herrscht Frust und Unverständnis. Unzufriedene Mitarbeiter verlassen Unternehmen. Doch genau das kann verhindert werden.
- Projektmanager wollen: das beste Produkt schnellstmöglich dem Kunden zur Verfügung stellen.
- Produktmanager wollen: das beste Produkt schnellstmöglich dem Kunden zur Verfügung stellen.
Krass oder? Der Unterschied liegt ausschließlich in der Sichtweise.
Wie wird ein Produkt erstellt: Ist es das Ergebnis eines Projekts? Oder ist es das Ergebnis von Zusammenarbeit?
Dadurch nutzen beide Rollen unterschiedliche Hilfsmittel und Werkzeuge.
Fazit
Auch agile Projektmanager haben es wirklich schwer, Agilität zu erlernen. Sie kennen ihre Tools blind. Dadurch ist es schwierig, sich auf einen anderen Prozess der Planung einzulassen.
Diejenigen, die immer schon agil gearbeitet haben, haben eben so wenig Verständnis für diese „veraltete“, „antiquiierte“ Sichtweise, Produkte zu bauen.
Was beiden Seiten fehlt, sind gemeinsame Tools. Es gibt nicht nur richtig oder falsch.
Vor allem ist es auch keine Schande, sich Hilfe ins Haus zu holen, spätestens, wenn diese Situation erkannt wurde und agiles Projektmanagement das Ende der Transition zu sein scheint.
Es gibt eine Menge Tools und Techniken, mit denen sich beide Seiten abholen lassen. Agiles Projektmanagement ist eine tolle zwischenlösung. Darauf aufbauend kann ein gemeinsamer Weg in Richtung Agile Produktentwicklung gestartet werden.
Die Welt ist nicht nur schwarz und weiß.