Mehr Agilität wagen! – Teil 2: Personalfragen

Nach den Grundüberlegungen zur Einführung von Agilität im ersten Teil der Blogserie geht es nun um die Auswahl der passenden Mitarbeiter für Ihr Pilotprojekt.

Je nach agilem Ansatz gibt es Schlüsselrollen, die zu besetzen sind, im Fall von Scrum die Rollen des Product Owners, des Scrum Masters und der Developer (Entwickler). Setzt man diese agilen Rollen mit traditionellen Rollen in Bezug, stellt man fest, dass die Scrum-Rollen die Aufgaben mehrerer traditioneller Rollen übernehmen:

SOPHIST_Mehr Agilität wagen - Teil 2_Bild 1

Auch die Projektdefinition im Produktmanagement und in Scrum ist in Bezug auf den iterativ-inkrementellen Charakter recht ähnlich: Ein Projekt ist keine einmalige, zeitlich beschränkte Tätigkeit wie im klassischen Projektmanagement, sondern eine zyklische Aktivität zur Produktentwicklung oder -weiterentwicklung. Somit besteht bei der Besetzung des Pilotprojekts die Möglichkeit, Mitarbeiter in passenden Positionen „wiederzuverwenden“ falls bereits eine Linienstruktur existiert. Eventuell haben ja auch einige Mitarbeiter schon Erfahrung mit dem gewählten agilen Ansatz gesammelt?

Unabhängig von vorhandener Erfahrung im Unternehmen sollen Sie überlegen, zusätzlich externe Experten für den gewählten agilen Ansatz hinzuziehen, um nicht doch im Wasserfalldenken stecken zu bleiben.

Der Product Owner ist für Spezifikation, Pflege und Priorisierung des Product Backlogs verantwortlich, und vertritt in der Kommunikation mit dem Developer Team die Kunden- oder Auftraggeberseite. Er muss in der Lage sein, sowohl die Bedürfnisse aller Stakeholder des Projekts richtig zu erfassen und zu konsolidieren, als auch die Bedeutung einer User Story in Bezug auf den Return on Investment richtig zu beurteilen. Neben ausgeprägten Kommunikationsfähigkeiten sind daher auch ein gewisses technisches Verständnis und gute Kenntnis der fachlichen Domäne notwendig.

Um den Product Owner nicht zu überlasten, kann beispielsweise mit einem Product Owner-Team gearbeitet oder das Developer Team in die Spezifikationsarbeit mit eingebunden werden. Ein einzelner Product Owner kann sonst gerade in großen Projekten aufgrund mangelnder Verfügbarkeit und Verzögerungen bei der Aufbereitung von Anforderungen zum Flaschenhals werden, der die Entwicklungsarbeit behindert und das Projekt ausbremst.

Der Scrum Master unterstützt den Product Owner beim Projektmanagement und ist Hauptan­sprechpartner für das Developer Team, wenn es um die Beseitigung von Problemen geht, welche die Entwicklungstätigkeit behindern. Für unerfahrene Developer Teams agiert er auch als Team Coach in Bezug auf effiziente Selbstorganisation und Umgang mit dem Scrum-Prozess. Nicht nur während der Einführung von Scrum nimmt der Scrum Master im Unternehmen häufig eine Rolle ein, die in Opposition zu althergebrachten Denkweisen steht und muss daher neben guten Kommunikations­fähigkeiten auch über ausreichend Selbstbewusstsein verfügen, um sich behaupten zu können.

Bei der Besetzung des Development Teams muss darauf geachtet werden, dass alle Kompetenzen abgedeckt sind, die für die Arbeit in den Sprints benötigt werden. Die idealen Mitglieder eines Developer Teams haben vertiefte Kenntnisse in mehr als einer Disziplin. Im Gegensatz zu Spezialisten, die nur bestimmte Tätigkeiten bearbeiten, sind sie bereit, ihre Teamkollegen bei allen Tasks zu unterstützen, um das gemeinsame Sprintziel zu erreichen.  Sie arbeiten eigenständig und eigenverantwortlich, sind motiviert und können kommunizieren, sowohl innerhalb des Teams als auch mit Stakeholdern, z. B. bei Sprint Review Meetings.

Während es möglich ist, die Teamzusammensetzung zwischen Sprints zu variieren, um z. B. nicht vorhandene Kompetenzen einzubinden, bedeutet jede Veränderung des Developer Teams eine Phase, in der das Team erst wieder seinen Arbeitsrhythmus finden muss. Alternativ kann mit Experten gearbeitet werden, die dem Developer Team während des Sprints zur Verfügung stehen, um bei Aspekten zu unterstützen, in denen das Team erst noch Kompetenz entwickeln muss.

Im dritten Teil der Blogserie beschäftigen wir uns mit dem hybriden Ansatz als erstem Zwischenstopp in Richtung Agilität.

———————————————————-

Teil 1: Mehr Agilität wagen! – Teil 1: Grundüberlegungen zur Einführung von Agilität 
Teil 3: Mehr Agilität wagen! – Teil 3: Wasserfall und Scrum kombinieren 
Teil 4: Mehr Agilität wagen! – Teil 4: Die Agilen Zwischenstufen 
Teil 5: Mehr Agilität wagen! – Teil 5 : Leichter geht’s nicht 

———————————————————-

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert