Herausforderungen an den agilen Ansatz bei Regierungsprojekten

Eine frühere Agile Diskussion hier hatte gute Antworten spezifizieren , was ist entscheidend für den Erfolg der Umsetzung der Agile - Methodik in der Softwareentwicklung. Die meisten Punkte waren die typischen Organisations- und Managementherausforderungen, aber ein Punkt beunruhigt mich und es ist, dass der Kunde während des gesamten Prozesses einbezogen werden muss.

Der Kunde ist das Einzige, was Sie nicht realistisch kontrollieren können. Vielleicht führt Ihr Geschäftsmodell Sie zu staatlichen Auftragsarbeiten, zum Beispiel wenn das Unternehmen aufgrund eines strengen Vertrags verpflichtet ist:

• Stellen Sie die gewünschten X-Funktionen bereit

• Feature Requests werden über eine Mauer geworfen, stört uns nicht, wir wollen es nicht hören.

• Der Kunde denkt nicht an die Priorität der Funktionen, sie sind alle wichtig, sonst hätten wir nicht darum gebeten.

• Das Projekt wird unabhängig von Überschreitungen oder Fristen nicht mehr und nicht weniger als Y kosten.

• Absolute, strenge, endgültige und nicht verhandelbare Frist für die vollständige Lieferung aller Arbeiten.

Wir haben noch nie mit einem solchen Kunden zusammengearbeitet, aber das Geld für das Projekt ist einfach zu gut, um darauf verzichten zu können. Wir brauchen diese Arbeit.

Ich bin hierher gekommen und habe hart daran gearbeitet , die Prozesse innerhalb von zu ändern, um zu agiler Entwicklung überzugehen, und hier weiß ich nicht, wie ich vereinbaren kann, wo dieses Projekt in unseren neuen Prozess passt. Ich hatte noch nie den Luxus eines aufgeschlossenen Hands-off-Managements, das mir anvertraute, das Entwicklungsteam und die Prozesse auf diesem Weg zu leiten, und jetzt, da wir hier sind, kann ich mir nicht ehrlich sagen, dass dieses Projekt wirklich in einem Gange sein wird Agiler Weg. Ich habe das Gefühl, dass das Management mir anvertraut hat, diesen Weg zu gehen, und dass ich sie im Stich gelassen habe, weil diese Situation, in der wir uns gerade befinden, so eindeutig nach Wasserfall verlangt. Ich habe Angst, dass ich ihr Vertrauen verlieren könnte, wenn ich jetzt einen Rückzieher mache.

Andere Antworten wie die hier sagen, dass Agilität bei dieser Art von Kunden unmöglich ist, stimmen Sie zu? Hat jemand von euch eine ähnliche Situation erlebt und es zum Laufen gebracht? Welche Strategien haben Sie umgesetzt, um Agile erfolgreich umzusetzen?

Ich denke, das Erste, was zu erkennen ist, ist, dass es einen Unterschied zwischen Agilität und Agilität gibt. Die langsame Einführung agiler Techniken und Merkmale - funktionsübergreifende Teams, adaptive Planung, evolutionäre / inkrementelle Bereitstellung, zeitgesteuerte Iterationen und sogar die Einführung von Konzepten aus Lean - unterscheidet sich erheblich von der Einführung von Extreme Programming, Scrum oder Crystal.

Sie erwähnen ausdrücklich die Kundenbeteiligung. Ja, viele der Agile-Methoden erfordern die Einbeziehung der Kunden, aber es ist nicht erforderlich, dass diese agil sind. In jedem Regierungs- / Verteidigungsprogramm hatte ich immer einen Programm- oder Projektmanager, der der Ansprechpartner für den Kunden war. Diese Person wird zur "Stimme des Kunden". Es kann verlangsamt werden, wenn Telefonkonferenzen oder E-Mails stattfinden oder Anrufe und Abklärungen erfolgen. Sie können jedoch auch eine einzelne Person (oder eine Gruppe, wenn Sie auch stellvertretende PMs haben) als Kundenvertreter Ihres Teams einsetzen. Zugegeben, es ist nicht ganz dasselbe. Aber ist es nicht agil, flexibel zu sein und auf Veränderungen zu reagieren?

Sie erwähnen auch einige Schlüsselkonzepte: vordefinierte Anforderungen, Feature-Anforderungen, die "über die Wand geworfen" werden, mangelnde Priorisierung, weil "sie alle wichtig sind", und Projekte mit festen Kosten und / oder festem Zeitplan. Jedes davon kann auf unterschiedliche Weise angesprochen werden.

