Das Internet ist voll von Menschen die interessante, tiefgründige oder aus anderen Gründen lesenswerte Artikel schreiben. Viele dieser Texte landen bei mir, wo sie als „Food for Thought“ dazu beitragen, dass auch mir die Themen nicht ausgehen. Wie am Ende jedes Monats gibt es auch diesesmal wieder eine kommentierte Übersicht über die
erwähnenswertesten.
Vor einiger Zeit hatte ich in den kommentierten Links
über Brian Milner geschrieben, der der Meinung ist, dass jeder Product Owner ein zweites Team neben seinem Scrum Team hat, sein Stakeholder Team nämlich. Roman Pichler geht hier noch einen Schritt weiter und rät dazu, das Scrum Team durch die Integration der (zentralen) Stakeholder zu einem Product Team auszubauen. Das hat seinen Charme, und wie er richtigerweise schreibt sollte es durch die Einbeziehung der Stakeholder in Sprint Reviews und anlassbezogene Meetings ohnehin gegeben sein. Die Frage für mich ist aber: hat eine derartig vergrösserte Gruppe dann nach die Charakteristiken eines Teams?
Es ist eine Falle in die viele Organisationen getappt sind während sie versucht haben sich in Richtung Agilität zu transformieren - mit der Absicht Bürokratie abzubauen werden mittlere Management-Schichten gestrichen, aber statt die Teams zu befreien werden diese dadurch mit zusätzlicher Abstimmungs- und Koordinationsarbeit überhäuft, die sie jetzt selbst machen müssen. Den Grund darin sieht Chris Combe in einem Denkfehler: der Annahme, dass es sich bei diesen Management-Schichten um Wildwuchs handeln würde, während sie in Wirklichkeit die notwendige Folge einer zu stark arbeitsteiligen Organisation mit Mehrfach-Zuständigkeiten sind. Vor einem Hierarchieabbau empfiehlt er daher mehr Empowerment der Teams.
In diesem Artikel habe ich vieles aus meinem Arbeitsalltag wiedergefunden, in dem ich als externer Agile Coach immer wieder mit (Kunden-)internen Gegenübern zusammenarbeite. Robert Galen hat eine gute Übersicht über die Unterschiede in Wahrnehmung, Ansehen, Einfluss und weiteren Kategorien zusammengestellt. Was er aufbauend darauf für sinnvoll hält ist die Einbindung beider Typen in den Agile Coaching-Chaptern oder -Gilden von Unternehmen. Die Externen können immer wieder neue Impulse und an anderen Orten gemachte Erfahrungen einbringen, die Internen können langfristig wirken und Netzwerke aufbauen, ausserdem ist durch sie eine langfristige Identifikation mit der Firma gegeben.
Bei Kunden deren Projekte einen Hardware-Anteil haben bin ich bereits
mit 5S in Berührung gekommen, dort wird es u.a. für die Standardisierung, das Aufräumen und das Sauberhalten von Arbeitsplätzen genutzt. Robert Falkowitz schlägt hier einen weiteren Verwendungszweck vor, der bei näherer Betrachtung hochgradig naheliegend ist: den Betrieb von Kanban-Boards. Auch die haben bei nachlässiger Disziplin die Tendenz schnell unaufgeräumt und unübersichtlich zu wirken, genau wie es bei Arbeitsplätzen der Fall ist. Und mit den selben Methoden in denen man dort für Ordnung sorgt können auch Kanban-Boards (wieder) in den Zustand kommen übersichtlich und selbsterklärend zu sein.
Einfache Zusammenarbeit war gestern, jetzt kommt die radikale Zusammenarbeit! Das klingt zwar etwas marktschreierisch, hat aber Substanz. Matt K. Parker versucht unabhängig von den gängigen methodischen Frameworks zentrale Faktoren für die Ein- und Durchführung intensiver Zusammenarbeit zu nennen. Gerade für die den Einsatz bei "Methoden-Muffeln" eine gute Zusammenstellung.
