Wie stelle ich Agile einem Team vor, das starre, nicht agile Methoden einsetzt?

Stellen Sie sich ein Unternehmen vor, das stolz darauf ist, für eine nicht agile Methode zertifiziert zu sein, und das es als Verkaufsargument für seine Kunden nutzt, um Rechenschaftspflicht zu demonstrieren.

Wie gehen Sie vor, um Kanban oder Scrum schrittweise einzuführen, ohne das gesamte System zu beschädigen und dennoch zuversichtlich zu sein, dass es genauso rechenschaftspflichtig / überprüfbar sein kann ?

Ich weiß, dass dies möglicherweise mit " Wie würden Sie eine agile Methodik wie Scrum einführen " zusammenhängt, aber hier frage ich mich, wie man die Tatsache umgehen kann, dass das Unternehmen eine bestimmte Art der Verwaltung des SDLC unter dem falschen Vorwand auferlegt, dass dies der Fall ist der einzige Weg, einen Audit Trail zu haben.

Ich denke, es ist ein Mythos, dass agile Projektteams ihre Anwendungen nicht dokumentieren, und dies ist der erste Widerstandspunkt, den Sie in Unternehmen erhalten, die zertifiziert sind, um die beste Dokumentation gemäß ihren Standards zu haben.

Ich arbeite in einem ISO-9001-zertifizierten Unternehmen, aber wir machen auch Scrums für eine große Anzahl unserer Projekte. In unserem Fall kam die Änderung von den Project Delivery-Verantwortlichen (dh von hochrangigen Mitarbeitern), weshalb sie übernommen wird - im Gegensatz zu einem Projektmanager oder Entwickler, der versucht, diese Änderung voranzutreiben.

Eine nützliche Praxis, der wir folgen, ist Dokument genug, aber kontinuierlich . Dies bedeutet natürlich, dass wir nicht alle für das Projekt vorgeschriebenen Vorlagen befolgen, aber es besteht ein bewusstes Verständnis und eine Übereinkunft darüber, welche Abschnitte / Dokumente benötigt werden, im Vergleich zu denen, die nur unnötige Gemeinkosten verursachen.

Sie müssten dann diese Sichtweise sozialisieren und die Genehmigung der Qualitätsgruppe oder der Normungsabteilung oder wie auch immer erhalten.

Das Agile-Prinzip ist 'gerade genug' Dokumentation. Können Sie versuchen, den Kunden dazu zu bringen, dem Team mitzuteilen, wie viel gerade ausreicht? Der Projektmanager kann mit dem Kunden sprechen und dessen Erwartungen und organisatorische Anforderungen verstehen. Anschließend kann er die Entscheidung dokumentieren und diese Erwartungen erfüllen. Wenn es für sie (dh die zahlenden Kunden) gut genug ist, kann es das sein, was Sie befolgen.

Wenn sie glauben, dass Agile nicht für große Projekte geeignet ist, überzeugen Sie sie davon - durch Zersetzung und parallelen Aufwand.

In großen Unternehmen wird die Kontrolle und Überwachung großer Programme durch die Führung eines Projektüberwachungsbüros (PMOs) gewährleistet, das konventionelle Planungen für Kosten- / Rechnungswesen- / Ressourcenmanagement usw. durchführt. Daher ist eine Menge Dokumentation erforderlich, die Fortschritte können jedoch mithilfe agiler Verfahren überwacht werden (die SCRUM-Burndown-Tabelle für eine). Sie müssen wissen, wie ihnen Techniken wie die kontinuierliche Integration früher als später helfen. Daher ist es für die Produktivität aller Beteiligten besser, Overhead-Dokumente aus dem Weg zu räumen.

Agilität ist eine Reihe von Fähigkeiten, die ein Team erlernen kann, die weitgehend orthogonal zu unseren traditionellen technischen Fähigkeiten sind. Aber wenn Sie dies zu ihren vorhandenen Fähigkeiten hinzufügen, können Sie natürlich ein effektiveres Team werden. Tägliche Stand-ups (zB Scrum-Meetings) werden nicht über Nacht möglich sein - aber Sie würden derzeit regelmäßige Team-Meetings (etwa zweiwöchentlich) haben? Ich würde sagen, beginnen Sie damit, diese in das Befolgen der Scrum-Fragen-Agenda umzuwandeln (nicht zu hinterhältig;) und dem breiteren Team zu vermitteln, warum dieser Ansatz funktionieren kann und nicht laxe Dokumentation / schlechte Standards oder was auch immer andere Mythen bedeuten.

