#BeyondScrum – #LeanEnterprise oder wie #Scrum das #Research & #Development verändern kann


Die Einfachheit als auch die Effizienz von Scrum hatte mich inspiriert in einem isolierten Team den Research- und Development Prozess (R&D) anzupassen. Gerne teile ich mit Euch meine Idee und erste Erfahrungen aus der Initierung und ersten Sprints. 
In vielen kleinen und mittleren Unternehmen besteht kein eigentliches R&D Departement. Die Mitarbeiter sind mit Delivery- oder mit Maintenance Aufgaben ausgelastet und eilen von Sprint zu Sprint. Neues anzugehen ist schwierig zu planen und wenn einmal Leerzeiten auftreten, bspw. zwischen Projekten oder aber auch in Projekten selbst, fällt es den Verantwortlichen schwer diese sinnvoll auszufüllen. Auch ist irgendwie jedermann und niemand verantwortlich für R&D und somit läuft dies heutzutage meist sehr unstrukturiert ab.
Inspiriert von Scrum lag die Lösung für mich auf der Hand, den R&D Prozess mittels einem nebenläufigen R&D Prozess abzulösen. Idee ist parallel zum Delivery Stream ein weiteren R&D Stream aufzusetzen, welcher aber über eine etwas längere Laufzeit aufweist. Nun werden periodisch in einem R&D Produkt Backlog zusammen mit dem Management, den Line Managern aber auch den Mitarbeitern Themen erfasst und priorisiert. Ist der R&D Sprint einmal gestartet und geplant kann sich nun jeder bei Leerzeiten, je nach seiner persönlichen Präferenz, aus dem R&D Sprint Backlog bedienen. Einzige Bedingung ist, die gewonnenen Erkenntnisse zu dokumentieren und im Sprint Review Meeting allen vorzustellen.
3466df87fb89d32b308c22110b80c986
Vorteile des R&D Streams mittels Scrum sind:
  • R&D ist in der Verantwortung von allen und jeder kann Inputs einbringen (Top down & Bottom up)
  • Leerzeiten werden sinnvoll genutzt, d.h. generieren sogar noch erwiesen Business Value
  • R&D ist instutionalisiert und steht nicht im Konflikt mit Delivery

Vom Management, aber auch seitens Mitarbeiter wurde dieser Prozess sehr gut aufgenommen und die Erfahrungen sind bisher durchwegs positiv. Einerseits sind sich die Mitarbeit die Selbstorganisation gewohnt und können sich somit auch mit Themen befassen die sie persönlich interessieren. Andererseits können die Mitarbeiter so aktiv auch die Unternehmensstrategie beeinflussen und neue Inputs einbringen, ohne das Delivery zu vernachlässigen. Gleichzeitig profitieren durch die konsequente Dokumentation und Präsentation der Erkenntnisse auch die anderen Mitarbeiter und somit letztlich auch das Unternehmen.

Mirko Kleiner is a Blogger, Agilist (Agile Evangelist), Vice President Delivery at youngculture AG, Twitterer, Father of 2 beautyful Sons and Partner of a lovely Wife.

