Scaling Up: Warum die Ausrichtung der Organisation so wichtig ist und Tipps, wie Sie sie erreichen können

Wenn Sie sich weiter mit Al unterhalten möchten, treten Sie bitte der Gruppe Agile Product Management auf LinkedIn bei und stellen Sie Fragen.

Q&A MIT AL SHALLOWAY

Vielen Dank, dass Sie während der Live-Sitzung so viele Fragen gestellt haben! Hier sind Als Antworten auf mehrere Fragen, die wir nicht beantworten konnten.

F: Unser Unternehmen hat vor kurzem eine Stelle ausgeschrieben und beschreibt unsere Kultur als "...schnelllebig, ständig wechselnd und kooperativ". Ich musste innehalten und darüber nachdenken, wie die Kultur dazu beiträgt, dass Teams innerhalb einer Organisation aufeinander abgestimmt sind oder nicht?

A: Die Unternehmenskultur kann einen großen Einfluss darauf haben, ob das Unternehmen Einzelpersonen und/oder Helden belohnt oder nicht. Wenn dies der Fall ist, wird die Ausrichtung beeinträchtigt. Aber man muss zunächst verstehen, was Kultur ist - ein Spiegelbild der Managementpolitik der Organisation. Wenn Sie sich für dieses Thema interessieren, sollten Sie lesen, warum Sie sich nicht auf die Unternehmenskultur konzentrieren sollten.

F: Wie kann ich die Akzeptanz für ein Tool schaffen, das uns dabei hilft, die Arbeit in meinem Unternehmen abzustimmen, zu priorisieren und zu verwalten?

A: Bevor man über ein Tool spricht, muss man die Beziehung zwischen der Verbesserung einer Organisation und ihrem Einsatz von Tools verstehen. Viele Unternehmen stürzen sich auf ein Tool, um ihr Problem zu lösen. Ihre Logik ist, dass die Menschen einem effektiven, klar definierten Prozess folgen werden, wenn sie das Tool richtig einrichten können. Leider setzt dies voraus, dass das Tool das Richtige tut. Die Realität sieht so aus, dass Unternehmen zunächst herausfinden müssen, was benötigt wird, und dann ein Tool entwickeln müssen, das diesen Bedarf deckt. Um die Akzeptanz für ein Tool zu gewinnen, müssen Sie den Leuten zeigen, wie es die Verschwendung, die Ihr aktueller Prozess verursacht, verringern kann.

F: Sollten die Teammitglieder sehen können, was auf der Portfolio-Ebene ansteht?

A: Das ist tatsächlich eine sehr wichtige Sache, die Sie tun sollten. Mit einem Tool wie Planview AgilePlace ist das zwar möglich, aber die meisten Tools sind nicht auf diese Weise eingerichtet.

F: Wie können wir uns an den WIP-Grenzen (Work-in-Process) orientieren?

A: Bestimmen Sie die WIP-Grenzen durch Experimentieren. Erstellen Sie zunächst ein Board in einem Tool wie Planview AgilePlace, das den Arbeitsablauf zeigt - so können Sie sehen, wo sich Dinge stauen. Setzen Sie dann Ihr WIP-Limit an diesen Punkten fest - und zwar etwas niedriger als jetzt. Wenn Sie in Ihrem Arbeitsablauf "Blasen" haben (d.h. Leute, die bereit sind, aber nichts in ihrer Warteschlange haben), dann ist Ihr WIP-Limit zu niedrig. Vielleicht interessiert Sie dieses Webinar von Planview AgilePlace über die Festlegung und Verwaltung von WIP.

F: Meine C-Levels erdrücken uns mit Command-and-Control-Führung, aber ich glaube, sie wären bei der Skalierung von Agile effektiver, wenn sie einen dienenden Führungsansatz verfolgen würden. Wie kann ich sie dorthin bringen?

A: Dienende Führung sollte darin bestehen, zu sehen, was gebraucht wird und die Menschen zu unterstützen. Es bedeutet nicht, Befehle von den Teams anzunehmen. Führungskräfte müssen ein Umfeld schaffen, in dem die ihnen unterstellten Mitarbeiter effektiver arbeiten können. Wenn Sie anfangen, mit Leuten über dienende Führung zu sprechen, die in der Vergangenheit mit Befehl und Kontrolle gearbeitet haben, werden sie wahrscheinlich das Gefühl haben, dass sie keinen Platz mehr haben und selbst wenn sie einen hätten, nicht wissen, was sie tun sollen. Dieser Blog könnte für Sie interessant sein: Die Bedeutung von Führung und Management in agilen Unternehmen.

F: Was halten Sie von SAFe (Scaled Agile Framework) für den Ausbau von Agile in Unternehmen?

A: Wir sind Gold-Partner, tragen zu SAFe bei und ich bin ein ehemaliger SPC-Trainer. Von den definierten Methoden gefällt uns diese also am besten. Allerdings verwenden wir es nicht direkt aus der Schachtel heraus, sozusagen. Wir halten die Verwendung von MVPs/MBIs für unerlässlich, und ihre Bedeutung wird in SAFe nicht ausdrücklich genannt. Außerdem unterscheidet sich die Dekomposition, die wir im Webinar besprochen haben, von den epischen -> features -> Geschichten von SAFe. Wenn wir also SAFe anwenden, neigen wir dazu, die im Webinar besprochenen Produktmanagementkonzepte mit der Methodik zu überlagern.

Da wir vor 4 Jahren zu SAFe in den Bereichen ATDD, TDD und Kanban bei Shared Services beigetragen haben, sind wir den jährlichen Veröffentlichungen in der Regel ein wenig voraus. Ich will damit sagen, dass man SAFe wirklich als Rahmenwerk verwenden und nach Bedarf ergänzen und erweitern sollte. Die wichtigsten Aspekte von SAFe, die uns gefallen, sind die ganzheitliche Sichtweise, die Wertschätzung von Lean, die Wertschätzung des Managements und die solide Planung, die für große Organisationen erforderlich ist. Mehr über und die Anpassung und Erweiterung von SAFe an Ihre Bedürfnisse erfahren Sie hier.

Wir haben einen alternativen Ansatz zu SAFe, bei dem wir mit einem auf die Bedürfnisse unserer Kunden zugeschnittenen Rahmenwerk beginnen, das die guten Dinge von SAFe enthält, sich aber auf die Bereitstellung von Geschäftswerten und das agile Produktmanagement konzentriert. Dabei stellen wir fest, dass es für eine Organisation, die sich verändern möchte, einfacher ist, diese zu übernehmen. In manchen Organisationen funktioniert nur ein vorgefertigter Ansatz, und dann verwenden wir gerne SAFe.

F: Sie haben zahlreiche Methoden erwähnt, mit denen Sie die iterative Entwicklung angegangen sind, wie z.B. Scrum, XP, Lean, SAFe, TDD, ATDD, und emergentes Design. Können Sie das näher erläutern?

A: Die Beantwortung dieser Frage könnte ein ganzes Buch in Anspruch nehmen, aber lassen Sie mich kurz erläutern, wofür ich jedes dieser Tools halte und wie ich sie am liebsten sehe.

• Scrum und XP: Ich halte Scrum für einen sehr guten Teamansatz, der als Rahmenwerk, das über das Team hinaus funktionieren kann, überbewertet wurde. Scrum und XP unterscheiden sich vor allem dadurch, dass XP technische Praktiken (wie TDD, ATDD und emergentes Design) einbezieht, während Scrum dies nicht tut. Sowohl Scrum als auch XP verwenden Iterationen, um schrittweise aufzubauen.
• TDD und ATDD: TDD sorgt für ein besseres Design, eine bessere Codequalität und automatisierte Tests des Codes aus einer funktionalen Perspektive. ATDD schafft Klarheit über die Anforderungen und ermöglicht es, das gewünschte Verhalten auf einer hohen Ebene zu definieren und es im Laufe der Zeit zu verfeinern. Weitere Informationen zu ATDD/TDD finden Sie unter Built-In Quality with Test-First. Obwohl es Teil der Tuning SAFe Webinar-Reihe ist, ist es so gut wie unabhängig von SAFe selbst.
• Unser eigener Ansatz ist das, was wir "Team-Agilität" nennen. Obwohl wir diesen Begriff schon seit Jahren verwenden, schreiben wir erst jetzt eine formellere Definition. Sie können den Anfang dieser hier sehen.

Lean ist so ziemlich die Grundlage für das, was wir bei Net Objectives tun. Ich diskutiere SAFe in der Antwort auf eine andere Frage in diesem Blog. Weitere Informationen zu SAFe und emergentem Design finden Sie auf unserer Webinar-Ressourcenseite .

ZUSÄTZLICHE RESSOURCEN, AUF DIE WÄHREND DER SITZUNG VERWIESEN WIRD:

• Gewichteter kürzester Auftrag zuerst verstehen
• Design Patterns Explained: A New Perspective on Object-Oriented Design , von Al Shalloway und James R Trott [Buch]
• Die Prinzipien des Produktentwicklungsflusses: 2nd Generation Lean Product Development, von Don Reinertsen [Buch]
• Eine vollständige Liste der Videos und Bücher, auf die während des Webinars Bezug genommen wurde, finden Sie auf dieser Seite Net Objectives resources.
• Wenn Sie einen Tag lang etwas über agiles Produktmanagement lernen möchten, sollten Sie an einem Net Objectives Agile Product Management Symposium teilnehmen.