Ich würde zuerst Scrum von Kanban trennen.

Mit Kanban - und hier ist eine ziemlich gute Quelle, wie man es richtig macht - ist das Prinzip, dass Sie den aufregenden Prozess respektieren, wenn Sie anfangen. Kanban ist nicht das, womit Sie den bestehenden Prozess ersetzen, sondern das, was Sie darauf anwenden. Zeichnen Sie es auf, visualisieren Sie es und richten Sie bestimmte Bedingungen für eine schrittweise Verbesserung ein.

Scrum unterscheidet sich grundlegend in dem Sinne, dass es den bestehenden Prozess verdrängen wird.

Ein Team, das an 12-monatige (oder längere) Wasserfall-SDLC-Zyklen gewöhnt ist, wird es sehr schwer haben, zu Scrum überzugehen. Eine schrittweise Verkürzung des Zyklus auf 6- oder 3-Monats- Release-Züge mit geringerem Umfang könnte ein nützlicher Zwischenschritt sein.

Wie bei jeder neuen Sache, die Sie versuchen, einer Organisation vorzustellen, werden Sie starken Widerständen ausgesetzt sein. Sind Sie bereit, kritisiert zu werden und die Verantwortung zu übernehmen, wenn dies fehlschlägt? Du musst ein starker Mensch sein. Das ist der Preis, den Sie zahlen müssen, wenn Sie sich aussetzen.

• Fragen Sie sich, warum Sie Scrum verwenden möchten . Müssen Sie ein echtes Problem lösen?
• Stellen Sie sicher, dass SIE sich dazu verpflichten , denn niemand wird es für Sie tun. Sie werden der Besitzer der Sache sein. Zumindest bis es positive Effekte in der Organisation bringt
• Trainiere dich . Bücher und Internet reichen nicht aus. Gehen Sie zuerst zu einem Kurs, oder Sie erhöhen Ihre Chance, Scrum falsch zu implementieren, dramatisch. Was wahrscheinlich dazu führen wird, dass Ihr Team schlechtere Ergebnisse erzielt als zuvor
• Verkaufe es zuerst an das Team . Sie müssen natürlich ihre volle Unterstützung haben
• Schlagen Sie keine Änderung vor, schlagen Sie einen Test vor . Und überleg es dir so. Scrum passt möglicherweise nicht zu Ihrer Organisation (oder zu Ihrem Team)
• Finden Sie einen Sponsor im Top-Management

Genau das ist bei uns passiert. Wir folgten strengen, nicht agilen Methoden. Als ein neuer Lead Technical Manager hinzukam, der Erfahrung mit SCRUM hatte , hielt er es für gut, es auszuprobieren.

Wir haben es so gemacht, dass eine kleine Gruppe von Entwicklern (und Analysten) ein Pilot-SCRUM-Team zusammengestellt hat. Wir folgten ungefähr 4 Monate lang der strengen SCRUM-Methodik, wonach das Unternehmen darüber nachdachte, was wir getan haben, wie wir es getan haben, und Daten analysierte (Sie wissen, alles, was die BA tun muss).

Was sie fanden, war, dass der Pilot ein großer Erfolg war. Also haben sie eine weitere Mannschaft gebildet, die Kanban folgt, und auch sie waren ein großer Erfolg. Ich denke, es ist die Rede davon, dass der Rest der Entwickler auch SCRUM / Kanban-Teams bildet.

Ich denke, der Pilot war ausschlaggebend. Es gibt der strengen Seite des Geschäfts Zeit zu bewerten und zu sehen, dass es zuerst funktioniert.

Ich bin ein agiler Coach und einer der Schlüssel zur Veränderung von Initiativen ist das Buy-in auf allen Ebenen! Dazu gehören Führungskräfte, Entwicklungsteams, Manager, ... usw. Bevor ich einen großen oder kleinen Änderungsaufwand ankündige, würde ich vorschlagen, zuerst Einzelpersonen mit an Bord zu nehmen. Dies durch ein Gespräch mit einer dritten Person zu tun, ist die einfachste Möglichkeit für Einzelpersonen, neue Ideen zu entwickeln. Was ist die dritte Person? Ein Blog, ein Youtube - Video, eine Präsentation, ... usw. Auf diese Weise können diese Leute ihre eigenen Ideen einbringen und mit Ihrem Einfluss mit einer Veränderungsinitiative an Bord springen.

Hier sind zwei clevere Videos, mit denen ich auf allen Ebenen der Nahrungskette Interesse geweckt habe.

Kanban: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI