Projektmanagement mit Scrum Teil 3

Teil 1: Die Projektmanagement-​​Methode Scrum   

Teil 2: Die Rolle des Product Owner auf Kundenseite

• Mein Scrum Master ist mein wichtigster Partner

Als Product Owner bin ich auf ein starkes Team angewiesen. Daher sollte ich immer einen guten Draht zum Scrum Master haben. Denn der Scrum Master sorgt dafür, dass “sein” Team Höchstleistung bringt und die Wünsche des Product Owners mit vollem Elan und höchster Präzision umsetzt. Er achtet auf die “Fitness” des Teams und sorgt dafür, dass alle Probleme (sog. “impediments”), die dem Erfolg des Teams im Weg stehen könnten, beseitigt werden.

• Mache Meetings nur wenn es sinnvoll ist

Klar, reden ist wichtig. Aber immer und überall? Zeit ist Geld, hinterfrage daher jedes Meeting. Jeder ist motiviert, wenn er aus einem Gespräch mit einer klaren Botschaft herausgeht. Also kläre vorher ab: Was wollen wir als Team erreichen? Brauchen wir dafür ein zusätzliches Meeting? Habe ich andere Möglichkeiten? Der Scrum Master steht Ihnen hier als Partner immer hilfreich zur Seite.

• Vertraue der Kraft des Teams

Nicht die ständige Kontrolle und Vorgabe der nächsten Schritte führt zu einem besseren Ergebnis. Vertraue der Selbstorganisation. Denn wenn Du abwartest und das Team die technischen Entscheidungen treffen lässt, wirst Du schnell feststellen wie das Team sich entwickelt, sich inhaltlich einbringt und welche enorme Performance entsteht. Die konkrete technische Umsetzung von Anforderungen ist das tägliche Brot des Teams. Genau dieses Wissen und diese Erfahrung möchten Sie für Ihr Projekt nutzen!

• Sie müssen nicht alles wissen

Du hast ein professionelles Team mit Fachleuten. Wunderbar, also können Sie sich zurücklehnen, deren Vorschlägen und auch Schätzungen vertrauen - sie machen das ja schließlich nicht zum ersten Mal.

So haben Sie die Freiheit sich auf Ihre fachlichen Aufgaben zu konzentrieren. Das Team wird schon Wege finden, diese effizient umzusetzen. Das ist echte Teamarbeit!

• Sei ein Servant Leader

Gute Führung ist die, die gar nicht als solche empfunden wird. Und bei der teamorientierten Arbeitsweise in Scrum gibt es auch keine klassische Führung. Sie sind Teil des Teams und geben hier die fachlichen Anforderungen vor. Sie sind zusammen mit dem Scrum Master ein “Servant Leader”.

• Kennen Sie Ihre Stakeholder?

Wenn Sie Ihre Stakeholder kennen und deren Ansichten verstehen, dann können Sie deren Wünsche gut in das Projekt einbringen. Denn deren Bedürfnisse sind wichtiger als Ihre persönlichen Vorlieben. Damit unterstützen Sie das Team und hältst dem Team die “politische” Kommunikation fern.

• Die Time-Box ist für Sie unantastbar

Das „time-boxing“ gibt Planungssicherheit. So weiß jeder im Team wie lange ein Meeting dauert und wieviel Zeit noch für die eigentliche Arbeit bleibt. Alle fokussieren sich und bringen alle Themen auf den Punkt. Wichtiges kommt in den Vordergrund und unwichtiges wird an anderer Stelle geklärt.

• Nutze Sie Ihren Scrum Master und das Entwicklungsteam

Als Product Owner haben Sie dank des Entwicklungs-Teams und des Scrum Masters immer einen Überblick auf den Status der Arbeiten, die Qualität und die Geschwindigkeit. Wenn Sie Fragen haben oder etwas klären möchten:

Sprechen Sie mit dem Team. Wenn Sie Fragen zum Prozess haben, Ihnen etwas quer sitzt, nicht gefällt oder Sie Verbesserungsvorschläge haben: Sprechen Sie mit dem Scrum Master.

• Wer nicht fragt bleibt dumm

