Cash, Stakeholder, Value – die drei Dimensionen des Business Values

Erstellt am 12 September 2017
von 1 Komment
Business Value hat 3 Dimentionen: Cash, Stakeholder und Value

Business Value – 3 Dimensionen

Zur Einschätzung des Business Values einzelner Produktfeatures oder User Stories hilft die Erkenntnis, dass Business Value immer durch Zusammenwirken der Dimensionen Cash, Stakeholder und Value entsteht.

Guter Kunde, schlechter Kunde – Product Owners Glück und Leid in agilen Zeiten

Erstellt am 10 Mai 2016
von Schreibe einen Kommentar

Das richtige Paradigma

b_01Wenn wir nur so gut Software und Systeme wie Häuser bauen könnten. Nein, wie ein gut gepflegter Garten- so sollten wir entwickeln. Halt, unsere Systeme sollen schon wachsen, aber die sollen auch gleich verkaufbar sein, also einen Wert stiften. Also besser, erst einmal einen Roller entwickeln, dann ein Motorrad und dann ein Auto. So sind doch erfolgreiche Produkte entstanden. Oder?

Gegen das „Nicht Verstehen“ – SCRUM richtig Agil machen

Erstellt am 4 November 2015
von Schreibe einen Kommentar

SCRUM ist beliebt und erfreut sich einer immer weiteren Verbreitung. Aber nicht für alle, die sich dieser Methodik annähern, scheint es ein „Silver Bullet“ zu sein. Neben den vielen erfolgreichen Projekten gibt es eine ganze Reihe von Firmen, die noch  keine erfolgreiche Entwicklung mittels SCRUM erreichen konnten. Solche Schwierigkeiten werden kaum an die große Glocke gehängt, aber wenn man im Netz sucht, dann stößt man auf agile Coaches, die auch schon mal Ihr Leid klagen:

Wer ist der Architecture Owner?

Erstellt am 13 Januar 2015
von Schreibe einen Kommentar

SuperheroWer vertritt die Architektur gegenüber dem Product Owner, der sich primär für den  Business Value interessiert?
Wer ist dieser „Superheld“, der die Verantwortung trägt – ein „Architecture Owner“?

Sind Product Owner Teams eine Alternative?

Erstellt am 6 Januar 2015
von Schreibe einen Kommentar

Kunde: Aktuell gibt es bei uns im Haus die Diskussion, ob statt einer Person auch eine Gruppe von Personen die Product Owner Rolle übernehmen könnte. Haben Sie eine Meinung dazu?

Wer bin ich – und wenn ja, wieviele? Requirements Engineers in der Sinnkrise…

Erstellt am 9 September 2014
von Schreibe einen Kommentar
This entry is part 1 of 1 in the series Casting für Product Owner

Und es trifft nicht nur die Requirements Engineers (REs), es trifft auch die Business Analysten (BAs), wie ich im Gespräch mit einer Teilnehmerin am Scrum Day erfuhr: „Unsere Entwicklung arbeitet jetzt mit Scrum – und ich weiß gar nicht mehr, was meine Aufgabe ist…“. Dabei ist das Arbeiten als RE/BA in einem Scrum Team herrlich. So vielfältige Aufgaben und Möglichkeiten, sich und sein Wissen einzubringen, habe ich bisher nur beim Arbeiten in einem agilen Team gehabt. Der Transfer der agilen Werte und Prinzipien auf das Requirements Engineering und die Rolle Requirements Engineer in einem agilen Umfeld ist eine Herausforderung für viele Menschen und Organisationen. Die heutigen Zertifizierungen am Markt zu Scrum/Agile und Requirements Engineering haben eines gemeinsam: Sie konzentrieren sich entweder auf das Thema Agilität/Scrum oder auf das Thema Requirements Engineering. Auch “Agile Extensions”, wie sie der BABoK oder das PMI veröffentlicht haben, ergänzen nur die agile Sichtweise, sie bieten keine übergreifende integrierte Sicht. Meine Erfahrung in der Arbeit mit agilen Teams und Organisationen auf dem Weg zu mehr Agilität zeigt jedoch, dass gerade die Verbindung beider Themen in der Praxis Schwierigkeiten macht. Die Transferleistung gelingt nicht oder nur schwer.

