Update-Bericht: Erprobung der „Shape Up“-Methodik von Basecamp

Letztes Jahr habe ich versucht, mein Produktteam vom klassischen SCRUM-Ansatz auf die Shape Up-Methodik von Basecamp umzustellen. Es war eine unglaubliche Erfahrung; Ich habe viel daraus gelernt und dachte, ich würde einige meiner Erkenntnisse mit Ihnen teilen.

Wenn Sie selbst damit experimentiert haben, würde ich gerne hören, wie es gelaufen ist. Wenn nicht, würde ich gerne hören, warum Sie weggeblieben sind.

Teil 1: Warum Shape Up?

Mein Team arbeitete schon seit Ewigkeiten mit SCRUM. Während unserer Startup-Zeit lebten wir die klassischen Technologiezyklen: schnell arbeiten, versenden und nicht zu viel über Prozesse nachdenken. Dann wurden wir übernommen.

Nachdem ich etwas mehr Zeit hatte, über unsere Produktmethodikoptionen nachzudenken, beschloss ich, Shape Up auszuprobieren. Es gab mehrere Gründe:

1. Bis dahin versuchten wir zweiwöchige Sprints und schafften es ziemlich oft nicht, sie zu Ende zu bringen. Jede Woche fühlte sich an wie ein Fließband voller Tickets, das wir nie ganz aufbrauchen würden.

   
   

2. Das Team fühlte sich wie Code-Affen. Ticket auswählen. Arbeitsticket. Ticket abgeben.

   
   

3. Da wir den Sprint nie beendet haben, gingen die Aufgaben immer auf den nächsten über. Schließlich bricht der Damm.

   
   

4. Es fehlte uns allen an Konzentration. Jeder Sprint bestand aus einer Auswahl von Dingen, an denen in der gesamten Codebasis gearbeitet werden sollte.

   
   

5. Sehr wenig Teamarbeit. Jeder Entwickler arbeitete an seinem kleinen Stück vom Kuchen und ließ wenig Raum, um voneinander zu lernen und, ehrlich gesagt, ein Gemeinschaftsgefühl zu entwickeln.

   
   

6. Fast kein Kundenverständnis. Entwickler würden zugewiesene Tickets abholen, sie erledigen und hätten keine Ahnung, warum/wer/was.

Nach erneutem Lesen Basecamps Shape Up , dachte ich, ich würde es mal versuchen, da es behauptete, die meisten dieser Probleme zu lösen.

Teil 2: Internes Pitchen

Einer der schwierigsten Aspekte beim Wechsel zu Shape Up war die interne Vermarktung der Idee.

Ich habe zusätzliche Zeit damit verbracht, die meisten Konzepte von Shape Up zu verinnerlichen, um sicherzustellen, dass ich auf alle Fragen vorbereitet bin. Es überrascht nicht, dass die Entwickler von der Idee dieses neuen Ansatzes begeistert waren (mehr Zeit, mehr Fokus, mehr Zusammenarbeit; warum auch nicht!).

Es überrascht auch nicht, dass die Hierarchie zurückhaltender war. Letztendlich gelang es mir, sie zu überzeugen, indem ich:

1. Sicherstellen, dass es nur ein Versuch war. Wenn es nicht klappte, kehrten wir zur „Normalität“ zurück.

   
   

2. Ich stellte sicher, dass ich so verfügbar wie eh und je war, um ihnen zu helfen. Die Entwickler würden konzentriert und ununterbrochen sein, ich jedoch nicht.

   
   

3. Durch die Hervorhebung von Shape Up können wir größere Probleme lösen, was größere Chancen bedeutet.

   
   

4. Das Beharren auf dem Schmerzprodukt erlebt derzeit und wie es sich auf jedes Team auswirkt.

Ich habe ein sehr übersichtliches Foliendeck erstellt und es jedem Abteilungsleiter (Kundendienst, Vertrieb und Führungsebene) vorgestellt.

