Was bedeutet es, agil zu sein?

Wir haben ein Projekt, von dem jeder sagt, dass wir es agil machen werden, aber ich bezweifle, dass wir klar verstanden haben, was agil ist.

In früheren Projekten hatten wir Planungsbesprechungen, definierten dann das Produkt-Backlog und teilten die Arbeit den Entwicklern in zwei- bis dreiwöchigen Sprints zu. Jeden Morgen hatten wir Scrum-Meetings (die jedes Mal eine halbe Stunde dauerten) und jeder Entwickler kam danach damit klar. Kaum jemand hat bis zum Ende des Sprints irgendwelche Tests geschrieben und nicht abgeschlossene Arbeiten wurden dem nächsten Sprint hinzugefügt.

Die Entwickler sprachen kaum miteinander und an der Entwicklung war kein TDD beteiligt. Tatsächlich hatten die meisten Entwickler zu Beginn eine Spezifikation und machten nur für die 2 oder 3 Wochen mit, für die der Sprint arrangiert wurde. Es gab kaum Kommunikation mit dem Kunden / Stakeholder.

Die Qualitätssicherung wurde in der Regel einige Monate später einbezogen, und bis dahin stellten wir fehlende Anforderungen fest, die den Arbeitsaufwand weiter erhöhten. Offensichtlich gab es keine Rückkopplungsschleife.

Meine Frage ist also, wo wir falsch liegen und wie ich verhindern kann, dass das Team die gleichen Fehler macht.

Was Sie beschreiben, ist nicht per Definition agil (Agiles Manifest), sondern ein Wasserfall mit täglichen Statusmeetings. Agil bedeutet, sich leicht an Veränderungen anzupassen. Wenn es keine interaktive Rückkopplungsschleife mit dem Produktbesitzer und damit den Kunden gibt, welche Veränderung findet dann statt?

Bei Agile geht es um schnelle Ausfälle durch ständige Kommunikation mit dem Produktbesitzer / Kunden. Es ist besser, früher als später zu scheitern, es wird weniger gearbeitet und es geht weniger "verloren". Und man bleibt nicht bei dem Argument hängen, dass "wir keine Zeit haben, es richtig zu machen, da wir so viel Zeit damit verbracht haben, es falsch zu machen, wir müssen einfach auf dem gleichen Weg weitermachen, auch wenn es zum Scheitern führt ".

Klingt so, als würde Ihr Management "SCRUM" machen, aber ... " wo das " aber " ist, wo sie all das SCRUM-Zeug rausschmeißen, das sie nicht verstehen oder mit dem sie nicht einverstanden sind, und die Dinge auf die gleiche zufällige Art und Weise wie immer machen, aber mit neuen, glänzenden Modewortnamen.

In SCRUM geht es beim täglichen Aufstehen NICHT darum, dem Management den Status zu übermitteln , sondern darum, die Entwicklerinteraktion zu erzwingen, damit Sie wissen, was Ihre Teamkollegen tun, und sich gegenseitig helfen und keine Doppelarbeit leisten können. Wenn es länger als 45 Sekunden dauert, machen Sie es falsch. Es geht um Transparenz für das Team. Wenn eine Person mehreren Tagen den gleichen Status für einen einzelnen Arbeitstag gibt, kann das Team das Personenproblem früher oder später lösen.

Wenn Sie den Code nicht so testen, wie er geschrieben wurde, tun Sie das auch nicht richtig. Das Testen sollte in den Prozess eingebettet sein und nicht nachgedacht werden. Die Qualitätssicherung sollte in die Planungssitzungen einbezogen werden und Schätzungen darüber enthalten, wie lange die Tests dauern werden.

Wenn Sie die Sprint-Verpflichtungen nicht einhalten und die Dinge nicht rollen, tun Sie es nicht richtig. Bei Sprints geht es um Verpflichtungen, wenn Sie zu viel Arbeit auf sich nehmen. Hören Sie auf, dies zu tun. Es gibt keine Möglichkeit, Vorhersehbarkeit oder Wiederholbarkeit einzuführen, wenn Sie sich nicht genau auf die zu erbringenden Leistungen festlegen können.