Sie können keine falschen Fragen stellen. Also nehmen Sie kein Blatt vor den Mund. Denn Sie müssen Klarheit in allen Themen bringen. Fragen Sie was die Stakeholder wirklich wollen und frage das Team, ob sie dies auch vollständig verstanden haben. Frage den Scrum Master wie fit das Team augenblicklich ist und was Sie zum Erhalt beitragen können.

• Das Projekt ist Chefsache - aber der Chef ist nicht da!

Das Webprojekt wird immer mehr das entscheidende Kommunikations- und auch Arbeitsinstrument. Von daher muss es auch Chefsache sein.

Erstes Projektmeeting: Seit 45 Minuten wird das vorab besprochene neue Design vorgestellt und in der Arbeitsgruppe werden die nächsten Schritte festgehalten. Die Tür geht auf und der Chef kommt rein, lässt sich unaufgefordert das Ergebnis zeigen und zerpflückt den Entwurf, ohne die Zusammenhänge zu kennen. Nach 10 Minuten stellt er fest, dass ihm doch Hintergrundwissen fehlt und das nächste Meeting wartet. Er hinterlässt die Arbeitsgruppe mit dem Hinweis alles doch noch einmal zu überarbeiten.

So bitte nicht!

Gute Vorgesetzte delegieren und vertrauen Ihren Mitarbeitern und somit ihrem Product Owner. Der Product Owner trifft innerhalb des Projektes die Entscheidungen. Er oder sie kommuniziert natürlich die Ergebnisse und bindet seine oder ihre Vorgesetzten ein.

• Product Owner ist ein Fremder - bitte nicht!

Wer soll das Projekt steuern? Intern ist schnell keiner zur Hand. Das Tagesgeschäft hält jeden fest im Griff. Wie soll auch eine Mitarbeiterin oder ein Mitarbeiter mal eben für 4 oder 6 Monate auch noch den Webrelaunch betreuen. Also wird eine neue Stelle geschaffen und mit einer neuen Kraft besetzt.

Guter Ansatz, wenn die Bereitschaft da ist der Arbeit als Product Owner auch die notwendige quantitative Bedeutung zu geben. Jedoch meist eine schlechte Wahl, da die neue Kraft sich erst ein Standing aufbauen muss. Ihr sind die internen Zusammenhänge fremd, sie kennt die informellen Wege noch nicht und so kann sie leicht gegen Wände laufen.

Entlasten sie eher eine erfahrene Mitarbeiterin von anderen Tätigkeiten, damit sie sich mit all ihrem internen Wissen gut auf das Projekt fokussieren kann.

• Scrum ist ja nett, aber Regeln sind zum Brechen da!

“Ich kann heute am Planning nicht teilnehmen, aber das klappt doch auch ohne mich.” und “Heute müssen wir mal statt 60 Minuten mindestens 120 Minuten reden, ich habe da eine Idee.” “Scrum, but...” - wie man auch dieses Aufweichen von Regeln nennt, führt nur zu Zeitverlust, zu Frust im Team und somit zu schlechteren Ergebnissen. Man sollte sich darüber im Klaren sein, dass die wenigen Regeln, die es im Scrum gibt, jeweils einen sehr konkreten Grund haben. Letztendlich schützt jede Regel entweder die Performance, die Produktqualität und/oder Ihr Budget.

Um es an diesem konkreten Beispiel zu verdeutlichen:

Wenn Sie ein Kernmeeting mit 4 Entwicklern, 1 Designer, 1 Scrum Master und 1 Product Owner mit einer Time-Box von 60 min. nun auf 120 min. ausdehnen, dann kostet sie das 7h. Das sind 7h, in denen ein Entwickler im Scrum, sehr viele Ihrer Anforderungen umsetzen könnte, die für Sie einen hohen Geschäftswert haben. Schon allein aus diesem Grund würde der Scrum Master an dieser Stelle intervenieren.

Agiles Projektmanagement mit Scrum aus Kundensicht

Teil 1: Die Projektmanagement-​Methode Scrum    Teil 2: Die Rolle des Product Owner auf Kundenseite