Wenn Sie denken, dass Sie alle Ihre Anforderungen im Voraus haben, haben Sie wahrscheinlich keine. Anforderungen ändern sich. Nur weil Sie eine "abgeschlossene und abgemeldete" Spezifikation haben, heißt das nicht, dass sie in Stein gemeißelt ist. Erfassen Sie unter Berücksichtigung der von Ihnen vorgelegten Anforderungsdokumente, wie Sie sich wohl fühlen und / oder wie im Vertrag festgelegt, und liefern Sie die Anforderungen, das Design und die Architektur. Überprüfen Sie außerdem, ob es sich bei diesen Dokumenten um lebende Dokumente handelt (ein Designdokument, das ich heute bei der Arbeit gesehen habe, ist mit Revision G gekennzeichnet, dh es befindet sich in der achten Aktualisierung). Fragen Sie, wie viel Sie als TBD in einer bestimmten Iteration belassen können und wie viel Sie jetzt festigen müssen - es könnte ein Geben und Nehmen geben.

Seien Sie agil mit Ihrer Dokumentation. Vervielfältigen Sie nicht die Bemühungen zwischen "was Ihr Team will" und "was der Kunde will". Wenn Ihr Kunde beispielsweise eine herkömmliche Spezifikation der Softwareanforderungen wünscht und Ihr Team User Storys verwenden möchte, sollten Sie versuchen, sich an einen herkömmlichen SRS anzupassen und statt User Storys Aktionselemente und eine fortlaufende Liste von Aktionselementen zu verwenden, damit Sie keine Zeit verlieren Formulierung sowohl "das System soll ..." und "muss in der Lage sein, weil". Dies erfordert jedoch Disziplin seitens des Teams, um sich auf Unterschiede zwischen den Projekten einzustellen. Erfassen Sie Probleme in Reflexionen.

Sobald Sie die Entwicklung erreicht haben, können Sie 5 oder 6 Iterationen ausführen und dann Ihren Kunden zu Ihrer Einrichtung einladen, um eine Teilmenge Ihrer Implementierung zu sehen. Spülen und wiederholen Sie diesen Vorgang. Es ist nicht die ständige Einbeziehung, die von einigen Methoden verlangt wird, aber Sie haben den Vorteil einer hohen Sichtbarkeit. Wenn Ihr Kunde Nein sagt, haben Sie es zumindest versucht. Wenn sie ja sagen, können Sie sie über Agilität aufklären. Bei einem meiner Projekte besuchte der Kunde die Website alle paar Monate (in der Regel 3-5 Monate). Sie sahen zu, wie wir QS-Tests durchliefen, sie diskutierten Bedenken mit Ingenieuren und Geschäfte mit dem Programm- / Projektbüro. Es war eine Gelegenheit für alle, auf die gleiche Seite zu kommen.

Test und Wartung erfolgen genauso wie bei anderen agilen Projekten. Erstellen Sie Ihre Testverfahren und dokumentieren Sie Fehler auf geeignete Weise, verfolgen Sie die Messdaten gemäß den vertraglichen Verpflichtungen und dokumentieren Sie die Testergebnisse. Wenn Sie TDD folgen möchten, wählen Sie es. Kontinuierliche Integration ist eine weitere gute Idee. Während Projektstatusmeetings kann Ihr Projektmanager anhand dieser Informationen sagen, dass wir N-Anforderungen implementiert haben, M-Tests durchgeführt und X-Tests bestanden haben, und den Personen, die das Geld haben, Informationen zum Projektstatus und -status übermitteln.

Apropos Geld, wir haben das Problem der festen Kosten und / oder des festen Zeitplans.

Der Umgang mit einem festen Zeitplan ist ziemlich einfach. Anhand Ihrer Anforderungen wissen Sie, wie viele Iterationen Sie ausführen können. Ihre Arbeitslast für jede Iteration ist in Bezug auf die zu implementierenden, zu testenden und zu integrierenden Funktionen ziemlich genau festgelegt. Es mag schwierig sein, aber es ist nicht unmöglich, Features aufzubrechen und sie im Voraus Iterationen zuzuweisen. Dies geht auf meinen Punkt über das Einladen des Kunden zurück - wenn Sie ein Jahr haben und 2-wöchige Iterationen verwenden, laden Sie den Kunden möglicherweise vierteljährlich ein (und laden Sie ihn vierteljährlich ein) und zeigen Sie ihm die Ergebnisse der vorherigen Arbeit. Lassen Sie sie Ihre Priorisierung der Anforderungen, Ihre Zukunftspläne und Ihre Terminplanung sehen.

Ähnlich verhält es sich mit einem festen Budget. Sie wissen, wie viel Zeit Sie haben, wie viele Ressourcen Sie für das Projekt haben, wie viel sie kosten und wie viele Stunden jeder pro Iteration arbeiten kann. Es ist nur eine Frage der Sicherheit, dass alle dies sorgfältig nachverfolgen. Wenn Ihre Firma die Kosten für Überstunden auffressen kann, entscheiden Sie sich dafür. Stellen Sie andernfalls sicher, dass alle Mitarbeiter über die erforderliche Zeit arbeiten, und setzen Sie gute Zeitmanagementfähigkeiten und Zeitboxen ein, um die Produktivität aller Mitarbeiter zu gewährleisten. Produktivere Arbeitszeiten sind das, was Sie brauchen, um die Kosten niedrig zu halten - liefern Sie mehr wertschöpfende Dokumente und Software, ohne die Kosten für Meetings und Overhead.

Letztendlich geht es nicht unbedingt darum, agil zu sein, sondern die Dinge anzuwenden, die Agile gut und agil machen. Sie können auf veränderte Anforderungen reagieren, häufige Software liefern, auch wenn der Kunde dies nicht wünscht, nur wertschöpfende Unterlagen erstellen (zusammen mit dem, zu dessen Erstellung Sie vertraglich verpflichtet sind) und so weiter.

Ja, Agile ist für ein solches Projekt nicht geeignet, da es den Anschein hat, dass die Anforderungen bereits in Stein gemeißelt und festgelegt wurden, wahrscheinlich das Ergebnis jahrelanger Analyse durch teure Berater, Ausschusssitzungen und politischer Kompromisse. Wasserfall funktioniert gut, wenn der Kunde so diszipliniert ist, dass er Ihnen genau schriftlich mitteilen kann, was er will. Sie könnten falsch sein, aber zumindest haben Sie es schriftlich, und Sie werden bezahlt, wenn Sie das liefern. (Dies sagt natürlich nichts über die Kundenzufriedenheit aus. Möglicherweise liefern Sie etwas, das sie nicht wirklich benötigen.)

Agile wurde entwickelt, um ein Problem zu lösen, das Sie nicht haben: Risiko aufgrund ungewisser Anforderungen.

Es ist richtig, dass der Kunde möglicherweise Änderungsanforderungen anfordert, Sie können jedoch einen von zwei Pfaden wählen:

1. Das Geld war so gut, dass Sie wissen, dass Sie X Menge neuer Funktionen in verschiedenen Phasen des Projekts aufnehmen und trotzdem herauskommen können, ohne Ihr Hemd zu verlieren, oder
2. Sie machen dem Kunden zu Beginn klar, dass aufgrund der Verhandlung eines engen Preises bei jeder neuen Funktionsanforderung ein Änderungsauftrag mit einem Preis generiert wird, der von ihm genehmigt werden muss, mit einer zugehörigen Bestellung (oder Änderung von die ursprüngliche Bestellung), damit Sie dies umsetzen können. In der Änderungsreihenfolge werden alle Auswirkungen auf die Funktionalität oder den Zeitplan aufgeführt. Wenn sie sagen, dass der Termin nicht verschoben werden kann, werden Änderungsaufträge im Verlauf des Projekts exponentiell teurer, weil es später teurer ist, Dinge zu ändern.

Die Beziehung fühlt sich unter Situation 1 viel freundlicher an, aber es ist ziemlich selten, dass es Einkaufsabteilungen gibt, die Sie nicht auf den Preis drängen, so dass Sie die meiste Zeit in Situation 2 sind. Das heißt, die Beziehung ist konfrontativ, aber wenn Sie im Geschäft überleben wollen, müssen Sie die Beziehung gut managen und dabei Ihre Position halten. Dies ist ein großer Teil der Arbeit des Projektmanagers.

Es hört sich so an, als wären Sie in Situation 1, was gut ist. Ich stelle mir vor, dass Regierungsverträge der einzige Ort sind, an dem ihnen Geld egal ist, weil sie schließlich nicht ihr Geld ausgeben, sondern Ihr Geld ausgeben.

