TopMenue

Agile Grundsätze

Scrum ist der Rahmen, Scrumcess der Prozess

Unser Dilemma

Es liegt in unserem Dasein begründet, die Zukunft nicht gesichert vorhersagen zu können. Aus der Kenntnis dieser Tatsache heraus ist es nachvollziehbar, dass die konkreten Ergebnisse komplexer, langfristiger und detaillierter Planungen im Laufe ihrer Realisierung mehr oder weniger weitgreifend von den ursprünglichen Zielvorstellungen (Umfang, Aufwand, Budget) abweichen können. Wird dies nicht berücksichtigt, erhält der Kunde am Ende des Projektes bestenfalls — wenn überhaupt — das Produkt, das er bestellt hat, aber nicht das Produkt, das er inzwischen benötigt.

Das ist ein äußerst bedauerlicher Umstand, der sich häufig daraus ergibt, dass sich während der Projektlaufzeit beim Kunden eine Vielzahl neuer Erkenntnisse, Erfahrungen und Bedürfnisse ergeben haben, die am Ende des Projektes nach einem potentiell anderen Ergebnis verlangen, als jenes, das dann an den Kunden ausgeliefert wird.

Unabhängig davon gibt darüber hinaus auch noch die Möglichkeit, dass sich auch das Projektteam während der Realisierung vor technische, fachliche und ggf. auch personelle Herausforderungen gestellt sieht, die während der Projektplanung noch nicht bekannt waren oder übersehen, vernachlässigt, ignoriert oder falsch eingeschätzt wurden.

Klassischer Lösungsversuch

Man kann nun einwenden, der Kunde müsse seine Wünsche und Ideen eben nicht am aktuellen Bedarf orientieren, sondern bei der Ausarbeitung der Anforderungen in die Zukunft seines Unternehmens blicken, um den gewünschten Lieferumfang zukunftsorientiert zu bestimmen und zu entscheiden. Um die „unerwarteten Herausforderungen“ zu kompensieren, müssten die Planer eben entsprechende Puffer vorsehen und die Projektbeteiligten sich ranhalten.

Agiler Lösungsversuch

Eine viel zielorientiertere Lösung ist jedoch, von vorn herein die aufgezeigte Entwicklung nicht als Risiko, sondern als Chance zu begreifen und zu ermöglichen, sowohl das Projektziel, als auch die jeweiligen Rahmenbedingungen zeitnah während des Projektverlaufs flexibel neu justieren und ausrichten zu können. Dabei muss dem Kunden plausibel gemacht werden, dass er hierzu selbst einen Beitrag leisten kann und auch leisten sollte, indem er sich, seine Wünsche, seine Ideen, sowie seine Erfahrungen und Erkenntnisse als aktiv Beteiligter in Form von Reviews und Feedback in das Projekt einbringt. Dieses Mehr an Sicherheit, Qualität und Flexibilität für Projekt und Projektziel ist jedoch nur dann erreichbar, wenn die Neujustierung in einer verantwortungsvollen, sparsamen und gezielten Weise, sowie im Konsens zwischen allen Beteiligten durchgeführt wird.

Ist der Kunde derart tief in das Projekt mit eingebunden, können eventuelle Konsequenzen, die sich aus einer Umsteuerung ergeben könnten, auf ein Mindestmaß reduziert werden, da der Kunde, bevor die Konsequenzen greifen, immer noch entscheiden kann, ob für ihn das Verhältnis von Kosten und Nutzen oder Chancen und Risiken annehmbar oder nicht annehmbar ist, bzw., ob er die Veränderung — und damit die Entscheidung — vielleicht lieber auf einem späteren Zeitpunkt verschieben möchte.

Agile Vorteile

Dieses Konzept ist einer der wesentlichen Vorteile agiler Vorgehensweisen und damit auch einer der vielen Vorteile von Scrumcess. Es birgt für den Kunden den großen Nutzen, am Ende des Projektes ein Produkt ausgeliefert zu bekommen, das dem jeweils aktuellsten Stand seiner Bedürfnisse entspricht, weil seine aktuell in Projekt und Geschäft gemachten Erkenntnisse und Erfahrungen direkt in die Realisation der aus seiner Sicht wertvollsten Anforderungen einfließen, um ihm den größtmöglichen wirtschaftlichen Vorteil bei höchster Qualität und Termintreue zu verschaffen.

Diese Vorteile stellen für den Kunden einen Kostenfaktor in den Raum: Zeit.

Um die o.g. Vorteile nutzen zu können, ist es für den Kunden allerdings nicht ausreichend, das Projekt zu initiieren, sich nicht weiter oder nur am Rande damit zu beschäftigen und sich dem Projekt erst wieder zum Ende der prognostizierten Projektlaufzeit zuzuwenden, um das fertig erstellte Zielprodukt entgegenzunehmen.

Das Maß aller Dinge

Der Kunde, seine Wünsche und seine Bedürfnisse sind in einem agilen Projekt zu jeder Zeit das Maß aller Dinge und es ist für solch ein Projekt selbstverständlich und essentiell, dass er anhand eines permanent aus dem Projekt zu ihm fließenden Informationsstroms die Chance bekommt — und sie dann auch nutzt — seine Wünsche und Bedürfnisse weiterzuentwickeln und diese Wünsche und Bedürfnisse auch wieder ins Projekt zurückfließen zu lassen. Diese Zeit ist für den Kunden eine gute Investition, denn er investiert seine Zeit in die Qualität des Produktes, weil ein Projektergebnis, selbst wenn es technisch und fachlich betrachtet den höchsten Qualitätsansprüchen genügt, aber die von ihm wirklich benötigten Funktionalitäten nicht abbildet, zumindest in Bezug auf seinen Bedarf von schlechter Qualität ist.

