Die sieben größten Kostentreiber in der Softwareentwicklung.

Softwareentwicklung und die Entwicklung digitaler Produkte können und sollten als Investment betrachtet werden. Ein Investment, welches sich am Ende des Tages auszahlen muss. Und dabei spielt es keine Rolle, ob das Produkt für einen internen „Kunden“, also eine andere Fachabteilung gebaut wird oder für einen echten Kunden außerhalb des Unternehmens. Software-Produkte haben immer den Sinn,… Weiterlesen →

Software-Engineering Pattern und Antipattern: Review-Antipattern (Teil 3)

Inhalt: Unfertige Features präsentieren Technische 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… Weiterlesen →

Software-Engineering Pattern und Antipattern: Refinement Antipattern

Inhalt: Nicht genügend Refinement Zu viel Refinement Zu detailliertes Refinement Keine Berücksichtigung der DoR Keine Vorbereitung durch PO Nicht alle Teammitglieder nehmen Teil Kein gemeinsames Verständnis Der 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… Weiterlesen →

Software-Engineering Pattern und Antipattern: Retrospektive Antipattern (Teil 2)

Inhalt Product-Owner nicht erwünscht Zeitschleifen Retrospektive Routine Retrospektive Anwesenheitspflicht Retrospektive nach Planning Kein 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… Weiterlesen →

Software-Engineering Pattern und Antipattern: Retrospektive Antipattern (Teil 1)

Inhalt: Keine Retrospektive benötigt Retrospektiven bringen nichts Auf die nächste Retrospektive verschieben Retrospektive die entbehrliche Pufferzeit Übereilte Retrospektive Gebrochene Las Vegas Regel Das Team in der Opferrolle Action-Items sind nicht SMART Keine Verantwortlichen und keine Verbindlichkeit Kein Abschließen von Action-Items 1. Keine Retrospektive benötigt Beschreibung des Antipatterns: Das Team hält keine Retrospektive ab, weil es… Weiterlesen →

Software-Engineering Pattern und Antipattern: Review-Antipattern (Teil 2)

Inhalt: Immer die selben Gesichter Faken oder Cheaten Review Sprint-Gate Fehlende Stakeholder im Review Fehlende Kunden im Review Wechselnde Stakeholder Passive Stakeholder im Review 1 Immer die selben Gesichter Beschreibung des Antipatterns: Beim Sprint-Review sind nicht alle Teammitglieder anwesend. Einige fehlen immer oder sind nur sporadisch anwesend. In Präsentationen oder Diskussionen halten sich einige Teammitglieder… Weiterlesen →

Software-Engineering Pattern und Antipattern: Review-Antipattern (Teil 1)

Inhalt: Kein Review Roadshow – Kein Feedback sammeln Ticket Accounting Product-Owner Ego Review Abnahmeveranstaltung vom Product-Owner Der unnahbare Product-Owner Prä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… Weiterlesen →

Software-Engineering Pattern und Antipattern: Sprint-Antipattern (Teil 3)

Inhalt Feature-Injection Keine Remaining-Work/ Kein Burndown-Chart Zu viele Meetings Hardening Sprints Das falsche Feature bekommen Keinen Antrieb Der Neue Variable Sprintlänge Variable Teilzeit Teammitglieder 1 Feature-Injection Beschreibung des Anitpatterns: Jemand fügt, ohne dies zuvor mit dem Team zu besprechen, ein neues Feature ins Sprintbacklog hinzu. Der Sprintscope erhöht sich dadurch, ohne dass dies dem Umsetzungsteam… Weiterlesen →

Software-Engineering Pattern und Antipattern: Sprint-Antipattern (Teil 2)

Inhalt: Kein Work-In-Progress Limit Cherry-Picking Nicht aktuelle Sprint-Boards Side-Gigs Goldplating Laufende Arbeitsunterbrechungen Fehlende Unterstützung Task-Assignments 1 Kein Work-In-Progress Limit Beschreibung des Antipatterns: Das Entwicklungsteam setzt kein Work-In-Progress-Limit und öffnet mehrere größere Features gleichzeitig. Warum ist das schlecht? Arbeitet das Team an zu vielen PBIs gleichzeitig im Sprint, besteht die Gefahr, dass am Sprintende keine oder… Weiterlesen →

Create a website or blog at WordPress.com

Nach oben ↑