... staatliche Auftragsarbeiten, bei denen das Unternehmen aufgrund eines strengen Vertrags verpflichtet ist:

Zuerst. Es ist streng. Aber es ist nicht unflexibel. Es erfordert einfach Liebe zum Detail und eine lange, lange Reihe von Änderungsaufträgen.

Regierungsbehörden sind tatsächlich auf langsame, ineffiziente Weise agil. Sie müssen ständig formelle, detaillierte Änderungsaufträge schreiben (und aushandeln).

Stellen Sie die gewünschten X-Funktionen bereit

Bis zur Änderung durch einen Änderungsauftrag.

Feature Requests werden über eine Mauer geworfen, stört uns nicht, wir wollen es nicht hören.

Der Kommunikationskanal ist die Änderungsreihenfolge. Auswirkungen auf Budget und Zeitplan.

Der Kunde denkt nicht an die Priorität der Funktionen, sie sind alle wichtig, sonst hätten wir nicht darum gebeten.

Das ist schwer zu umgehen. Selbst Nichtregierungsunternehmen, die viel Geld für "Anforderungsanalysen" ausgeben, möchten nicht wissen, dass ein großer, flacher, dampfender Haufen von Anforderungen, der nicht durch Prioritäts- und Kompromissinformationen belastet ist, unvollständig ist. Sie haben gutes Geld bezahlt, um alle Anforderungen zu erfüllen. Wie können Sie weitere Informationen wünschen?

Das ist ein schwieriges Problem.

Das Projekt wird unabhängig von Überschreitungen oder Fristen nicht mehr und nicht weniger als Y kosten.

Mit Ausnahme der Änderungsaufträge. Welche ändern Y und die Deadline.

Absolute, strenge, endgültige und nicht verhandelbare Frist für die vollständige Lieferung aller Arbeiten.

"Nicht verhandelbar" ist im Allgemeinen nicht wahr. Es ist verhandelbar. Es ist nur schmerzhaft zu verhandeln.

Der wichtige Teil der Verhandlungen mit Regierungsbehörden ist die Tatsache, dass Sie Beweise auf "Anwaltsebene" für Ihre Kosten- und Zeitplanänderungen benötigen. Ein paar sorgfältige technische Präsentationen mit einer schönen Powerpoint-Folie sind kein "Beweis". Sie benötigen eine Menge Dokumentation, um Ihren Fall zu machen.

Die Regierungsbeamten müssen unanfechtbare Beweise dafür vorlegen, dass sie alles in ihrer Macht Stehende getan haben, um dies so billig und effektiv wie möglich zu gestalten. Sie wissen, dass jede Entscheidung in der öffentlichen Presse wiederholt und im Nachhinein überprüft wird.

Die Komplexität der Softwareentwicklung und der nachträgliche Aspekt der Regierungsarbeit am "Montagmorgen-Quarterback" führen dazu, dass sie den Vertrag nur ungern ohne überwältigende Beweise ändern.

Es macht einen richtig agilen Ansatz schwierig.

"Individuen und Interaktionen über Prozesse und Werkzeuge" ist hart. Sie arbeiten nicht mit einer Einzelperson zusammen, sondern mit einem Vertreter der Regierung, dessen Aufgabe durch den Prozess eingeschränkt wird.

In einem Projekt wie diesem haben Sie Umfang, Ressourcen und Zeit gebunden. Das einzige, was Sie noch verwalten müssen, ist die Qualität. So...

Sie werden nicht den größten Nutzen aus einem agilen Ansatz ziehen, den Sie sonst hätten, aber Sie können Ihr Bestes tun, um Qualitätsrisiken zu minimieren und den Kunden früher als später über Probleme zu informieren.

Seien Sie also so beweglich wie möglich:

1. Gehen Sie die Anforderungen durch und priorisieren Sie sie am besten hinsichtlich des technischen Risikos. Legen Sie die priorisierten Anforderungen als Ihren Rückstand fest.
2. Bearbeiten Sie den Rückstand in Sprints - entwerfen, testen und codieren Sie die Funktionen für den Sprint. Da die Kundeninteraktion fehlt, muss das Anforderungsdokument den Kunden für diese Aktivität darstellen.
3. Laden Sie den Kunden zu jeder Sprint-Überprüfung ein - er kann Nein sagen, aber er kann Ja sagen. Und Sie werden eher früher als später eine Rückmeldung erhalten.

