Heute habe ich ein gewagtes Versprechen an meine Produktleute: Mit nur einer einzigen Frage kommt ihr einen Schritt aus der Feature Factory heraus und rein ins Empowerment – und haltet dabei hartnäckige Stakeholder auf Abstand! Die Frage lautet: Welches Kundenproblem löst das? Gerne mit einem Nachsatz (in Habeckscher Anlehnung): Zeig mir dein Customer Problem Statement, Alter!
Autor: Helen Sedlmeier
Helen Sedlmeier ist seit 2018 an Board der Mayflower und betreut als Product Owner die Produktentwicklung für Start-ups.
Sie liebt es, zusammen mit einem Entwicklungsteam in die raue See der Greenfield-Produktentwicklung zu stechen.
Design the Product Box
Produktentwicklung ist ein Spiel mit vielen Variablen und Menschen – das macht sie spannend und herausfordernd. Kommunikation ist ein Schlüssel in diesem Spiel. Ein Tool, um Kommunikation und Menschen auf freundliche Weise zu verbinden, ist die Methodik „Design the Product Box“.
Warum das Management nicht allein über ein skaliertes agiles Framework entscheiden sollte
Unternehmen, die sich dazu entschließen, agile Software-Entwicklung zu skalieren, stehen vor der Herausforderung, sich für ein skaliertes agiles Framework zu entscheiden, dies anzupassen oder gar ein eigenes zu entwickeln. Da sich die Grundideen und Strukturen zwischen den skalierten agilen Frameworks zum Teil grundlegend unterscheiden, sollte die Entscheidung sorgsam getroffen werden. Deshalb möchte ich eine Empfehlung…
Scrum of Scrums
Neben Produktmanagement ist eines meiner Lieblingsthemen die agile Skalierung. Denn wie sollte man sonst umfangreichere Produkte auf die Beine stellen können? Zu agiler Skalierung habe ich bereits ein paar Artikel verfasst. Bei all den Skalierungsframeworks gibt es Eines, dass meiner Meinung nach zu wenig Aufmerksamkeit bekommt: Scrum of Scrums.
Team Topologies: Cognitive Load
In meiner aktuellen Serie beschäftige ich mich mit Team Topologies. In diesem Artikel erkläre ich, was Cognitive Load ist und welche Arten es gibt. Der Begriff Cognitive Load wurde durch Team Topologies geprägt und populär.
Team Topologies: Teamgrößen – Dunbars Number
In dem ersten Artikel der Serie habe ich erklärt, welche Teamtypen und Interaktionsmuster es in Team Topologies gibt. In diesem Artikel möchte ich auf die vorgeschlagenen Findings zu Teamgrößen eingehen.
Team Topologies: Platform-as-a-Product (Teil 1)
Team Topologies schlägt vor, Infrastruktur-Teams zu Plattform-Teams zu wandeln. Daraus ergibt sich ein Wandel hin zu Platform-as-a-Product. Dabei sind sich Matthew Skelton und Manuel Pais darüber im Klaren, dass dies mit Herausforderungen verbunden ist. Grund genug, dass wir uns ein wenig genauer damit beschäftigen!
Team Topologies: Product Ownership in den vier Team-Typen
Team Topologies ist in aller Munde. Aber was bedeutet Product Ownership in den vier Team-Typen, die Team Topologies kennt? Das möchte ich heute beleuchten. Am Ende des Artikels kennt ihr die vier Team-Typen und deren Interaktionsmuster aus Team Topologies und wisst, was das für Product Ownership bedeutet bzw. diese zum Einsatz kommt.
Die Kontingenztheorie – warum agile skalierte Frameworks angepasst werden müssen
Als Praktiker ist es einem völlig klar, dass skalierte agile Frameworks angepasst werden müssen. Wie man das jedoch theoriegeleitet begründet, möchte ich in diesem Artikel mithilfe der Kontingenztheorie aufzeigen. Die Kontingenztheorie ist eine Organisationstheorie. „Organisationstheoretische Ansätze dienen dem Zweck, die Ziele, die Entstehungsgeschichte, die Funktionsweise und den Wandel von Organisationen zu erklären und zu verstehen.“[1]