Jarrod gab eine gute Antwort (+1 dazu) und ich möchte darauf noch etwas eingehen.

Bei Agile geht es nicht nur um schnelle Ausfälle und Rückmeldungen zwischen dem Produktbesitzer (Kunden) und dem Team. Es geht um schnelles Feedback zwischen allen beteiligten Stakeholdern. Um wirklich agil zu sein (und das geht direkt aus dem Manifest hervor ), muss man erkennen, dass es nur einen Prozess gibt, der Entwicklern hilft, bessere Produkte zu liefern. Personen über dem Prozess bedeuten, dass Sie den Prozess ändern und zum Funktionieren bringen, sobald das Team erkennt, dass Ihr vorhandener Prozess nicht funktioniert.

"Scrum but ..." ist auch ein Thema, aber diese Münze hat beide Seiten. Wenn Sie sich das Manifest ansehen, werden Sie feststellen, dass es um das Team geht und dass Tools / Prozesse für Sie funktionieren. Keine zwei Teams sind gleich und daher wird jedes etwas anders funktionieren und das ist in Ordnung. Sie könnten sicher die gesamte Scrum-Methodik übernehmen und versuchen, sie genau zu befolgen und zu prüfen, ob dies für Ihr Team funktioniert.

Eine andere Alternative besteht darin, statt einen anderen Prozess in das Team zu verlagern und alle dazu zu bringen, die Anweisungen von Scrum zu befolgen. Probieren Sie den agilen Ansatz aus : Kommunizieren Sie mit dem Team und sehen Sie, ob Sie gemeinsam Problembereiche und Lösungen für jeden einzelnen identifizieren können. Führen Sie dann schrittweise Änderungen in Ihrer Arbeitsweise ein, damit Probleme behoben werden.

Es könnte eine Weile dauern, aber ...

1. Sie werden die größten Probleme zuerst beheben, was den größten Einfluss auf die Fähigkeit Ihres Teams hat, Produkte zu liefern
2. Indem Sie sofortige Probleme identifizieren und an der Erarbeitung von Lösungen mitwirken, verstehen Ihre Teammitglieder, warum bestimmte Praktiken wichtig sind, und tun sie nicht einfach, weil sie dazu aufgefordert werden.

Wenn wir eine Analogie zwischen Scrum und einem Entwurfsmuster ziehen, ähnelt die von mir vorgeschlagene Arbeitsweise dem Codieren in ein Muster, bei dem Sie den Code so einfach wie möglich halten und nur dann auf ein Entwurfsmuster konvergieren, wenn dies erforderlich ist. Im Gegensatz dazu, einfach ein Designmuster auszuwählen und damit zu rollen (dh Scrum und alle seine Prozesse blind als eine Gruppe auszuwählen), ist der Code manchmal komplexer und schwieriger zu warten, als es sonst möglich gewesen wäre.

Der Schlüssel zum Verständnis ist, dass es bei Agilität nicht darum geht, einen neuen Prozess für die Ausführung von Dingen zu entwickeln. es geht um ständige Veränderung und ständige Anpassung an bestehende Prozesse / Praktiken.

Wenn das Team (und sein Management) wirklich "agil" sein wollen, sollten sie als Team zunächst das Agile Manifest und seine Prinzipien lesen und diskutieren . Wählen Sie dann eine der agilen Methoden aus, die erstellt wurden ( z. B. Scrum ), lernen Sie sie kennen und befolgen Sie diese. Ich würde empfehlen, es eine Weile genau zu verfolgen, bevor ich es ändere, aber das bin nur ich.

Sie sollten sich auch eingehend mit den Ingenieurspraktiken befassen, die zur Unterstützung der ausgewählten agilen Projektmethodik verwendet werden.