Funktionierende Projekte an Stelle von perfekten Lehrbuchmethoden

Häufig höre ich: "Was wir machen, ist kein SCRUM." Okay, verstanden. Die Gegenfrage "Funktioniert's denn?" bleibt meist unbeantwortet.

 

Dabei lohnt sich der Blick darauf, welche Methodenbausteine im Kontext Eures Geschäftsmodells, Eurer Firmen und der zugehörigen Unternehmenskultur passen. 

Wenn Projekte nicht funktionieren, gibt es zwei häufig genutzte Erklärungsmodelle:

  1. "Wir arbeiten nach Wasserfall. Das kann nicht funktionieren."
  2. "Wir machen etwas, dass wir Kanban / SCRUM / XP / ... nennen. Wir machen das aber falsch. Das kann in dem Buch XYZ lesen."

Die Lösung, wie das Team ein perfektes Projekt zu erreichen wünscht, ist nun einfach:

  1. Von der Wasserfall-Methode in eine agile Methode wechseln (hier wird SCRUM von vielen Teams favorisiert).
  2. Rollen und Prozesse aus dem Buch XYZ einfordern und jammern.

 

Das Jammern über die schlechte Ausführung der Projektmethode belässt die Beteiligten in ihrer jeweiligen Komfortzone.

Grafik: Komfort-, Lern- und Panikzone
Das Ändern der Projektmethode bringt uns aus der Komfortzone

Während klassisch-hierarchische Projektmethoden stark auf Standardisierung und Generalisierung setzen, suchen agile Methoden durch eine inkrementelle und iterative Veränderung nach der optimalen Methodik in dem jeweiligen Umfeld. Das Mittel hierzu sind regelmäßigen Retrospektiven. Alle wollen liefern! Und wissen um die Veränderung, die sie hierfür brauchen. Im zweiten Prinzip des agilen Manifests heißt es dazu:

 

Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

 

Jedes Projekt ist anders -- warum sollte jedes Projekt nach der gleichen Methode funktionieren? Der Versuch, agile Prozesse zu standardisieren und in vorgeformte Bahnen zu pressen, wird scheitern. Es ist nicht wichtig, ob eine Methode exakt nach Lehrbuch durchgeführt wird. Es zählt, was funktioniert! David Anderson beschreibt das in dem Buch "Kanban: Successful Evolutionary Change for Your Technology Business" (Amazon-Link) so:

 

“You have the permission to try Kanban. You have the permission to modify your process. You have permission to be different. Your situation is unique and you deserve to develop a unique process definition tailored and optimized to your domain, your value stream, the risks that you manage, the skills of your team, and the demands of your customers.” 

 

Deswegen: wenn was nicht funktioniert, fragt Euch, warum das so ist. Und ändert das.

 

Nutzt Lehrbücher über Projektmethoden als Inspiriationsquelle, wie man die Projektprozesse anders gestalten könnte. Nicht für mehr, nicht für weniger.


Kommentar schreiben

Kommentare: 0