Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

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 1

10:30 – 11:00 : Coffee break

11:00 – 12:30 : Micro Sprint 2

12:30 – 13:30 : Lunch

13:30 – 15:00 : Micro Sprint 3

15:00 – 15:30 : Coffee break

15:30 – 17:00 : Micro Sprint 4

17:00 – 17:30 : Check-out and next steps

This 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!

Altstefan_msprints_bild3hough 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:

  1. stefan_msprints_matrixHow 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_bild7The 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.