IT visualisieren – ganz spontan
„Teilzeit-Scrum“ – sich aufteilen müssen zwischen der Arbeit im Scrum- oder gar Entwicklungsteam und anderen Arbeiten in der Organisation – ist m. E. eine der potentiell schädlichsten MeTooden, die aktuell en vogue sind. Zu dieser Einschätzung komme ich vor allem aus drei Gründen:
Situationsbedingt komme ich mit meiner Präferenz für physische, „haptische“ Kanban-Boards im Moment nicht weit; die pandemiebedingte Verbreitung von Home Office macht digitale Lösungen geradezu notwendig. Bei der nun vermehrten Auseinandersetzung mit Kanban-Software fällt auf: Praktisch jede Lösung am Markt offeriert zusätzlich zur Visualisierung des Arbeitsflusses am eigentlichen Kanban-Board eine Darstellung als Gantt-Diagramm und wirbt oftmals sogar damit – was für eine absurde, das Werkzeug seines Kerns entkleidende Methoden-Chimäre! … weiterlesen ...
Kaum eine Kanban-Einführung vergeht, ohne dass irgendwann Littles Gesetz erwähnt und als (meist die) Erklärung für die Sinnhaftigkeit von WIP-Limits herangezogen wird. Theoretisch mag dieser Ansatz richtig sein, praktisch erscheint er mir sehr wenig zielführend.
Die wenigsten Informatiker (und noch weniger Betriebswirtschaftler) werden das Thema „Warteschlangentheorie“ im Studium genossen haben – und mit einer hübschen Formel am Flipchart lässt sich auch nur beeindrucken, wenn sich der Trainer beim Erklären der beteiligten Variablen und Rahmenbedingungen nicht hoffnungslos verhaspelt. … weiterlesen ...
Vorgestern fand das 5. PMCamp Hamburg (#pmcamphh) statt – nicht in Hamburg, sondern im virtuellen Raum. An dieser Stelle möchte ich kurz meine Eindrücke vom Camp schildern, wirklich begeistert „Danke“ sagen und ganz nebenbei auch noch ein paar grundsätzliche Gedanken zu virtuellen BarCamps sammeln. … weiterlesen ...
„Bloß nicht noch ein Board!“ ist häufig die Reaktion meines jeweiligen Gegenübers, wenn ich die Einführung eines Kamishibai-Boards als Ergänzung zum vorhandenen Task- oder Kanban-Board vorschlage (vgl. hier). Das ist schade – nicht nur, weil ein Kamishibai (紙芝居) die sinnvolle Modellierung wiederkehrender Arbeit in einem Kanban-System ermöglicht, sondern auch, weil die beiden Boards und die dahinterstehenden Ideen, Prinzipien und Prozesse so nahtlos ineinandergreifen können, dass das Ergebnis nach kürzester Zeit gar nicht mehr wie „noch ein Board“ wirkt. … weiterlesen ...
Ich nehme die Menschen im IT-Infrastruktur-Bereich oftmals als in ihrer Arbeit hin- und hergerissen wenn nicht gar zerrissen wahr: Die meist fehlende klare Trennung von Betrieb und Projekt ist im Tagesgeschäft ein kaum auflösbarer Dauer-Konflikt und die Dringlichkeit des Betriebs gewinnt meist gegen die Wichtigkeit des Projekts – der Hauptgrund, warum mir Kanban als übergreifende Methode zur Steuerung dieser Arbeiten als empfehlenswert erscheint: Kanban ermöglicht nicht nur das Mischen von reaktiven Support-Tätigkeiten und Projektarbeit, sondern macht zudem den inhärenten Konflikt sicht- und damit handhabbar (vgl. … weiterlesen ...
„Wir machen jetzt [auch] Scrum.“ ist ein Satz, den (sicher nicht nur) ich in den letzten Jahren sehr häufig gehört habe – inzwischen auch außerhalb des Softwareentwicklungs-Bereichs im traditionell methodisch eher konservativen IT-Infrastruktur-Bereich. Praktisch erlebt man dabei Scrum häufig eher als MeToode (Antrieb: „Alle machen das!“) … weiterlesen ...
Tom DeMarco und Timothy Lister unterscheiden in ihrem m. E. nach wie vor lesenswerten Klassiker „Wien wartet auf Dich!“ (engl.: „Peopleware“) zwischen „Methodiken“ und „METHODIKEN“ – letztere sind im Gegensatz zu ersteren „[…] meist riesig und werden immer umfangreicher […]“, werden gern dogmatisch angewandt und als eine Art „Allheilmittel“ angesehen. … weiterlesen ...