Wie man die sieben Arten der Verschwendung (Muda) im Agile RE/BA vermeiden kann


SwissQ,

Wir haben kürzlich über die sieben Arten der Verschwendung (Muda) im Agile RE/BA diskutiert. In diesem Beitrag möchte ich einige rasch umsetzbare Tipps vermitteln, wie man Muda vermeiden kann.

Die sieben Arten der Verschwendung (Muda) sind rasch und oftmals unabsichtlich und mit eigentlich gutem Ansatz „geschaffen“, so auch mein letzter Blog-Beitrag. Die Bewusstwerdung ist der erste Schritt, um Verschwendung nachhaltig zu bekämpfen. Der zweite Schritt ist, mit kleinen Massnahmen (quick wins) Verschwendung vorzubeugen.

Gewiss kann man nicht alle Verschwendungen sofort und unmittelbar eliminieren. Manche sind strukturell bedingt. Andere hingegen kann aber ein „einsamer“ Agile RE/BA mit ein wenig Selbstdisziplin minimieren. Zu jeder Verschwendungsart liefere ich also effektive Praxistipps und Akzeptanzkriterien, damit du deine Umsetzung nachher prüfen kannst.

Überproduktion

Praxistipps

Du befragst deine Abnehmer, also die nachgelagerten Stellen innerhalb des Sprints (wie z.B. Entwicklung, Testing), was sie wirklich für ihre tägliche Arbeit von dir benötigen. Fordern deine Entwickler und Tester lediglich BDD Szenarien, dann liefere auch nur solche und keine weiteren Artefakte.

Hier kannst du als klassischer RE dich herantasten und die Bedürfnisse/Anforderungen deiner Kunden strukturiert ermitteln, dokumentieren, prüfen und abstimmen – und natürlich priorisieren.

Akzeptanzkriterien

  • Priorisierte, geprüfte und abgestimmte Liste der Bedürfnisse/Anforderungen deiner Kunden
  • Pilot/Test mit dem ersten (toppriorisierten) Bedürfnis

Zu hohe Lagerbestände

Praxistipps

Du limitierst selber, wie viel Backlog Items du lagern möchtest. Du installierst einen schlanken Kanban-Prozess, der die Spezifikation der Backlog Items unterstützt, welche für einen kommenden Sprint priorisiert sind (Backlog Grooming und Magic).

Du sensibilisierst deinen PO, dass du als Agile RE/BA die Lieferkette überblicken musst. Er solle dich jederzeit informieren, wenn sich die Prioritäten verändern oder verschieben.

Akzeptanzkriterien

  • Definierte und kommunizierte WIP-Limite für Sprintvorbereitungsprozess
  • Kanban-Board implementiert

Unnötige Transporte

Praxistipps

Du zentralisierst die Entscheidungen und Diskussionen deiner wichtigsten Stakeholder auf einer interaktiven Kollaborationslösung. Deine Stakeholder sollen nur entscheiden und diskutieren, was dort notiert ist.

Du moderierst solche periodischen Sitzungen. Allerdings sorgst du dafür, dass immer die richtigen Stakeholder teilnehmen und auch stets fokussiert sind. Die Periodizität ist durch den Projekttakt bestimmt und kann variieren.

Akzeptanzkriterien

  • Liste der offenen Punkte sind für alle zugänglich
  • Stakeholder identifiziert

Wartezeit/Liegezeit

Praxistipps

Ideen/Varianten testest du möglichst rasch. Vergeude keine Minute, über eine Entscheidung zu grübeln, welche du nicht mit Tatsachen belegen kannst.

Schaffe Tatsachen, indem du Ideen/Varianten als Prototyp implementierst oder implementieren lässt. Damit verkleinerst du Wartezeiten. Zwar erhöhst du damit das Risiko, dass du scheiterst – aber lieber früh scheitern als zu spät.

Akzeptanzkriterien

  • Lösungsvarianten werden als Architektur-Spike in einem Sprint erfasst und umgesetzt

Reparaturen/Fehler

Praxistipps

