Micro Sprints - your way to effective workshops

Don’t get me wrong, meetings and workshops are important for managers to get their work done. As Paul Graham nails it: meetings are the managers’ work. Nevertheless I’ve experienced so many management workshops dull and vague, lacking any specific outcome. This is why I started to design management workshops as micro sprints. These workshops are now fun, fast, productive and always result in a specific delivery.During the last years of my work as a Management Consultant I’ve learned that the right setting is key to working with top-managers and executives. In my case this means that most of the consulting impulses on how to build fast, adaptable user centric organizations are given during management workshops that most of the time are held offsite. Offsite meetings should take place regularly (at least bi-monthly) and should be scheduled way in advance.The micro sprint workshop structure provides the participating managers with a strict repetitive structure that helps them to deliver high quality decisions - which are most of the time deliverables of the management participants - in a very high pace by using and at the same time learning some of the core practices of Scrum.

What’s the idea behind Micro Sprints?

Focus is a Scrum value. It helps to get work done and avoids overload by doing too many things at a time. By using the micro sprint workshop framework I try to create as much focus as possible to achieve productive and fun workshops.

stefan_msprints_bild_1

Define the Workshop Release Goal

Consider the workshop as a period of time that needs to have a specific outcome. In Scrum we define the release and sprint goals before we define how we are going to achieve these goals. We apply this practice within the micro sprint workshop framework to direct the attendees’ focus onto this release goal. I suggest to define the release goal before the workshop takes place. If this is not feasible, do it directly after the initial workshop check-in. A possible release goal might be: After this offsite meeting we are going to announce the first iteration of organizational changes towards the new delivery structure. All necessary decisions have been made.

stefan_msprints_bild_2

Keep the agenda loose

Usually management workshops have strict agendas that schedule every single minute precisely upfront. This might be useful in a lot of settings. Nevertheless I try to avoid these rigid agendas whenever I want the management team to work closely together. What I use instead, is an agenda that only prescribes the sessions in which we work together. I don’t prescribe which topic will be tackled when. I have made good experiences with sessions of 90 minutes each, intermitted by generous coffee breaks.

Example

09:00 - 10:30 : Check-in, Backlog Grooming and Micro Sprint 110:30 - 11:00 : Coffee break11:00 - 12:30 : Micro Sprint 212:30 - 13:30 : Lunch13:30 - 15:00 : Micro Sprint 315:00 - 15:30 : Coffee break15:30 - 17:00 : Micro Sprint 417:00 - 17:30 : Check-out and next stepsThis structure creates four highly effective micro sprint sessions. In every single session the management team is encouraged to develop and finish at least one specific deliverable.

Switch off the gadgets!

Alt

stefan_msprints_bild3

hough this might be a no-brainer: Please switch off your electronic devices. You don’t need your smartphone for being productive in the workshop. Your notebook might be stored in your bag. Try to work as distraction-free as possible. It is the workshop facilitator’s mission to create focus during working sessions.

Create the Workshop Backlog

Prior to every workshop collect issues that are raised by the participants. Usually not every topic is closely related to the defined release goal but don’t consider this as a problem. Prepare all these issues on story cards which then will be pinned to a wall in the room. I let the attendees add issues if needed. Consider this part of the workshop as an initial Backlog Grooming or Backlog Refinement session. Every participant is then invited to briefly present his or her issue and the aimed outcome if it will be tackled in the workshop. After every ‘story‘ on the wall has been introduced to the participants and no more issues are raised you get a fully ‘groomed‘ workshop backlog. Then let the participants prioritize the stories.

Prioritize the Workshop Backlog

Prioritizing the backlog can be done fast and fairly easy by using an adaptation of the Matrix for Cost of Delay by Don Reinertsen. Two questions are relevant to finding the right priority of each story:

stefan_msprints_matrix
  1. How high is the cost of delay if this story will not be delivered within this release (this workshop)? The answer needs to be given in proportion to the other stories on the wall.
  2. How long does it take to deliver this story if we only work on this one story at a time? This estimate needs to be given in proportion to the other stories as well.

With a little help of the workshop facilitator this prioritization work is done within some minutes. I once got the feedback from a participant that it helps if you don’t show the prioritization numbers of each box in the matrix to the participants. With this easy technique you’ll get a prioritized release backlog that will be the foundation of the workshop. Feel free to reprioritize this backlog if new issues are introduced to the backlog within the workshop or if the group of managers has learned something so important that the old prioritization doesn’t make sense anymore.

