Software-Engineering Pattern und 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 →

Digitalisierung: Wo entstehen die Kosten

Inhalt: Warum sind Digitalisierungsprojekte so teuer?Wo fließt das Geld hin?Wie können Kosten vermieden werden?Ramp-UpUmsetzungBetriebFazitQuellen Die Kosten für die Entwicklungen digitaler Produkte im Zuge von Digitalisierungsprojekten können sehr stark schwanken. Von einigen tausend Euro für die Integration und das Customizing von digitalen Produkten, bis hin zu einigen hunderttausend (>100.000€) Euro für die individuelle Entwicklung von digitalen... Weiterlesen →

Software-Engineering Pattern und 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 Pattern und 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 Pattern und Antipattern: Review-Antipattern (Teil 1)

Inhalt: Kein ReviewRoadshow - Kein Feedback sammelnTicket AccountingProduct-Owner Ego ReviewAbnahmeveranstaltung vom Product-OwnerDer unnahbare Product-OwnerPräsentationismus oder das ungesehene Produkt 1 Kein Review Beschreibung des Antipatterns: Es wird kein Sprint-Review abgehalten.Der Product-Owner und die Stakeholder können sich selbst das Release ansehen, wenn es denn eines gibt, denn oft wird auch kein Release gemacht, weil der Sprint eher... Weiterlesen →

Roadmaps – Die meisten machen sie falsch.

In den vielen Jahren meiner IT-Karriere musst ich leider viel zu oft Produktentwicklungen beobachten, die scheiterten. Sie scheitern nicht aus technischen Gründen, oder weil das Umsetzungsteam schlechte Arbeit leistete. Das Problem war also nicht in der technischen Hemisphäre der Projektwelt zu finden, sondern auf der anderen Seite, in der Organisation und dem Mindset der Entscheider.... Weiterlesen →

Der Lean-Productmanagement-Zyklus – 6. Testen der Experimente/des Minimal Viable Products mit dem Kunden

Dieser Artikel beschäftigt sich mit dem 6. Schritt des Lean-Productmanagement-Zyklus. Einen Überblick über den Lean-Productmanagement-Zyklus finden Sie hier. 6. Testen der Experimente/des Minimal Viable Products mit dem Kunden Der 6. Schritt widmet sich nun dem eigentlichen Testen der im Schritt 5 erstellten MVP-Kandidaten. Schritt 6 und Schritt 5 hängen somit sehr eng zusammen, und müssen... Weiterlesen →

Der Lean-Productmanagement-Zyklus – 5. Erstellen der Experimente/des Minimal Viable Products

Dieser Artikel beschäftigt sich mit dem 5. Schritt des Lean-Productmanagement-Zyklus. Einen Überblick über den Lean-Productmanagement-Zyklus finden Sie hier. 5. Erstellen der Experimente/des Minimal Viable Products Bis zum vierten Schritt sind die Hypothesen aus dem Problembereich mehr und mehr verfeinert worden und im vierten Schritt dann noch um Annahmen und Ideen des Teams im Lösungsbereich überführt... Weiterlesen →

Create a website or blog at WordPress.com

Nach oben ↑