Drei Tipps von erfahrenen Projektmanagern, die immer gelten – auch in Scrum

Als kurze Anekdote: Ende der 90er habe ich mein Projektmanager Examen bei einer renommierten Projektmanager Beratung gemacht. Unser Coach war ein älterer Herr (wahrscheinlich so alt, wie ich heute ;)).

Er hatte vor seiner Lehrtätigkeit AKWs in Südamerika gebaut (nicht son unkritischen Quatsch wie Webseiten). Am Anfang des Kurses sagte er zwei Dinge, die mir nie aus dem Kopf gingen – und die sich als wahr herausstellten:

1. Überlegen Sie sich gut, ob sie Projektmanager werden wollen. Denn: wenn es gut läuft, war es ihr Team; wenn es schlecht läuft, waren Sie es.

2. Sie können Böcke nicht vermeiden – probieren Sie es gar nicht erst. Das Einzige, was Sie beeinflussen können ist, wann die Böcke gebaut werden. Je früher im Projekt, desto besser.

Bonus: ach ja, jetzt, wo ich darüber nachdenke, fällt mir noch ein Rat ein, den er uns gab.

“Wenn Sie wollen, dass ein Projekt scheitert – dann machen sie es groß.”

How to organize projects with more than one Scrum team involved using Jira?

In the Jira cloud we organised it this way: – Each Scrum team has its own project. – Each customer project has its own project (but you can also differentiate by features, initiatives and so on)

The customer project organises the main and complete product backlog for the specific project.

...

While in the Scrum teams only issues assigned to that team are maintained and worked on.

The advantages:

You can organise your work across more than one development team AND have a central backlog with given reports and epics management for example.
You can easily organise who has access to what type of project. E.g. customers or freelancers

Kill your Definition of Ready (DoR)

I’ve rarely met a Scrum team that was capable of maintaining a DoR as a living artifact out of their own motivation (mea culpa). On the contrary; the DoR either keeps growing or becomes increasingly defensive. In the end, you’re left with a shield against tasks—because no story will ever meet the requirements of that Definition of Ready again.

I am now convinced that standardizing “readiness” kills two of the most important agile tools:

Gut feeling
Discussion

In Germany especially, people end up arguing about semantics rather than the problem, the feature, the issue... I really support this idea: kill your DoRs ;) #Scrum #ScrumMaster #DoR PS I think there’s a reason why there is no DoR in the #ScrumGuide

DE: Ich habe kaum ein Scrum-Team getroffen, das in der Lage war, eine DoR selbstmotiviert als lebendiges Artefakt zu erhalten (mea culpa). Im Gegenteil; die DoR wird wahlweise immer größer, immer abwehrender; am Ende hast du einen Schutzschild gegen Aufgaben – denn erfüllen wird die Vorgaben der Defintion of Ready keine Story mehr.

Ich bin inzwischen davon überzeugt: Die Standardisierung von “Readyness” tötet zwei der wichtigsten agilen Werkzeuge: 1. Das Bauchgefühl 2. Die Diskussion

Vor allem in Deutschland diskutiert man am Ende eher über Semantik als über das Problem, das Feature, das Issue...

Ich unterstütze diese Idee wirklich: kill your DoRs ;)

#Scrum #ScrumMaster #DoR

PS Ich denke, es gibt einen Grund, warum es keine DoR im #ScrumGuide gibt

Scrum Master sind “Farmer”

Ich beschreibe die Tätigkeiten eines Scum Masters ja auch gerne mit dem Bild des Gärtners oder Farmers. Und es passt gut, wie für alle Führungsrollen ...

***

Die besten Führungskräfte denken wie Farmer 👩‍🌾

(7 Praktiken, die Ihnen helfen, dasselbe zu tun):

1) Brüllen Sie die Pflanzen nicht an –> Verstehe und führe ohne Druck

2) Geben Sie den Pflanzen nicht die Schuld –> Anstrengung anerkennen & Wachstum unterstützen

3) Entwurzeln Sie die Pflanzen nicht –> Sei geduldig mit den Fortschritten und gib ihnen Zeit, sich zu entwickeln

4) Wähle die besten Pflanzen für den Boden –> Bringen Sie Menschen mit Problemen zusammen & begrüßen Sie die Vielfalt

5) Bewässere und dünge –> Investiere in ihre Entwicklung & lobe großzügig

6) Unkraut entfernen –> Negativität ansprechen & giftige Menschen loswerden

7) Denken Sie daran, dass es Jahreszeiten geben wird (gute + schlecht) –> Antizipieren Sie Veränderungen und bereiten Sie sie auf Herausforderungen vor

Ein großes Lob an Eric Partaker für diese Tipps.

Beginnen Sie noch heute damit, die Saat des Erfolgs zu pflanzen. Führung mag komplex erscheinen. Aber in Wirklichkeit, einige einfache Praktiken können viel bewirken.

Via Linkedin

#Leadership #Scrum #ScrumMaster

Darf man das Daily in Scrum ausfallen lassen?

tl;dr: Man darf, allerdings eine echte Schietidee!

Celina, Scrum Masterin und Agile Coach, postete auf LinkedIn, dass Sie das Daily ausfallen lassen würde, wenn das Team nachhaltig keinen Sinn darin sieht.

“Ich würde auch so weit gehen, wenn das Team den Wert des Dailys nicht sieht auch die komplette Serie abzusagen”

– ich nicht!

Ich halte das Daily Scrum Event sogar für eines der wichtigsten Events in Scrum überhaupt.

Es ist das zentrale Steuerungsinstrument des Development Team im Sprint; – um den aktuellen Status zu kommunizieren, – die Arbeit des Tages zu besprechen und – imho am wichtigsten - – den Abgleich zum Sprintziel zu leisten.