Tagged with: , , , , , , , , ,
Veröffentlicht in field experience, scrum
6 comments on “#BeyondScrum – #LeanEnterprise oder wie #Scrum das #Research & #Development verändern kann
  1. Hans-Peter Korn sagt:

    Mit solchen „nebenläufigen“ Arbeiten, auch wenn sie im Team geplant und in einer Art Taskboard sichtbar verfolgt werden, habe ich keine guten Erfahrungen gemacht. „Leerzeiten“ gibt es in einem a la Scrum arbeitenden IMHO praktisch keine – sondern eher ein „von Sprint zu Sprint Gehetze“. Sogar im sprint eingeplante „Gold Cards“ (pro Teammitglied und Woche 1/2 Tag für „das was Spass macht“) werden kaum genutzt.
    Gut funktioniert allerdings eine Vereinbarung, dass ein bestimmter Halbtag pro Woche für ALLE im Team / in allen Teams für Innovationen nach freiem Ermessen zur Verfügung steht.In diese Richtung heht auch der „Hardening – INNOVATION – Planning – Sprint“, siehe http://scaledagileframework.com/hardening-innovation-planning/

    • mirkokleiner sagt:

      Hallo Hans-Peter

      besten Dank für Deinen Input. Auch ich habe so meine “Erfahrungen” gemacht mit nebenläufigen Prozesses, sowie auch mit den “Gold Cards” und “Joker Tag” à la Google..:-)

      Meine Quintessenz ist, dass wenn es im Projekt heiss zu und her geht auch ein Jokertag drauf geht. Das gute daran ist, meiner Meinung nach, dass dem Mitarbeiter ein fixes Zeitbudget gewährt wird.

      Was ich mit meinem Ansatz verbessern wollte ist folgendes. Themen/Epics werden gemeinsam definiert, sodass ein maximaler business Nutzen sowohl für das Unternehmen, als auch den/die Mitarbeiter erzielt werden kann. Es ist also nicht nur am Mitarbeiter zuerst zu überlegen über was er denn nun einen Research durchführen könnte. Zudem ist vor allem im Projektgeschäft mit Leerzeiten umzugehen. In der Theorie gibts diese nicht beim Einsatz von Scrum, da gebe ich Dir recht. In der Praxis können diese sehr wohl vorkommen, bspw. zwischen 2 Projekten (letztes grade zu Ende/Neues noch nicht gestartet). Oder aber vom ursprünglichen Scrum Team wird ein Mitarbeiter weniger benötigt im neuen Projekt, etc.
      Mit diesem Ansatz können sich die Mitarbeiter genau zum Zeitpunkt der Arbeitslücke selbstständig aus dem R&D Sprint Backlog bedienen. D.h. es geht keine Zeit verloren für die Themendefinition. Idealer Weise stellt das Unternehmen zusätzlich noch ein Zeitbudget pro Mitarbeiter zur Verfügung, sodass R&D auch bei Vollauslastung gewährleistet werden kann.

      Beste Grüsse
      Mirko

      • Hans-Peter Korn sagt:

        Dass die Themen/Epics gemeinsam definiert werden, macht sicher einen wesentlichen Unterschied. Wichtig IMHO auch, dass weder der PO noch irgend jemand aus dem „Management“ bei der Definition mitwirkt sondern es dem Team überlässt. Dafür aber die Ergbnisse fortlaufend wertschätzend verfolgt – und dafür sorgt, dass immer wieder welche auch umgesetzt werden.
        Die Leerzeiten zwischen „Projekten“ nutzen zu können ergibt sich aber nur dann, wenn die Teams für temporäre Projekte arbeiten und nicht für die kontinuierliche Neu- und Weiterentwicklung von Produkten – was ja die eigentliche Intention bei „agil“ ist – siehe https://www.xing.com/net/pri313a31x/agile-at-large/andere-diskussionen-und-fragen-zu-agile-large-761131/agil-passt-nicht-zum-management-von-projekten-und-programmen-sondern-zum-gesamten-leben-von-produkten-44263868/44263868/#44263868
        Und bei der projektbasierten Arbeit werden ja sehr oft temporäre Projektteams zusammnengestellt und danach wieder aufgelöst. Die Leute sind dann – jedoch „vereinzelt“ – wieder auf „Warteposition“ in ihren Stammabteilungen oder werden „als kurzfristig verfügbare Ressourcen“ anderen Teams „zugeordnet“.
        „Leerzeiten“ gibt es dann bestenfalls nur auf der „Warteposition“, dort aber nicht im (bisherigen) Team.

        Vor diesem Hintergrund bevorzuge ich längerfristig stabile „Produkt-/ Service-Teams“ gemäss „Teams optimal strukturieren und organisieren“ in
        http://www.symposion.de/kapitel40600101_WERK0003442.html
        Dort aber gibt es keine „Leerzeiten“. Zeit für Innovation muss dann also ganz bewusst – wie überall sonst in einem Unternehmen – eingeplant und konsequent „geschützt“ werden. DAS zu schützen wäre übrigens eine wichtige Aufgabe des „Managements“.

      • mirkokleiner sagt:

        Das Konzept sieht vor, dass sowohl das Management, das Business, die Linemanager, …, als auch die Mitarbeiter beim R&D Backlog Definition als „normale“ Team Mitglieder agieren. So können alle Vorschläge einbringen die gemeinsam geplant und priorisiert werden. Eine Unterteilung pro Business Unit/Technologie/o.ä. kann dabei Sinn machen um die Teamgrösse einzuschränken.

        Bei youngculture setzen wir auch auf Stabilität in den Teams. Dies geht besonders gut bei dedizierten Produkt-/Projekt-/Maintenance Teams. Daneben gibt es aber auch den Markt der zeitlich beschränkten Projekte mit immer neuen Kunden. Auch dort setzen wir auf bewährte Deliveryteams in immer derselben Zusammensetzung. Bin also auch hier absolut bei Dir.

        Abschliessend möchte ich drauf hinweisen, dass der Ansatz „R&D Backlog“ beyond SCRUM also für jede Unternehmung auch ausserhalb von Software Entwicklung gedacht ist.

      • Hans-Peter Korn sagt:

        Wenn du schreibst:
        > Das Konzept sieht vor, dass sowohl das Management, das Business, die Linemanager, …, als auch die Mitarbeiter beim R&D Backlog Definition als “normale” Team Mitglieder agieren. <
        meinst du mit "Team" dann das jeweilige Produkt-/Projekt-/Maintenance Team – oder ist das ein alle übergreifendes "Superteam"?

      • mirkokleiner sagt:

        du must dich gedanklich vom klassischen scrum team lösen. das r&d team ist auf ebene linienorganisation

        gruss mirko

Schreibe einen Kommentar

Trage deine Daten unten ein oder klicke ein Icon um dich einzuloggen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s

mirkokleiner

mirkokleiner

Mirko Kleiner is a Blogger, Agilist (Agile Evangelist), Vice President Delivery at youngculture AG, Twitterer, Father of 2 beautyful Sons and Partner of a lovely Wife.

Verifizierte Dienste

Vollständiges Profil anzeigen →

  • When you blame others you give up your power to change. Take responsibility for your future! - Chris Voss #quote 9 hours ago
  • Let us never negotiate out of fear. But let us never fear to negotiate. - John F. Kennedy #quote 12 hours ago
  • Success is the result of good judgement, which is the result of experience, experience is often the result of bad judgement. - Tony Robbins 1 day ago
  • RT @BillGates: Anybody can learn to code. And everyone should give it a try: b-gat.es/2h3cAzd #HourOfCode 1 day ago
  • Do what you can, with what you have, where you are. - Theodore Roosevelt #quote 1 day ago
%d Bloggern gefällt das: