Viele Autoren machen gerne eine Abgrenzung zwischen Agile Coach und Scrum-Master. So wird im Social Media oder auf medium gerne definiert das Scrum-Master sich auf das Team fokussieren und Agile Coaches auf die Organisation und die agile Transformation.Ich möchte in diesem Artikel auf diese Argumentation eingehen und meine Sicht diese Themen hier klarlegen. Der Scrum-Master... Weiterlesen →
Projects vs. Products – Die Transformation von Projektentwicklung zur agilen Produktentwicklung.
Warum Manager Projektentwicklung gegenüber der agilen Produktentwicklung bevorzugen und warum sie dabei falsch liegen. Es gibt viele Arten wie sich Unternehmen organisieren. So vielseitig wie die Geschäftsmodelle dieser Unternehmen sind, so unterschiedlich sind auch deren Aufbauorganisationen und Prozesse. Viele Unternehmen lassen sich in eine von zwei Kategorien einteilen: Unternehmen mit ProjektentwicklungUnternehmen mit Produktentwicklung Je größter... Weiterlesen →
Bang for the Buck Score – Wie Story Points und Value Points helfen das Backlog zu priorisieren.
Ein Freund von mir, der ebenfalls als Scrum-Master tätig ist, hat mich vor kurzem gefragt wie er mit Story Points umgehen soll. Er möchte einem Team das er coachet, dabei helfen von einer Stundenschätzung und Planung basierend auf Stunden, zu einer Story Point basierten Schätzung und Planung zu kommen. Aus einer kurze Frage wurd sehr... Weiterlesen →
Das Cynefin-Framework in der Software-Entwicklung und Unternehmensentwicklung: Ein Werkzeug zur Entscheidungsfindung und viel mehr…
Das Cynefin Modell wurde im Jahr 2000 vom ehemaligen IBM Mitarbeiter und Berater Dave Snowden entwickelt. Cynefin (Ausgesprochen Kü-Ne-win) ist walisisch und bedeutet wörtlich übersetzt “ Das Cynefin Modell wurde im Jahr 2000 vom ehemaligen IBM Mitarbeiter und Berater Dave Snowden entwickelt. Cynefin (Ausgesprochen Kü-Ne-win) ist walisisch und bedeutet wörtlich übersetzt “Lebensraum”. Es beschreibt fünf... Weiterlesen →
Software-Engineering – agile Pattern und agile Antipattern: Review-Antipattern (Teil 3)
Inhalt: Unfertige Features präsentierenTechnische Schulden sammeln und verschweigen 1 Unfertige Features präsentieren Beschreibung des Antipatterns: Ein Teammitglied wird mit einem Ticket nicht fertig und präsentiert den aktuellen Entwicklungsstand den Stakeholdern und dem Product-Owner. Warum ist das schlecht? Werden den Stakeholdern unfertige Features präsentiert zeugt dies nicht von der Professionalität des Teams.Unfertige Features sind meist noch... Weiterlesen →
Software-Engineering – agile Pattern und agile Antipattern: Sprint Planning – Antipattern (Teil 2)
Inhalt Defintion of Ready GateSprintlänge an Plan anpassenErzwungener PlanSprintplanung by Lead DevBotschafter-Planning Sprint Planning - Antipattern 1. Defintion of Ready Gate Beschreibung des Antipatterns: Das Umsetzungsteam ist sehr unflexibel in der Sprintplanung, es lässt nur jene PBIs für die Planung zu, die zuvor das Refinement durchlaufen haben und bereits die Definition of Ready erfüllen.Alle PBIs,... Weiterlesen →
Software-Engineering – agile Pattern und agile Antipattern: Refinement Antipattern
Inhalt: Nicht genügend RefinementZu viel RefinementZu detailliertes RefinementKeine Berücksichtigung der DoRKeine Vorbereitung durch PONicht alle Teammitglieder nehmen TeilKein gemeinsames VerständnisDer Erzwungene Abschluss 1. Nicht genügend Refinement Beschreibung des Antipatterns: Das Team nimmt sich nicht genügend Zeit, einzelne Backlogitems zu refinen.Die Qualität der Backlogitems ist nicht ausreichend und das Team weis oft nicht, was zu tun... Weiterlesen →
Software-Engineering – agile Pattern und agile Antipattern: Retrospektive Antipattern (Teil 3)
Inhalt Keine DokumentationBlaming KulturIntrovertierte gehen unterVorgesetzte sind anwesendKontrolle der Retrospektiven DokumentationStakeholders in der RetrospektivePassive Teilnahme 1. Keine Dokumentation Beschreibung des Antipatterns: Niemand im Team schreibt in der Retrospektive mit und dokumentiert die Beschlüsse und Action-Items.Die Dokumentation wird als anstrengender lästiger Part gesehen, den niemand im Team machen möchte Warum ist das schlecht? Werden Beschlüsse, besprochene... Weiterlesen →
Software-Engineering – agile Pattern und agile Antipattern: Retrospektive Antipattern (Teil 2)
Inhalt Product-Owner nicht erwünschtZeitschleifen RetrospektiveRoutine RetrospektiveAnwesenheitspflichtRetrospektive nach PlanningKein passender Raum 1. Product-Owner nicht erwünscht Beschreibung des Antipatterns: Der Product-Owner ist in der Retrospektive nicht erwünscht und wird dezidiert nicht eingeladen bzw. ausgeladen.Das Team glaubt die Retrospektive ist ein Meeting, welches ausschließlich für das Umsetzungsteam da ist. Warum ist das schlecht? Der Product-Owner ist ein essenzieller... Weiterlesen →
Software-Engineering – agile Pattern und agile Antipattern: Retrospektive Antipattern (Teil 1)
Inhalt: Keine Retrospektive benötigtRetrospektiven bringen nichtsAuf die nächste Retrospektive verschiebenRetrospektive die entbehrliche PufferzeitÜbereilte RetrospektiveGebrochene Las Vegas RegelDas Team in der OpferrolleAction-Items sind nicht SMARTKeine Verantwortlichen und keine VerbindlichkeitKein Abschließen von Action-Items 1. Keine Retrospektive benötigt Beschreibung des Antipatterns: Das Team hält keine Retrospektive ab, weil es glaubt, es würde nichts zu besprechen geben. Warum ist... Weiterlesen →