Agile Projekte aus Kundensicht Teil 1

Einstieg

Der Beitrag richtet sich insbesondere an Entscheider in mittelständischen Unternehmen bei denen die Umsetzung eines Online-Projektes ansteht, Menschen die sich allgemein für agile Methoden interessieren und diejenigen die sich damit befassen wollen.

Agiles Projektmanagement kommt insbesondere in der Softwareentwicklung oder generell bei der Entwicklung digitaler Produkte zum Einsatz.
Häufiger werde ich mich auf SCRUM beziehen. SCRUM ist eine Projektmanagement-Methode und kann als Quasi-Standard des agilen Projektmanagement für die Softwareentwicklung bezeichnet werden. 86% setzen dabei auf Scrum was eine Studie der Hochschule in Koblenz belegt(Siehe http://www.status-quo-agile.de).

Deshhalb hier noch kurz ein Link zu Wikipedia wo Sie sich über SCRUM informieren können: SCRUM Einleitung

Eines Vorweg – werden Sie als Auftraggeber und somit als Kunde einer Agentur oder IT-Dienstleisters mit dem Vorschlag konfrontiert, ein Projekt mit Ihrem Dienstleister “agil” umzusetzen, bitte geben Sie dem Projekt eine Chance – Sie werden es nicht bereuen!

Agil ist in aller Munde…

Jeder IT- Projektmanager oder Projektmanager im Agenturgeschäft der einigermaßen was auf sich hält, wird etwas zu agilem Projektmanagement mit oder ohne SCRUM sagen können. Die meisten zeigen sich mehr oder weniger überzeugt das man hier eine Methode an der Hand hat, die den Anforderungen an die Projektarbeit im digitalen Umfeld am ehesten gerecht wird. Agil ist in aller Munde und das ist gut so, denn eines ist sicher – der Kunde und die Qualität des Ergebnisses standen nie “stärker” im Fokus der Betrachtung.

Agile Prinzipien

Die agilen Prinzipien sind quasi die Werte die die Beteiligten teilen und nach denen im Projekt gehandelt wird. Aus meiner Sicht sind viele Aspekte fernab von Softwareentwicklungsprojekten absolut erstrebenswert und erzeugen echten “Mehrwert”. Ganz nebenbei: Die Prinzipien bzw. Werte finden Ihren Ursprung in den “Lean Management” und “Lean Development”- Gedanken.

Die 12 Prinzipien von agiler Softwareentwicklung können Sie hier noch einmal nachlesen: Agiles Manifesto

An der Stelle konzentriere ich mich auf die übergeordneten 4 Werte denen alle 12 Prinzipien untergeordnet sind:

– Individuen und Interaktionen mehr als Prozesse und Werkzeuge
– Funktionierende Software(Produkte) mehr als umfassende Dokumentation
– Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
– Reagieren auf Veränderung mehr als das Befolgen eines Plans

Hier stehen sich die Punkte nicht konträr gegenüber, sondern das fett gedruckte ist schlicht höher zu gewichten als der zweite Teil des genannten Werteprinzip.

Von welchen Projekten ist die Rede?

Richtig ist, das man ein Hausbau als Projekt nur bedingt mit einem Softwareentwicklungsprojekt vergleichen kann und agile Methoden lassen sich nicht 1:1 übertragen. So werden Sie sicher bisher beim Hausbau selten erlebt haben, daß kurz vor Fertigstellung des Daches der Auftraggeber noch einmal eine Etage mehr wünscht. Also reden wir wie zu Beginn bereits angedeutet, ausschließlich von IT-Projekten? Nein, mir geht es in diesem Beitrag vorallem darum wo wir auch ausserhalb von IT-Projekten von den agilen Ansätzen lernen können.

Ein Rückblick…

Je nachdem aus welcher Perspektive/Rolle (Auf Auftraggeberseite bsp. als Geschäftsführer oder Projektleiter) man im Prozess eines Projektes (digitales Umfeld) beteiligt war, werden die folgenden Punkte einem sehr bekannt vorkommen.
Eines ist jedoch sicher, unten stehenden Punkte (die ich leicht überspitzt dargestellt habe) werden Sie in agilen Projekten definitiv so NICHT mehr erleben:

• Ellenlange Projektpläne wurden an die Wand geworfen, insbesondere “enorme Ressourcen” darauf verschwendet, die Eintrittswahrscheinlichkeit der Risiken in der Zukunft des Projekts vorherzusehen. Die Ernüchterung folgte in vielen Fällen auf dem Fuße.
• Nicht zu vergessen die teilweise aufgeblähten Konzepte biblischen Ausmasses die dem Kunden verdeutlichen sollten, das man sich sehr intensiv mit dem Auftrag beschäftigt hat. Wer sollte das eigentlich lesen?
  • Die Konzept stammen meist aus der Feder eines sehr klugen Kopfes (nicht ironisch gemeint).
• War der Auftrag erst einmal gewonnen und das Konzept geschrieben, ging man davon aus, das das definierte Produkte sich eigentlich nicht mehr ändern darf, schließlich hat man ja alles dafür getan Sie als Kunde dahingehend zu beraten, wie das optimale Ergebnis auszusehen hat. Änderungswünsche – ja gerne – aber doch nicht jetzt!
• Kommunikation mit Ihnen als Kunde verlief meistens in etwas so; intensive Gespräche in der Auftragsanbahnungsphase, während nachdem Projektstart sich die Kommunikation häufig auf die “berüchtigten” Status-Meetings konzentrierte. Folienschlachten waren und sind auch heute keine Seltenheit – wobei Sie als Kunde von dem Zwischenergebnis keinen Einglick hatten – Transparenz bezog sich dann meistens auf den Prozess. Meilenstein 1 – wurde erreicht usw…Sie kennen das.

Mehr erfahren Sie in Teil 2…