Die Qual der Wahl – das Konferenzprogramm der Manage Agile 2014 steht fest

Erstellt am 29 Juli 2014
von Schreibe einen Kommentar

manageagile_2014_quadrat_500pxWir Frauen sind es ja eigentlich gewöhnt aus einem überreichen Angebot auswählen zu müssen. Das geht morgens schon los mit der Frage „Was soll ich anziehen“, setzt sich in der Mittagspause fort mit der Entscheidung ob „Salat, Gemüse, oder doch das Schnitzel“ und (ja, ich bediene jetzt wirklich jedes Klischee) endet mit Verlustgefühlen oder Gewissensbissen nach dem Besuch im Schuhladen (je nach Anzahl der erworbenen Paar Schuhe). Und nein, Sie sind nicht aus Versehen auf dem Blog einer Frauenzeitschrift gelandet – gleich geht’s weiter mit agil.

Pecha Kucha: Der Scrumertinger

Erstellt am 19 Februar 2013
von Schreibe einen Kommentar

RE-Phänomene in agilen Projekten oder such den Scrumertinger! Im Rahmen der Pecha Kucha Night auf der OOP 2013 kommen wir diesem viel zu realen Wesen auf die Spur. Viel Vergnügen mit einer etwas anderen Vortragsform und Susanne Mühlbauer mit dem Beitrag: Scrumertinger: RE-Phänomene in agilen Projekten auf der OOP 2013.
Für mehr Informationen zum Thema Pecha Kucha siehe Wikipedia: Pecha Kucha.

Wirksame Gegenmittel gegen RE-Phänomene und Scrumertinger finden Sie auch in unseren Trainingsangeboten, zum Beispiel hier:

  • Gute User Stories – Workshop für Autoren
  • RE im agilen Umfeld

 

 

 

Story-Requirements – ein Gedankenspiel

Erstellt am 2 Oktober 2012
von Schreibe einen Kommentar

Spätestens seit sich die agile Softwareentwicklung als alltagstaugliche und in einigen Entwicklungsbereichen auch als alternative Vorgehensweise durchgesetzt hat, sind die User Stories fester Bestandteil der Entwicklung. Die Requirements sind aber als Entwicklungsartefakt nicht ausgestorben. So existieren in vielen Unternehmen beide Artefakte – User Story und Requirement – nebeneinander, quasi stellvertretend für die agile und die klassische Welt. Lassen Sie sich mit dem nun folgenden Gedankenspiel auf eine mögliche Verschmelzung dieser Artefakte ein.

Rollenkonflikte in agilen Umgebungen

Erstellt am 18 September 2012
von Schreibe einen Kommentar

Mit der Einführung von Scrum werden die Rollen Scrum Master, Product Owner und Entwicklungsteam neu eingeführt. Im Fokus dieses Beitrages steht der Product Owner. Der Product Owner ist verantwortlich für den Produkterfolg und für den Wert, den die Arbeit des Entwicklungsteams liefert (Scrum Guide). Der Product Owner tritt dem Entwicklungsteam als Kunde bzw. als Kundenstellvertreter (Kundenproxy) gegenüber. Er alleine entscheidet und verantwortet welche Anforderungen wann umgesetzt werden. Damit übernimmt er die Aufgaben des Anforderungsmanagers, des Produktmanagements, des Business Analysten oder des Projektleiter (entscheiden Sie bitte selbst, welche Rollen in Ihrem Unternehmen diese Aufgaben wahrnehmen). Die Anforderungen definiert der Product Owner selbst, gemeinsam mit dem Entwicklungsteam oder erhebt sie bei seinen Stakeholdern.