#www.tastycupcakes.org | Explore Tumblr Posts and Blogs

tak4hir0 · 3 years

Link

GOAL OF THE GAME The goal of this game is to understand how organisational design using component teams leads to the waterfall and unnecessary complexity. In this game, you experience how a typical scaling approach I call “Copy Paste Scaling” results in not so good things in organisations. Copy Paste Scaling is what I see most companies do. What they do is scaling by adding Scrum Teams and as a result, they have multiple Scrum Teams; instead of multiple team Scrum. And then need to add all kinds of extra complexity to their organisation. OVERVIEW OF THE GAME We are a product development group of a company called StickyArts. We develop graphics using only Sticky notes. Our product consists of several deep specialities. These skills need well-educated people with lots of experience working on the single speciality. Some companies have Java, Android, iOS, MainFrame, SAP, Billing, Legal etc as specialities. At our company, the specialities we have are Sticky notes of colour Blue, Red, Green, Orange and Yellow. The product that we need to create is the text “LeSS = Scrum”. In order to build our product, we work in teams of at most 5 people. The teams are organised into single function teams. So, there is 1 team per colour sticky note and we have a Red team, a Blue team etc. DURATION 90 Min. NEEDED SUPPLIES 5 Teams of at least 3 people 5 flip charts or A0s and wall space for the teams to work on. 7 tables 5 packs of different colour post-its. Thick sharpies for each colour for the Analysis Team. Caps or Hats; 1 Program Manager Cap, 5 Integration Team Caps, 5 Product Owner Caps, 2 Project Manager Caps. 1 Printed Product Backlog, see below an example. (download here) Printed decompositions of PBI letter ‘e’, see below for an example of letter ‘e’ ( download here ) The printed template for the letters ‘L’, ‘S’, ‘S’, ‘=’, ‘S’, ‘c’, ‘r’, ‘u’, ‘m’. Each letter on a separate A3 paper. These are needed for the Analysis team to do the decomposition (download here) Game Rules that everyone in the room can see. Timer WhiteBoard/Flipchart where you keep track or progress StickArts.com Logo PAPERS TO HANDOUT FOR FURTHER READING AFTER THE GAME. Scale your Product NOT your Scrum at http://agilix.nl/resources/ScaleYourProductNotYourScrum.pdf Why Scaling Scrum is the Wrong Question to ask at https://agilix.nl/blog/528-how-to-scale-scrum-is-the-wrong-question-to-ask WORKFLOW The teams do the following steps in parallel but synchronized: Start each Sprint with 1 min of Sprint Planning. ( how should we build our PBI? ) Then we have a 2 min development episode. The teams build their PBIs. ( Build it by using post-its. ) and end the Sprint with 2 min of retro where each team proposes an improvement. ( what dynamics do we see and what can we do to improve? ) The facilitator of the game acts of the owner and has final say on organisational design and acceptance of the product. After each retro, the facilitator leads a discussion about the dynamics that are observed and the teams’ proposals for improvement. Out of the organisational design improvements, you choose 1 proposal and implement it. PRODUCT BACKLOG (DOWNLOAD HERE) EXAMPLE DECOMPOSITION OF LETTER ‘E’ (DOWNLOAD HERE) FACILITATOR GUIDE Step 0. SET-UP THE ROOM VELOCITY-CHART We are going to track the teams’ velocity to see progress each Sprint for each team, to use it for Sprint Planning and to track PBIs done. Create a Velocity Chart for the 5 teams for 5 Sprints. RULES – A0 Create on an A0 Paper the rules of the Game to that it is visible during the game. A team only works its own speciality. Sprint Planning 1 min Sprint 2 min Retro for improvement of the system 2 min You cannot form other DEVELOPMENT teams. You can introduce other types of teams. We Improve the system based on your feedback from the retro PBL – A0 Glue the Product Backlog on a wall or door in priority order en explain the PBIs. The order of the PBL is from left to right: “LeSS = Scrum”. Explain the Product Backlog. It is ordered in Value and it already has estimates on it you see. SPACE Each team needs a flipchart or wall space with A0 papers and also their colour stick notes. Table space for the Analysis Team as far away as possible from the development teams. Table space for the Integration Team as far away as possible from the development teams. Enough wall space for the end product ‘LeSS = Scrum”. Step 1. ORGANISE INTO DEVELOPMENT TEAMS So, first step: Let’s organise into DEVELOPMENT teams For example: “You are 1, you are 2 you are 3 etc” Explain: You are DEVELOPMENT team with all the skills from development, to testing to ship your speciality colours. REMEMBER: You can only work within your own speciality and use your own colour sticky notes. START SPRINTING SPRINT 1 GOAL: Understand that there is a mess and propose to introduce an Analysis Team. Give each team a PBI and then you can start Sprint Planning of 1 min. EXPLAIN AGAIN: You can only work on your own speciality because otherwise, that would not be efficient Ask if there are any questions? IF they say something like: this is stupid, we cannot complete a PBI because it required multiple components THEN say yes that is the result of component teams. SKIP Sprint 1 and ask the teams to come up with a proposal to fix it. Set the timer of the Sprint Start Sprint Planning for 1 min. Start development episode for 2 min At the end of the Sprint ask: what is your velocity? Nice all worked very hard how many PBIs are done? …. Update the Velocity Chart for each team. Facilitate: “Interesting, we only created parts of PBIs, but the most important PBI also did not get done. Facilitate what they see happening around them. What dynamics they see etc. Point out the dynamics of local optimisation and creating wastes. Now ask: “I want the most important PBI to get done the next Sprint. And you are only allowed to work within your single speciality.” And then ask: “Please have a 1 min retro and come up with a proposal for improvement”. After their retrospective: Ask each team one at a time what their proposal is. Facilitate the retro results so that they propose something like an Analysis Team. Once they propose such a thing you choose that proposal to be implemented. Each team will have 1 person that speaks on behalf of the team and will share the team proposal for improvement. You make them the ‘volunteers’ to be part of the Analysis Team as Team Product Owner. Invite them to leave their teams and become the Team Product Owner and take a seat at the Analysis Team tables. Give them their Analysis Team hats and hand them A3 papers and colour stick notes to work with. Add Analysis Team to the Velocity Chart and start tracking their progress too. SPRINT 2 GOAL: Understand that there is a bigger mess and that work needs to be integrated Important: Let the teams throw away their work of the first Sprint because it did not work anyway. The teams start Sprint 2 clean. Show the teams the decomposed letter ‘e’ so that they understand how it looks and what the Analysis Team needs to do. Show the Analysis Team the PBL with the next PBIs that need to be decomposed. Point out that each Team PO needs to decompose as much as possible for their OWN team. Explain that in this Sprint the development teams will produce their part of the decomposed letter ‘e’ PBI while at the same time the Analysis Team will decompose as much PBI from the PBL as possible. Hand out the prepared decompositions letter ‘e’ to each team. Each team gets only its own decomposition by colour. Tell the analysis team that they need to work on the Product Backlog and decompose as many PBIs as possible for their own team. For example: The Team PO of the Blue team can pick the template for letter ‘L’ and then draw blue squares on the A3 paper on the right location. After all blue squares are on the exact location the decomposition of letter ‘L’ for the Blue team is done. Set the timer of the Sprint Start Sprint Planning for 1 min. Start development episode for 2 min At the end of the Sprint ask: what is your velocity? Nice all worked very hard how many PBIs are done? …. Update the Velocity Chart for each team. What happens is that a lot of work got done, but nothing is integrated. Facilitate: Facilitate what they see happening around them. What dynamics they see etc. “Please have a 1 min retro and come up with a proposal for improvement” After the retrospective Ask each team one at a time what their proposal is. Facilitate the teams’ proposal and let them propose something like an Integration Team. Once they propose such a thing you choose that proposal to be implemented. The members that speak on behalf of the team are the ‘volunteers’ to be part of the Integration Team. Invite them to the Integration Team tables and give them their Integration Team hats. Explain that their task is to get the parts from the teams and integrate them into a DONE PBI on the wall. They will need to get the A0-papers from the teams and combine it into a single A0 with the complete PBI. Point out the dynamics of Integration Teams, waterfall, handoff, delay, information scatter, not being able to work on highest value PBI and therefore optimising for ‘ass to chair time’ etc. Note: Add Integration Team to the Velocity Chart and start tracking their progress too. SPRINT 3 & 4 GOAL: Understand that there is even a bigger mess; that nothing really gets done and that work is being done out of order creation queues and coordination problems. In this Sprint: The Integration Team is integrating PBIs from the teams. The Analysis team is analysing the next PBIs. The Development Teams are developing their part of the PBIs. Set the timer of the Sprint Start Sprint Planning for 1 min. Start development episode for 2 min At the end of the Sprint ask: what is your velocity? Nice all worked very hard how many PBIs are done? …. Update the Velocity Chart for each team. The waterfall is there… Facilitate: Facilitate what they see happening around them. What dynamics they see etc. Point out all the dynamics of Component Team and the effect of having to do waterfall. A lot of PBI is being developed out of sync because they work of the PBIs do not distribute evenly across the teams. To manage this and ensure that the right pieces are integrated you need a solution. “Please have a 1 min retro and come up with a proposal for improvement” After the retrospective Ask each team one at a time what their proposal is. Facilitate so that the improvement proposal you choose is to introduce project managers to handle the coordination and keep track of the work. Give the project manager the Project Manager hat. Fire all of them Now, explain that you do not like this. You spent a lot of money and very little got done. More and more people are added for coordination, integration, design, analysis who are not doing value work. Facilitate discussion about the dynamics of adding special coordination roles like Project Managers. Now, fire all people. “You are all fired…” Rehire all of them and let them organise into feature teams. Give each team a PBI and start a new Sprint. (The teams will likely finish a PBI on the wall by themselves.) Set the timer of the Sprint Set the timer of the Sprint Start Sprint Planning for 1 min. Start development episode for 2 min Update the velocity chart for each team. Facilitate discussion about Feature teams and the dynamics. Hold a retro for improvement. Pick 1 improvement Have final Sprint. Facilitate Recap of the whole game by using a distributed retro technique where the teams come up with their most important learning or concepts. LESS HUGE EXTENSION For LeSS Huge, with more than 25 people, you can introduce Areas. One Area does the ‘LeSS’ part and the other Area does the ‘Scrum’ part. Enjoy, Cesario The LeSS Dynamics Game by Cesario Ramos is licensed under a Creative Commons Attribution-ShareAlike 4.0 International License. Based on a work at https://agilix.nl/blog/534-the-less-dynamics-game. Book author, LeSS Trainer and Coach.