Teil 3: Ängste und Sorgen

Meine Erfahrung als Gründer, Vermarkter und Produktmanager hat mich gelehrt, dass es sich immer lohnt, Bedenken aufzuschreiben, bevor man mit einem Experiment beginnt. Ich hatte ein paar mit Shape Up:

• Wie gehen wir mit Ablenkungen um? Ich weiß, dass ich „Nein“ sagen soll. 'Waren beschäftigt.' „Im nächsten Zyklus können wir uns das ansehen.“ Das ist die Theorie, und sie funktioniert, wenn das gesamte Unternehmen von dieser Methodik überzeugt ist. Während meines ersten Fahrradversuchs hatte ich Angst, dass ein Notfall eintreten würde.

• Rückstände? Shape Up empfiehlt keine Rückstände (Kapitel 7). Da wir das gerade ausprobiert haben, habe ich natürlich nicht mit cmd+a+unseren Rückstand gelöscht, aber trotzdem. Wenn wir diese Methodik übernehmen würden, würde ich mich ohne Rückstand etwas verloren fühlen.

• 'Fast fertig.' Das hat mir wirklich Angst gemacht. Was passiert, wenn wir das Ende des 6-Wochen-Zyklus erreichen und zwar vorläufig, aber noch nicht ganz da sind? Basecamp sagt „Neu starten“ (es sei denn, Sie sind so nah dran). Ich hatte Angst, dass wir das Ziel um die lästigen 20-30 % verfehlen würden.

Letztlich konnte mich keine dieser Ängste/Bedenken davon abhalten, den Prozess fortzusetzen. Es lohnte sich jedoch, sie im Hinterkopf zu behalten.

Teil 4: Der Zyklus

Und los geht’s!

Ich startete den ersten Zyklus an einem Montagmorgen und blickte auf sechs Wochen intensiver Konzentration und Teamarbeit. Hier ist eine Zusammenfassung dessen, was jede Woche passiert ist:

• Woche 1 : Anpfiff und... Stille. Ein wichtiger Teil dieser Methodik besteht darin, das Team in Ruhe zu lassen, es recherchieren zu lassen und in Ruhe in den Code einzutauchen. Es fiel mir in dieser ersten Woche unglaublich schwer, loszulassen und nicht nach Updates zu fragen. Ich habe stark gehalten!

• Woche 2 : Das Team kam endlich aus seinem Schneckenhaus heraus. Die Kommunikation nahm Fahrt auf. Der Entwurf für die Arbeit erschien, ich musste Feedback geben und gemeinsam arbeiten.

• Woche 3 : Theoretisch sollte Woche 3 der Höhepunkt der Zykluskurve sein. Am Ende sollte das Team eine sehr gute Vorstellung davon haben, wie es das bauen will, was gebaut werden muss. Als die Kommunikation richtig in Schwung kam, haben wir einen zyklusspezifischen Slack-Kanal erstellt. Am Ende dieser Woche sahen wir Prototypen, Designs, Codeausschnitte und mehr. Wir waren auf dem richtigen Weg!

• Woche 4 : Wieder ruhig. Das ganze Hin und Her von Woche 3 führte zu einer konzentrierten Woche 4, in der jeder seine Arbeit umsetzte. Wir haben am Freitag ein „Show & Tell“ gestartet.

• Woche 5 : Curveball-Woche. Eines der Zielfernrohre begann, ziemlich viel Geschwätz zu erzeugen. Es wurde schnell klar, dass der Umfang nicht klar genug war. Ich hatte meine Anforderungen nicht präzise genug formuliert und was zunächst schön und einfach schien, entpuppte sich als komplex. Ich musste die schwere Entscheidung treffen, dieses Zielfernrohr zu reduzieren.