Scrum Master sind nicht nur Servant Leader, sondern haben auch die “Domain Leadership” inne, was heißt, dass sie wichtige Events in ihrer Scrum-Domain eben auch als obligatorisch markieren und durchsetzen können – imho sollten.

Bleibt das Ausfallen keine Ausnahme, müssen wir Scrum Master sogar intervenieren. Spätestens immer dann, wenn das Team einfach kein Scrum mehr macht – bei aller Liebe zur Selbstorganisation.

“A line must be drawn here”, um mal Jean-Luc Picard, einen der größten Servant Leader aller Zukünfte zu zitieren ...

#Daily #Scrum #ScrumMaster

Scrum – Framework vs. Pattern

Ich bin heute über einen Blogpost von Bob Galen gestolpert, der den Shift weg von “Frameworks” (wie Scrum), hin zu “Patterns” (wie unFIX oder Holocracy) propagiert. Er reiht sich ein in den lauten Abgesang an Scrum und den Einsatz von ScrumMaster:innen – und ich habe damit ein Problem: ich verstehe diese Diskussion nicht.

Sie klingt akademisch, hilflos (wie so manche Marketing-Sau, die wir durchs Dorf haben reiten sehen) und tief selbstreferenziell.

Eines kann ich zur Diskussion aber beisteuern, wenn ich darf (und vielleicht erklärt mir ja jemand von euch, wozu diese Diskussionen gut sind ;)):

Ich habe den Effekt erlebt, wenn Scrum Master in agilen Teams fehlen, womöglich über längere Zeit. Das ist wie mit jedem gepflegten und gehegten Sociotop; man merkt es anfangs nicht, aber nach sechs Monaten gerät fast alles aus den Fugen – und dann wirds anstrengend. Wie eine Farm, auf der die Farmerin fehlt.
Grundsätzliche Eigenschaften von agilen Teams, wie das “Pull-Prinzip”, die Selbstorganisation, das Delegieren von Macht top-down und das regelmäßige “Inspect and Adapt” bleiben wichtig und finden sich in jedem Konstrukt, ob nun Pattern oder nicht ;)

#Scrum #Framework #ScrumMaster

Re: Scrum Metrics

Meine Lieblingsmetriken als Scrum Master sind von Kanban ausgeliehen ;)

Ich habe bspw. gute Erfahrungen damit gemacht, Metriken von anderen Frameworks in Scrum zu integrieren. So sagt bspw. die “Cycle Time” von Aufgaben manchmal mehr über Schwierigkeiten aus, als Zuckungen der “Velocity” des Teams.

Die “Cycle Time” bezeichnet die Zeit, die ein Issue braucht, um von einem Status in den anderen zu gelangen (oder von 2do zu done, je nach Betrachtung). In Jira gibt es einen Standard-Report, der das zeigt: das Control Chart.

Eine Analyse der Issues, die bspw. im Testing feststecken oder Issues, die Sprint-über-Sprint in der To-do-Spalte Moos ansetzen, kann sehr hilfreich sein.

Teams in Retros Muster erkennen zu lassen und gemeinsam zu besprechen, zählt zu den effektivsten Tools, die ich kenne.

#Scrum #Kanban #Jira #Metriken #Velocity

Scrum vs. Kanban – welches agile Framework ist besser?

Ein umfassender Vergleich agiler Projektmethoden

In der heutigen Geschäftswelt sind agile Methoden wie Scrum und Kanban unverzichtbar, um Projekte effizient und flexibel zu managen. Beide Frameworks haben ihre Stärken und eignen sich für unterschiedliche Projektszenarien. Dieser Artikel beleuchtet die Einsatzbereiche, Vorteile und Unterschiede von Scrum und Kanban, um Ihnen bei der Auswahl des optimalen Frameworks für Ihr Projekt zu helfen.

Was ist Scrum?

Wie kann ich die Akzeptanz und Relevanz von Scrum Events, wie Planning, Review, Daily und Retro steigern?

Eine Übung, die mir sehr gut gefällt, kann nebenbei auch Scrum Events aufwerten:

Bündle Aufgaben und Arbeit in Scrum Events – verschlanke Kalender

Nimm dir in einer Retrospektive die Kalender Deines Scrum Teams vor und übe, Meetings und deren Inhalte, statt in seperaten Terminen abzuhandeln einem Scrum Event (Review, Planning, Retro) zuzuordnen.

Das erhöht die Akzeptanz der Scrum Events und verschlankt die Kalender. So ganz nebenbei zahlt es auch noch auf das Scrum Value “Focus” ein ;)

#Scrum #ScrumEvents #ScrumTeam

Wann ist mein Unternehmen bereit für Scrum?

Stolperte gerade über die Frage bei Linkedin: “How can you tell if your organization is ready for Scrum adoption?” – und antwortete inspiriert durch Jan Fischbach:

Oder: Wann sollte ich Scrum ernsthaft in Betracht ziehen?

Wenn eines dieser Probleme in Ihrem Unternehmen auftritt, sollten Sie den agilen Weg einschlagen: 1. Unser Unternehmen versteht die Kundenwünsche nicht. 2. Fehler werden zu spät im Entwicklungsprozess gefunden. (Womöglich regelmäßig vom Kunden) 3. Das Management mischt sich in die operative Arbeit ein. 4. Zu viele Projekte zur gleichen Zeit. 5. Die Mitarbeiter brennen aus. 6. Schlechte Kommunikation.

(“Fun Fact”: dies ist eine Liste der wichtigsten Probleme des Produktmanagements aus dem Jahr 1996)

Mein collab dazu auf LinkedIn 📑 https://lnkd.in/e_GA2Kzr

#Scrum #Unternehmen #Management #Agile