Wenn Sie anfangen, gegen die Frist zu rennen, können Sie zeigen, was getan wurde, und vielleicht wird der Kunde zu diesem Zeitpunkt, da er weiß, dass er nicht alles bekommen wird, genug Prioritäten setzen, um Ihnen mitzuteilen, was er will. Sie sollten auch die riskantesten Dinge erledigen lassen, was bedeutet, dass die Aufgaben zur Deadline am einfachsten zu erledigen sind, wenn Sie mehr arbeiten.

Ich denke, diese Art von Kunden ist nicht die Norm. Sie haben es mit einer Gruppe zu tun, die bereits ähnliche Projekte angefordert hat, damit sie genau wissen, was sie wollen. Sie erwähnen nie, dass sich ihre Spezifikationen ändern werden.

Stellen Sie die gewünschten X-Funktionen bereit

Ich habe Glück, wenn ich die X-Funktion vage wie vorgeschlagen zur Verfügung stelle und bereit bin, sie kurzfristig zu ändern.

Feature Requests werden über eine Mauer geworfen, stört uns nicht, wir wollen es nicht hören.

Wenn Sie wissen, was sie wollen, bauen Sie es.

Der Kunde denkt nicht an die Priorität der Funktionen, sie sind alle wichtig, sonst hätten wir nicht darum gebeten.

Das kannst du nicht verlieren. Bauen Sie sie nach Belieben.

Das Projekt wird unabhängig von Überschreitungen oder Fristen nicht mehr und nicht weniger als Y kosten. Absolute, strenge, endgültige und nicht verhandelbare Frist für die vollständige Lieferung aller Arbeiten.

Das ist eine schwierige Frage, wenn Sie noch nie ein Projekt für die Regierung erstellt haben. Wenn Sie eine Vorgeschichte haben, können Sie möglicherweise feststellen, ob Sie liefern können. Dies bedeutet nicht, dass sie nicht gut bezahlen (sie sind dafür berüchtigt, 50 US-Dollar für einen Hammer von 10 US-Dollar zu zahlen) oder dass sie unangemessene Erwartungen haben. Mit diesen Spezifikationen sollte jemand in Ihrem Team als Kunde fungieren und die Arbeit im Vergleich zu den Spezifikationen genehmigen. Selbst wenn Sie einen Fehler gefunden und sie gebeten hätten, die Anforderungen zu ändern, würden sie dies wahrscheinlich nicht tun.

Leider haben Sie die typische Sichtweise der Kunden beschrieben, wie ein Softwareprojekt angegangen werden sollte. Dies bedeutet nicht, dass der Kunde unvernünftig ist; Immerhin - ist das nicht die Art und Weise, wie man den Bau von irgendetwas anderem ausführen würde (zum Beispiel eines Hauses?). Davon abgesehen biete ich nicht wirklich mehr als das, was wir alle bereits wissen. Was Sie fragen, ist ... ist die Anwendung von agilen Praktiken in dieser Situation möglich?

Ich habe den Vorteil, dass ich gerade ein Projekt abgeschlossen habe, das in vielerlei Hinsicht der von Ihnen beschriebenen Situation ähnlich ist, dh

1. Feste (in Stein gemeißelte) Frist.
2. Dokument mit funktionalen Anforderungen ("die Bibel"). Kein Wunder, dass es nicht ausreicht.
3. Traditionelle Rollen: Projektmanager, Business Analyst.
4. Schwach engagierte Geschäftsanwender (können Sie sagen "kein Produktsponsor"?).

... und natürlich versucht das vorausschauende Entwicklerteam, trotz des oben Gesagten agil zu arbeiten:

1. 2-wöchige Iterationen;
2. Stand-ups;
3. Rückblicke;
4. Paar-Programmierung;
5. TDD;
6. Kontinuierliche Integration.

Ist etwas davon für das Business von Bedeutung? Nein. Zwei Monate vor Ablauf der Frist werden die bis dahin sorgfältig beobachteten Iterationen und Planungstermine in einem Wahnsinn von Headless-Chicken-Itis aufgegeben.

Die Antworten, die andere oben gegeben haben, sind mehr oder weniger Kompromisse. Meiner Meinung nach wird agil (ob "agil" oder "agil") auf schädliche Weise "eingearbeitet", wenn wir Kompromisse eingehen. Meiner Meinung nach:

Es gibt keine Kompromisse, oder es gibt keine agilen.

Der Geist von Agilität besteht darin, auf die Jagd zu gehen, Verschwendung zu beseitigen und sich selbst gegenüber brutal ehrlich zu sein. Es ist eine mittlerweile gut dokumentierte und unbestreitbare Tatsache, dass die Softwareschätzung bei großen Projekten bestenfalls ein Glücksspiel ist. Ist es nicht unsere Pflicht als Softwareprofis, potenzielle Kunden darüber aufzuklären? Wenn Kunden nicht akzeptieren wollen, dass wir die Experten sind, ist es dann nicht unsere berufliche Pflicht, wegzugehen?

Als ich anfing zu arbeiten, wo ich jetzt bin, stellte ich mir die gleiche Frage, die Sie ziemlich oft stellten. Es gibt etwas zu sagen für Wasserfälle mit Regierungsaufträgen. Ironischerweise ist Agile jetzt ein Schlagwort für Regierungskunden geworden (die realistisch nach Art eines Wasserfalls arbeiten). Jetzt müssen wir uns noch mehr darum bemühen, einen agilen Prozess mit einem grundsätzlich unflexiblen Kunden zu implementieren.

Wir haben ein System, das als "Scrummerfall", "Agilefall" oder "A mess" beschrieben wurde, aber in vielerlei Hinsicht konnten wir langsam einen immer agileren Prozess einleiten, da sich dieses (gigantische) Projekt im Laufe der Jahre weiterentwickelt hat . Eine der Möglichkeiten, die wir haben, besteht darin, Kommunikationskanäle mit den BENUTZERN unseres Systems im Gegensatz zu unseren KUNDEN zurückzugewinnen. Unsere Kunden sind eine stickige Abteilung, die von ernannten Beamten geleitet wird, die unsere Software in ihrem Arbeitsleben niemals berühren und sie nicht verstehen wollen. Unsere Benutzer sind reguläres Regierungspersonal vor Ort, das versucht, eine wichtige Aufgabe zu erfüllen. Für uns war der Schlüssel zum Aufbau einer Kommunikations-Feedback-Schleife, die es uns ermöglichte, so agil wie wir zu sein, die Notwendigkeit für UAT (User Acceptance Testing).

Zu einem frühen Zeitpunkt in unserem Projekt wurde beschlossen, dass eine repräsentative Gruppe von IST-BENUTZERN aus verschiedenen Büros unseres großen Regierungskunden HIER vor Ort versammelt wird, und wir haben ein paar Wochen Zeit mit ihnen, während sie eine Reihe von durchlaufen Testskripte zum Testen unserer Software. Das Anforderungs-Team war diesmal eine sehr informelle Angelegenheit, um Feedback von den tatsächlichen Endbenutzern zu erhalten. In der Zwischenzeit arbeitete das UAT-Testteam innerhalb der Regierung mit ihrer Bürokratie daran, mehr und mehr Einfluss auf den formalen Anforderungsprozess zu nehmen, einschließlich Änderungsaufträgen. Das Endergebnis ist, dass BAs wie ich als eigenständige Product Owner in Scrum-Teams agieren und in der Lage sind, wertvolle Zeit mit echten Kunden zu verbringen, die es uns ermöglichen, sehr agil zu arbeiten.

Offensichtlich gibt es viele Probleme, und wir sind immer noch nicht wirklich agil, aber wir sind agil genug, um als Beispiel für ein großes agiles Projekt angeführt zu werden, das diese Methode tatsächlich im öffentlichen Auftragswesen einsetzt.

Fazit: Nutzen Sie Ihre Erfahrung als agiler Evangelist in Ihrer eigenen Organisation, um Ihre Kunden zu infiltrieren. Gehen Sie mit ihnen einen Lernprozess durch, gründen Sie eine vertrauensvolle Partnerschaft mit Schlüsselpersonen auf ihrer Seite und arbeiten Sie RUND UM den formalen, verknöcherten Anforderungsprozess, den sie unvermeidlich eingerichtet haben. Sie werden von den Jungs vor Ort bedankt, die das, was Sie entwickeln, tatsächlich nutzen müssen!

Sie gehen davon aus, dass die Anforderungen gut geschrieben sind und Sie denken, dass sie bedeuten, was sie meinen, dass sie bedeuten. Das Hin und Her des agilen Prozesses wird dazu beitragen, dass sie das bekommen, was sie gemeint haben, zusätzlich zu dem, wonach sie gefragt haben.