Story 1 - Sprint Planning 1

What happens then is basically pure Scrum. From time to time I like to address the managers in my workshops as a management team. This is meant to be a hint that it is not enough to announce that Scrum now needs to be done within the company. Instead, even the management needs to understand and feel what it is like to work within a management framework called Scrum. So, at the beginning of every session the story with the highest priority is pulled from the workshop backlog. Just pull one story at a time! Then start Sprint Planning 1 by defining exactly what needs to be done within this story by adding information to:

  1. Understand the context of the story. Why is it important to deliver this story and which information might be relevant for all participants?
  2. Define the acceptance criteria. This answers the very important question: When are we done? Based on which criteria do we know that we have done the right thing? This also gives a very good idea on what the expected benefit of this story will be. It is not unusual that participants start to argue who the user of this story is after all.
  3. Define the constraints of that story. What are the givens which cannot be ignored or violated by the derived deliverable?
  4. Define the user acceptance tests. This basically answers the question what needs to be fulfilled in order to deliver the story in the right way.

These items shall be testable by the participants. Although it might be ideal that the participants write these additional informations on their own, it is often a bit too much for them if they are confronted with this approach for the first time. The facilitator should then guide the conversation, collect all the information and write it down in a prepared template. This Sprint Planning 1 format might sound like overhead. But I’ve experienced too many times that participants have a hard time to define the aimed deliverable of an issue. I often experience participants who „just want to talk“ about an issue. But seriously: this is not Scrum. Scrum was designed to deliver. We want to get things done.

stefan_msprints_bild7

The pleasing part of this exercise is that managers feel relieved and energetic when they can say precisely what they want to deliver. It creates focus and frees their minds from load that hinders them from working on one item. Due to their daily work routines managers are trained in analyzing topics broadly. They swiftly find edge cases and dependencies which usually make it almost impossible to deliver. Thats why I use the constraint of micro sprints lasting no longer than 90 minutes to get something worthy done. This is challenging and possible.The edge cases are important you say? Fair enough. Nevertheless, if the edge case prevents the 80% solution to be outspoken, it is not helpful at all to stick to the edge case. It is far more easy to find a solution for the edge case if you’ve found a solid solution for the default cases first.

Sprint Planning 2 - optional

Sometimes participants have a hard time saying how they are going to tackle the started story. They now know exactly what they want to deliver. In Sprint Planning 2 they work out how they are going to achieve this. The easiest way to walk through this exercise is by checking the previously defined User Acceptance Tests and derive designs or work items that address this test. I sometimes even create tiny task boards to visualize what the participants want to do in order to deliver the story.

stefan_msprints_bild4

Delivery Check

If the story is so well defined it is usually very easy for participants to deliver it within 90 minutes. Don’t forget that Sprint Planning 1 and 2 are included in these 90 minutes. Also the delivery check takes place within this micro sprint session. The participants check if all the User Acceptance Tests are met and if the Acceptance Criteria is fulfilled.

Micro Celebration

Believe me, the feeling of having accomplished something is staggering for managers who are used to sit in boring meetings caught in endless discussions and close to no substantial decision. Let the participants celebrate their deliverable. Check the time then. Let the participants decide if they want to deliver one additional story before the break. If there are only some minutes left, start the break.This way of working and delivering together as a management team is fun and can be exhausting at the same time. Having some slack is fine! This will help to deliver the next story. The facilitator then documents all the deliverables and prepares the next micro sprint.

Repeat

Keep the structure stable and repetitive for every micro sprint session of the workshop. This is not boring. It helps to improve the overall team collaboration and helps the participants to become focused and faster.

Retrospective

Don’t forget the Retrospective. This is an essential part of Scrum and therefore should also be integrated in the micro sprint workshop framework. To keep the retrospective short and effective ask two simple questions at the end of the workshop:

  1. What went well this management offsite meeting that we are going to keep in the next offsite?
  2. What are we going to improve in the next management offsite?

That’s it. It’s the facilitators job to collect the results of the Retrospective in the same structured way as he has collected the deliverables of the workshop. This is the fast to implement and easy to use micro sprint workshop framework for your effective offsite meetings. I hope you find it useful and it will help you the same way it helped me and my clients to get the most out of their offsite sessions.

Agile Toolbox
bgloger-redakteur
November 30, 2016

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4