Schmerzfreie Demo's

In einer agilen Projektumgebung sind regelmäßige Demoss are one of the main strongholds. Demogut für das Team und die Kunden. Sie setzen den Fokus und machen den Fortschritt schmerzhaft transparent. Agile fördert die Demonstration der Teamergebnisse in jeder Iteration, also alle 2-4 Wochen, und zwar von der ersten Iteration an. In diesem Artikel stellen wir Ihnen 2 reale Fälle vor und erörtern einige Überlegungen, die Sie berücksichtigen sollten, um zu verhindern, dass frühe Demoss to have a boomerang effect on the project. Early demodie Erwartungen der Kunden in unrealistische Höhen treiben, was zu Frustration auf allen Seiten führt. Fall 1 Bei dem Projekt ging es um die Entwicklung einer sehr technischen, innovativen Anwendung. Natürlich wandte das Team Agile, genauer gesagt Scrum, mit 2-Wochen-Sprints an. Zu Beginn des Projekts bestand das Team aus 3 sehr erfahrenen Experten. Nach nur 2 Wochen gelang es ihnen, den grundlegenden technischen Ablauf zu realisieren, den Proof of Concept, der notwendig war, um Vertrauen in die Machbarkeit der Investition zu schaffen. Sie waren begeistert und sehr stolz auf diese enorme Leistung! An der Demo am Ende des Sprints, der ersten des Projekts, nahmen ein Techniker des Kunden und Vertreter der Managementebene sowohl des Lieferanten als auch des Kunden teil. Mit einer Stunde Verspätung aufgrund anderer Besprechungen des Managements begannen wir schließlich gegen 16:00 Uhr. Es war schwierig, die geleisteten Anstrengungen zu zeigen: "Nun, hier sehen Sie die aktuelle Website, und wenn Sie dies und das auswählen und den 'Go'-Knopf drücken .....<1 Minute lang stumm auf den Bildschirm starren>.... tadaaaa .... da ist die neue Website!!!!!" Natürlich hatten wir diese kurze Aktion in eine Powerpoint-Präsentation verpackt, die einen Teil der technischen Komplexität erklärte. Das Publikum reagierte nur lauwarm. Es stellte sich heraus, dass sie den technischen Vortrag überhaupt nicht verstanden hatten und nun ja, wir müssen zugeben, dass der Action-Teil der Show nicht so spektakulär war. Die Diskussion verlagerte sich schnell auf die Benutzeroberfläche: "So können wir dieses Produkt niemals ausliefern!" Zwei Wochen später führten wir dasselbe System mit einem auffälligen Design vor und die Menge war sozusagen aus dem Häuschen. Fall 2 Ein paar Monate später waren wir an einem anderen Projekt beteiligt. Es sah ziemlich einfach aus. Wieder hatten wir einen 2-Wochen-Scrum-Rhythmus. Das System enthält ein komplexes Backend mit einem Datenlader und ein Front-End für die Website. In den ersten 3 Sprints nahmen wir Teile des Systems auf, erfassten einige Felder aus diesem externen Datenstrom und verarbeiteten sie bis hin zur Benutzeroberfläche. Eines der Teammitglieder beschloss, ihren freien Abend damit zu verbringen, die Benutzeroberfläche ein wenig in Richtung der Designskizzen, die wir gesehen hatten, zu vergolden. Das sah richtig cool aus!! Und so dachte der Kunde: "Wenn Sie das in nur ein paar Wochen schaffen können! Ich weiß, das ist erst der Anfang, aber fügen Sie einfach ein paar Funktionen hinzu und wir können live gehen! Ich weiß, dass dies erst der Anfang ist, aber ich bin sehr zuversichtlich, dass wir das Projekt rechtzeitig fertigstellen werden!" Wieder ist der Wahnsinn im Raum. Demo`s und Kundenerwartungen Im ersten Beispiel hat das Team hervorragende Arbeit geleistet, aber die Demo war nicht auf das Publikum abgestimmt. Es ist uns nicht gelungen, die Komplexität zu vermitteln. Wir hinterließen auch kein Gefühl des Vertrauens beim Kunden und bekamen auch nicht die Wertschätzung, die wir definitiv verdient hatten. Im zweiten Beispiel erwies sich der Data-Loader-Teil des Projekts als sehr, sehr komplex. Und ohne die Daten gibt es auf der Website wenig zu sehen. Die Erwartungen des Kunden waren bei der ersten Demo sehr hoch gesteckt worden, trotz der ausdrücklichen Hinweise, die wir während der Demo gaben. Tatsächlich hat sich diese erfolgreiche Demo gleich zu Beginn des Projekts im weiteren Verlauf des Projekts gegen uns gerichtet. Fazit Lassen Sie niemals eine Demo ausfallen, aber denken Sie nicht zu leichtfertig darüber nach. Fünf Regeln, die jede Demo erfolgreich machen. Sogar die erste!

1. Schenken Sie dem Kunden Vertrauen. Aber seien Sie vorsichtig mit der Angeberei. Wenn Sie zeigen, dass Sie gelernt haben, die Komplexität, insbesondere des Geschäftsumfelds, zu verstehen, gewinnen Sie ebenfalls Vertrauen.
2. Worte über Nuancen sind nicht genug. Sie müssen die Komplexität auf eine Weise sichtbar machen, die Ihr Kunde versteht.
3. Demo in Bezug auf die Funktionalität und den geschäftlichen Nutzen. Verwenden Sie die Wörter aus den implementierten User Stories.
4. Die ersten Sprints sind risikobasiert. Zeigen Sie das Risiko und die von Ihnen vorgenommene Risikominderung auf.
5. Seien Sie zurückhaltend und bescheiden, wenn es darum geht, schlaue Designs zu zeigen. Sparen Sie sich die schlauen Design-Dinger lieber auf, bis Sie sie brauchen.