Du rettest nicht die Welt, sondern machst ein System lauffähig. Also beginnst du mit dem einfachsten Geschäftsfall. Du antizipierst keine möglichen Verbesserungen einer fernen Zukunft – und auch und vor allem keine Sonderfälle. Du fokussierst dich auf einen simplen, überschaubaren Geschäftsfall, der sofort Mehrwert schafft.

Je kleiner die Komplexität, je kleiner die Wahrscheinlichkeit, dass du etwas übersehen hast. Damit reduzierst du Kosten, um deine Fehler nachträglich zu korrigieren.

Akzeptanzkriterien

  • Deine Geschäftsfälle sind vereinfacht und sind dementsprechend im Backlog geordnet
  • Der einfachste Geschäftsfall ist hoch priorisiert, die seltenen und komplexen Geschäftsfälle sind tief priorisiert

Wegezeiten/Unnötige Bewegungen

Praxistipps

Du spezifizierst deine Backlog Items einheitlich. Verwirre deine Stakeholder nicht mit neuen Diagrammtypen, die du in einem Product Management Blog überflogen hast.

Wenn du Diagramme verwendest, musst du garantieren können, dass deine Diagramme auch verstanden werden. Hast du die richtige Zielgruppe angepeilt? Wie viel musst und darfst du abstrahieren?

Versuche aber auch hier, nicht die komplette Welt zu modellieren, sondern nur so viel wie erforderlich ist, damit Entwickler und Tester dein Backlog Item ohne unnötigen Bewegungen umsetzen können.

Akzeptanzkriterien

  • Deine Backlog Items sind einheitlich und zweckmässig modelliert
  • Deine Zielgruppe versteht und befürwortet deine Diagramme

Flächen

Praxistipps

Gewiss liebäugelst du mit einer ausgereiften PLM-Lösung, wo du in 3D-Modellen navigieren und deine Anforderungen in vernetzten Produktlinien verwalten kannst. Auch weisst du, wie man den JIRA Workflow noch näher an den echten Prozess rücken könnte.

Dafür bist du aber nicht beauftragt. Tools lenken ab, zerstreuen einen. Du als Agile RE/BA musst stets den Mehrwert anzielen – und im Zweifel rezitierst du das Kredo:

Mehrwert ohne komplex-komplizierte Tools

Also lebst du vor, wie man auch ohne klassische Tools lauffähige Software produzieren kann. Du kommunizierst und präsentierst deine Anforderungen so, dass sie deine Entwickler und Tester verstehen – und eben im Zweifel mit Papier und Stift.

Akzeptanzkriterien

  • Alle für Entwicklung und Testing notwendigen Informationen sind in den Backlog Items zentralisiert
  • Die Backlog Items werden in einem Werkzeug verwaltet

Was bleibt übrig?

Gewiss kann man Lean Philosophien nicht unbedarft dem agilen Softwareentwicklungsvorgehen aufstülpen. In meinem Blog-Beitrag über Mediokrität habe ich denn auch dargelegt, dass die IT-Industrialisierungsneurose Mittelmässigkeit bewirke und sich mit überbordenden IT-Prozessframeworks verwirkliche. Im Kontext eines Agile RE/BA will ich mit Lean Philosophien demonstrieren, wie man rasch und einfach Komplexität aus dem System nimmt. Denn Projekte scheitern nicht bloss, weil sie kein oder mangelhaftes RE haben, sondern zuweilen auch, weil sie zu viel RE haben. Wir von der SwissQ wissen, wie man RE/BA – auch im Kontext der Agilität – wirkungsvoll und gezielt einsetzen kann.

Welche Praxistipps nutzen Sie, um möglichst wenig Verschwendung in ihren agilen Projekten zu produzieren? Teilen Sie ihre Erfahrungen mit uns, gerne auch am kommenden Agile Leadership Day.

Weitere Blogs über Agile RE/BA

Beratung anfragen

0 thoughts on “Wie man die sieben Arten der Verschwendung (Muda) im Agile RE/BA vermeiden kann”


Schreibe einen Kommentar