• Woche 6 : Die verbleibenden Bereiche liefen gut. Die Intensität nahm in Woche 6 drastisch zu, da ich überall Qualitätssicherungen durchführte und die Entwickler unglaublich schnell auf mein Feedback eingingen; Wir haben alle an einem Strang gezogen, um das Ziel zu erreichen.

  
  

Am Ende haben wir das Ziel erreicht. Wir haben es geschafft! Es war super intensiv und ich war am Boden zerstört, dass wir eines der Zielfernrohre abschneiden mussten, aber wir haben es geschafft.

Am darauffolgenden Montag um 10 Uhr gingen wir in die Produktion.

Teil 5: Ein paar Lektionen

Hier sind in keiner bestimmten Reihenfolge einige Lektionen und Empfehlungen:

1. Formen ist schwer . Ich dachte, ich hätte die meisten gruseligen Teile des Zyklus gut gestaltet. Es stellte sich heraus, dass ich etwas völlig Offensichtliches übersehen hatte, was den gesamten Zyklus fast zum Scheitern gebracht hätte.

   
   

2. Beziehen Sie Ihr Team in die Gestaltung mit ein . Ich habe es größtenteils alleine gestaltet und manchmal auch mit der Leitung meines Entwicklerteams. Es wäre für mich wertvoll gewesen, andere Entwickler einzubeziehen.

   
   

3. Wenn Sie mitten im Zyklus diskutieren oder gestalten, ist etwas schief gelaufen . Stoppen Sie alles. Ihre Priorität besteht darin, die Sache herauszufinden, bevor sie alles andere völlig zum Scheitern bringt.

   
   

4. Die Intensität ist nicht gleichmäßig verteilt . Ob zwischen Teammitgliedern oder im gesamten Zyklus, die Arbeitsintensität wird stark variieren. Als PM ist es Ihre Aufgabe, diese Intensitätsbereiche zu erkennen und den Personen, die sie durchlaufen, besondere Aufmerksamkeit zu widmen.

   
   

5. Erstellen Sie einen separaten Slack-Kanal . Es machte die Kommunikation viel einfacher, machte aber auch viel mehr Spaß. Das Fahrradteam entwickelte schnell eine gemeinsame Sprache, Memes zu der Arbeit, an der wir arbeiteten, und so weiter. Es fühlte sich im Grunde wie ein Startup innerhalb des Teams an.

   
   

6. Implementieren Sie Show & Tell-Meetings ab Woche 1 . Wir haben zu lange damit gewartet. Ab Ende der ersten Woche sollte es genug zu zeigen oder zu diskutieren geben. Es ist auch eine Gelegenheit, sich zu treffen, zu diskutieren, zu lernen usw.

   
   

7. Die Abklingzeit erwies sich als viel schwieriger als der Zyklus selbst . Die ganze „andere Arbeit“ hatte sich sechs Wochen lang angehäuft; Es fühlte sich an, als würde man direkt zu SCRUM zurückkehren. Das ist etwas, an dessen Verbesserung ich immer noch arbeite.

Wie Sie wahrscheinlich sehen können, hat mich dieser Versuch überzeugt.

Die Implementierung von Shape Up und die Übernahme seiner Eigenheiten geschieht sicherlich nicht über Nacht. Ich vermute, dass es ein langer Lernprozess sein wird. Ich schätze besonders die Veränderung unserer Denkweise, die uns dieser Prozess ermöglicht hat. Wir (und hoffentlich auch die anderen Teams) haben gelernt, die Arbeit als das zu sehen, was sie ist: eine spannende Herausforderung, die wir gemeinsam meistern werden.

Wenn Sie dies ausprobiert haben (oder nicht), würde ich gerne einige Geschichten oder Feedback lesen!

Wenn Ihnen dieser Beitrag gefallen hat, könnte Ihnen auch mein Newsletter gefallen. Ich schreibe über Produktmanagement, teile umsetzbare Erkenntnisse und nehme zum Spaß reale Produktherausforderungen an (ich weiß, oder?).