„agile Manifasto“

Scrum und somit auch Scrumcess folgen dem Geist des agilen Manifests mit seinen vier Leitsätzen und zwölf Prinzipien, deren Erläuterung umd Kommentierung Sie hier unter Das agile Manifest und die zwölf Prinzipien finden können. Die originalen Texte des „agile Manifasto“ sind hier in englisch und vielen weiteren Sprachen zu finden; u.A. hier in deutsch.

Die 4 Leitsätze des agilen Manifests
  1. Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
  2. Funktionierende Software ist wichtiger als umfassende Dokumentation
  3. Zusammenarbeit mit dem Auftraggeber ist wichtiger als Vertragsverhandlung
  4. Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans
Die 12 Prinzipien des agilen Manifests
  1. Unsere höchste Priorität ist es, den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufrieden zu stellen
  2. Heiße Anforderungsänderungen selbst spät in der Entwicklung willkommen. Agile Prozesse nutzen Veränderungen zum Wettbewerbsvorteil des Kunden
  3. Liefere funktionierende Software regelmäßig innerhalb weniger Wochen oder Monate und bevorzuge dabei die kürzere Zeitspanne
  4. Fachexperten und Entwickler müssen während des Projektes täglich zusammenarbeiten
  5. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen und vertraue darauf, dass sie die Aufgabe erledigen
  6. Die effizienteste und effektivste Methode, Informationen an und innerhalb eines Entwicklungsteam zu übermitteln, ist im Gespräch von Angesicht zu Angesicht
  7. Funktionierende Software ist das wichtigste Fortschrittsmaß
  8. Agile Prozesse fördern nachhaltige Entwicklung. Die Auftraggeber, Entwickler und Benutzer sollten ein gleichmäßiges Tempo auf unbegrenzte Zeit halten können
  9. Ständiges Augenmerk auf technische Exzellenz und gutes Design fördert Agilität
  10. Einfachheit — die Kunst, die Menge nicht getaner Arbeit zu maximieren — ist essenziell
  11. Die besten Architekturen, Anforderungen und Entwürfe entstehen durch selbstorganisierte Teams
  12. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann und passt sein Verhalten entsprechend an
Kosten der Flexibilität

Die Kosten für den Kunden, ein bestens auf ihn und seine jeweils aktuellen Wünsche und Bedürfnisse abgestimmtes Produkt zu erhalten, sind für ihn daher, dass er sich in den Produktionsprozess aktiv mit einbringt, sich und seine Sicht auf das zu erstellende Produkt weiterentwickelt und diese Weiterentwicklung auch an das Projekt kommuniziert und dort mit dem Scrumteam in technischer und fachlicher Hinsicht diskutiert.

Wie, Diskussionen?

Der Kunde muss diskutieren? Ja, ist er dann doch nicht Herr des Projektes? Stand da nicht eben noch, er sei „das Maß aller Dinge“! Warum muss er dann diskutieren?

Nun, müssen muss er natürlich nicht.
Wenn es ihn jedoch interessiert (und das sollte es), was für Auswirkungen seine Entscheidungen auf Projekt und Produkt haben werden, sollte er mit dem Projektteam darüber diskutieren, was seine Ideen und Entscheidungen zum aktuellen Zeitpunkt für Projekt und Produkt bedeuten! Er ist also weiterhin „das Maß aller Dinge“. Verzichtet er jedoch auf die Meinung der Experten, vergibt in den allermeisten Fällen die Chance, seine Entscheidungen auf eine möglichst breite Basis zu stellen.

Veränderung ist alltäglich

Es ist sicher nachvollziehbar, dass es Auswirkungen auf Projekt und Produkt hat, wenn der Kunde sich nicht verantwortungsvoll gegenüber dem Projekt verhält und z.B. am Vortag der Endabgabe entscheidet, dass er — sehr überspitzt gesagt — statt eines CRM-Systems doch lieber ein ERP-System hätte … mal davon abgesehen, dass in so einem Fall bereits das ganze Projekt über etwas ganz dramatisch schief gelaufen sein muss, bedeutet diese Entscheidung, dass wahrscheinlich der Großteil des Inhaltes des Projektplanes, bzw. des Product-Backlogs schlagartig veraltet und obsolet wäre und gemäß der geänderten Ausrichtung neu aufgebaut werden müsste. Einen klassischen Projektleiter, der das Projekt mit einem klassischen Softwareentwicklungsprozess durchgeführt hat, würde diese Aussicht wahrscheinlich krebsrot anlaufen und ihn hektisch in seinen Taschen nach Herz- oder Beruhigungstabletten forschen lassen, wobei ein agiles Team im Gegensatz dazu im großen und ganzen völlig gelassen bleiben dürfte.

Veränderung ist ihr tägliches Brot.

Konsequentes Handeln

Die genannte (fiktive und sehr überspitzt dargestellte) Entscheidung stellt in jedem Fall eine ganz erhebliche Veränderung des Projektzieles dar und das Projektteam sollte dem Kunden die aus seiner Entscheidung resultierenden Konsequenzen bzgl. der bereits geleisteten Arbeit und dem nunmehr zu erwartenden Projektergebnis ganz klar vor Augen führen.

Ja aber wenn der Kunde trotzdem auf seiner Entscheidung besteht?

[ERP-System]

Was würde ihm das agile Team unter diesen Umständen am Auslieferungstag ausliefern?

Ein ERP-„System“.
Wenn auch unter diesen Umständen ein wahrscheinlich nur sehr, sehr kleines.

[zurück zum Seitenanfang]


, ,

No comments yet.

Schreibe einen Kommentar

V1503130747DE