#www.tastycupcakes.org

0 notes

cahouser · 5 years

Link

Summer Meadows is a short and fun exercise to demonstrate the effect of handoffs, detailed specs, and silos (otherwise referred to as the Product Management Vacuum) and to communicate how the Three Vs (Vision, Value, Validation) serve as a way to create more cohesive and creative products.

Note: I apologize as I am unsure who to credit for this game. I first learned it from a client, who learned it from an agile coach. It has been tweaked along the way. I first ran it at Agile 2018 with Ralph Jocham to demonstrate the Three Vs. If anyone knows, please add a comment below. UPDATE: I found the original post from David Barnholdt here. Wish I saw it before putting all this effort into a write-up.

Ingredients:

Flip chart paper for each team.

Colored markers for each team (green, blue, red, yellow/orange, black should do it).

Print-out instructions for each team. This one that I like to use has instructions for drawing a Summer Meadow scene with flowers, animals, sun, etc. Page 1 has detailed instructions (specs) and page 2 has high level, more value-based instructions. Page 3 is not for printing. I display it on a projector to use as a debrief afterward.

Steps:

Divide participants into an even number of teams. Each team should have between 3-6 people.

Provide half the teams (preferably on one side of the room) the detailed specs and the other half the high-level instructions. But act like you are handing the same instructions to each team. Ask them not to look until you say ‘go’.

Tell them they have 4 minutes to complete the instructions and send them off.

Make sure you circulate while they’re working. You will notice that the detailed spec teams are very focused and start checking their work off without ever asking why they’re even creating this drawing. They randomly place flowers, birds, cows all over the drawing. Whereas the teams with high-level instructions will start asking you more questions. Since the customer is mentioned in their instructions, they will likely ask you about the customer. I answer with “It’s me! I wanted a drawing to remind myself of my summers in Ireland at my Grandparents”. They will then ask more about that experience and end up producing something much more cohesive. Here are some examples with detailed specs: … and here are some examples with high-level instructions:

When the time is up, have everyone stop and ask them to post their drawings for everyone to see. Ask which ones are better. The more cohesive, customer-focused drawings will clearly be better. I like to point out some cow high up in one of the detailed spec drawings and ask if it is flying. I’ve had teams get defensive and respond with “Well the specs never said that cows don’t fly!”.

Finally, reveal that this was a trap and that you provided them with different instructions (if they haven’t already figured it out). Then start the debrief.

Debrief/Learning Objectives:

Ask the participants how we end up with detailed specs in the real world.

Ask if they have ever experienced similar outcomes. I’ve never had a group say they’ve never seen a similar effect in their world.

Ask about the sentence “This scene reminds our customer of their childhood growing up on a farm.” Tie it back to the importance of a Vision.

Ask about the success criteria and the bottom of each page. Tie it back to the way we measure Value.

Ask which of the two will be more likely to ask about the customer. Tie it back to the importance of Validation.

Point out that counter-intuitively, less details can produce better results through better more focus, more communication, and more autonomy.

0 notes