GameStorm is a technique for brainstorming developed by Bart Hufen from BrandNewGame. It uses gamification to identify areas for improvement and to make their impact transparent. We have adapted it for use in Sprint Retrospectives to support continuous improvement in teams. This format is excellent for a series of Sprint Retrospectives focused around a recurring challenge and makes very transparent what needs to be improved and how.
Full credits for the format go to BrandNewGame - we only simplified it for use in Sprint Retrospectives. You can obtain all the official GameStorm materials (and many more gamification techniques and digital tools) by becoming a member of the Gamification Academy.
A room with a large table in the middle and space to move;
One GameStorm-canvas (below) per group;
Green and red post-its;
The GameStorm Canvas
Below we've shared an empty GameStorm canvas. This isn't the official one that BrandNewGame uses, it's a custom made version we've used for a Retrospective.
At the end of the Retrospective, the canvas should contain the following:
Blue post-it: the overarching challenge the team wants to address;
Top yellow post-it's: the three biggest obstacles that need to tackled;
Red post-it's: actions to keep the obstacle in place or strengthen it;
Green post-it's: actions that are needed to remove or reduce the obstacle;
Bottom yellow post-it's: a definition of success per obstacle;
Play this game with up to 12 people. Split into parallel groups if you have more;
Set up the room with a large table in the middle, with the canvas on it. Create two corners for the two teams;
Part 1 - 30 minutes
Collectively identify an overarching challenge. Examples could be: “Expand ‘Done’ to include a tested deployment to production”, “Development Team remains stable for at least 3 months” or "Define and achieve Sprint Goals for the upcoming 3 Sprints". Write the challenge on the blue post-it at the top;
Collectively identify the three biggest obstacles that need to tackled and write them on the yellow post-its directly below the blue post-it. You can brainstorm these together, or use 1-2-4-ALL to identify them;
Ask the team to determine the relative value of the obstacles by asking them to divide 10.000 dollars across the three obstacles: “How much is saved or gained by removing these obstacles?”. Write the values down on the three yellow post-its at the bottom of the canvas. We’re not trying to fly to the moon with these values, so don’t worry about not being precise;
Part 2 - 30 minutes
Create two teams of equal size (4 to 8, with 6 as the ideal number): The Killers will identify concrete actions that the team (already) performs that keep the obstacle in place or strengthen it. The Dreamers will identify concrete actions that are needed to remove or reduce the obstacle;
Both teams take 15 minutes to identify as many actions (about ± 15) as they can per obstacle. Write them down on individual post-its and collect them in a ‘team corner’, grouped by obstacle. You can use 1-2-4-ALL to give everyone an equal voice within their team, and prevent dominant or more extrovert members from influencing the results too much;
Part 3 - 30 minutes
Ask the teams to physically switch corners, meaning that the Killers now get to see what the Dreamers came up with and visa versa;
The teams take 10 minutes to dot-vote the top 3 actions per obstacle. So the killers dot-vote the three best actions as brainstormed by the dreamers, and visa versa. Ask teams to consider feasibility, impact and how actionable the items are;
Both teams pick the top 3 actions per obstacle and put them in the boxes on the canvas. The resulting canvas now should have eighteen actions; nine actions that keep obstacles in place, and nine that can help remove them;
Part 4 - 30 minutes
Ask the group to divide the value per obstacle across their six actions identified (both green and red). So if the obstacles in column 1 has a value of 3.000, the team can divide 3.000 dollars across the six actions above it;
Determine a definition of success per obstacle. How can you measure progress? When have you successfully resolved the obstacle? Make this as tangible as possible.
You now have a canvas with eighteen actionable activities to start or stop doing, and address the obstacles and resolve the overarching challenge. Decide which items the team will pick up first (e.g. during the next Sprint). You can revisit and update the Canvas throughout the Sprint or during upcoming Sprint Retrospectives - until the challenge is resolved;
Provide the team with fake money to make the valuation more fun;
Create a leaderboard to promote friendly competition among members or teams. Whoever completes a green action or stops a red action from happening again (as decided by the entire team) earns the points awarded for that action;
Create avatars for the members of the team, or the teams themselves if you play with more teams;
Keep track of the challenges bested by the team(s) by creating a timeline. You can even treat them like ‘achievements’ that teams ‘unlock’;
For some fun, decorate the corners for the Killers and the Dreamers with appropriate attributes;
Give it a try!
In this simplified form, GameStorm is a really fun format for series of Sprint Retrospectives. It creates friendly competition by laying down a simple framework for improvement. It helps teams work from big challenge to small, actionable activities that contribute to solving that challenge. And it creates transparency in what the team is currently improving.
Want to know more about GameStorm? Join their upcoming training on March 21 & 22 or in September to learn how to apply this game to organizational change and get more out of it.
We are going for "Agile" Transformation, One of our goals is to increase velocities across all our teams by X% , Have you heard of this? I have heard Marc Andreessen’s Adage that “Software is eating the world”, this is becoming the differentiator for Industries that were previously thought to be more manual.
A Company that is known for developing “Agile” products surveyed more 18,000 customers and Software development professionals, and this is what they discovered
77% practice Agile Development.
The well-known Contributor of this Game changer is “Scrum” – A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Velocity is just a Complementary & Optional Practice in Scrum
When you start adopting Scrum, at any point in time the total work remaining to reach a goal can be summed. Various projective practices upon trending have been used to forecast progress like burn-downs charts or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. Especially, Agile Frameworks like Scrum doesn’t mandate any practices to be used, however these are Complementary practices that is found to be useful. These practices are used to build “Dashboards” to make decisions.
But the Agile development does not necessarily lend itself to the kind of dashboards and reports beloved by managers. The few metrics it produces make little sense outside of the context of team planning. Given this shortage of usable information, it can be tempting to re-purpose velocity as a measure of productivity. After all, it’s a measure of team capacity so it follows that changes over time could be used to indicate overall shifts in productivity?
“Velocity is an option to Measure progress” not the value!
Alongside these complementary practices that we have, the biggest risk with this approach is that velocity is a planning tool rather than a specific measurement. It’s an estimate of relative capacity that tends to change over time and these changes don’t necessarily indicate a shift in productivity. It’s also an arbitrary measure that varies wildly between Organizations, teams and Products. There’s no credible means of translating it into a normalized figure that can be used for meaningful comparison.
What is Velocity then?
Velocity is an indication of the ability to turn Product Backlog into releasable functionality across time, or for a specified price.
I want to increase my team velocity == that’s my goal
Given that velocity is such an arbitrary measure it is easy to game, Inflate it or Deflate it. By equating velocity with productivity you create a “perverse incentive” to optimize velocity at the expense of developing quality software. Consciously or not, teams will start trying to demonstrate an increase in productivity by massaging velocity upwards, if the goal is set as Increase in Velocity is directly proportional to the productivity .Worse still, they may start cutting corners to deliver things. This can lead to a build-up of technical debt and the product they create will be brittle.
Magic Moment- Open the team’s burn-down charts
If you distribute burn-down charts to senior management. Every sprint, the progress line magically starts to intersect with the delivery target. The shape of the line may vary wildly, but somehow there’s a speeding up or slowing down in the second half of the sprint to meet the expectation.
Velocity is a measure of the amount of work that a team can do. This is not the same as measuring the value or impact of this work. Velocity may actually be relatively stable in a successful and well-established team as the amount of raw effort available for each sprint remains constant. In this case, putting artificial upwards pressure on velocity will only serve to distort estimates.
Can you really measure software productivity?
Productivity is determined by looking at the inputs and outputs of an activity. It’s easy enough to measure the inputs for software development, but it’s actually very difficult to measure the outputs in any consistent way.
Most importantly, it is Outcome that Matters, not the Output.
A raw, quantitative measure such as numbers of lines of code does not provide any reasonable guide. It is too dependent on wildly variable factors such as coding style, development language and implementation approach. It can also be counter-intuitive as well-written code that has taken time in crafting often requires fewer lines of code.
How do we Measure Value?
If you derive a measure of productivity from velocity then you will see a statistical improvement. This is not the same as successful development.
Ultimately, Agile Frameworks like “Scrum” process framework relies on empirical approach, Empirical process relies on Inspection, Adaptation and Transparency, that enables continuous feedback loop between development teams and the commercial context. A more meaningful measure of success should take this into account and focus on real-world benefits rather than abstract measures or normalized indicators. But remember,
A release is required to realize the Value.
So, Am I saying metrics are bad?
No, I am not, hear me again, I am not saying “metrics” are waste, they are not just management indulgence, they help you gather Information, decide on corrective action , most importantly how to figure out how to evolve. If you tend to satisfy on-going Management hunger for reports, you end up creating meaningless overhead. End of the day, Software is Complex and that can’t be predicted, but only forecasted!
Then, what do I measure?
Measure the value of your Investment, One of the ideas that Ken Schwaber put across is known as "Evidence based Management "- He says, Evidence-Based Management for Software Organizations is the first useful method for transforming software from an expense into a profitable asset. Especially the,
The Agility Index™ software enables you to measure the improvement in business outcomes and track the return of your investment.
Covering EBM is out of scope of this article, I would recommend to go through the below link for more Information on EBM, https://www.scrum.org/resources/evidence-based-management-guide
Scaling is a popular strategy these days: scaling innovation, scaling agile, scaling whole organizations. But scaling can easily undermine agile principles like focus and minimal viable product, and the abilities to deliver, learn quickly, and pivot decisively when required.
Human nature means we tend to want to scale too fast. I think of Frasier’s appeal to hire a full orchestra and a choir to record his show’s new jingle, much to his brother’s chagrin: “Ah, but if less is more, just think of how much more ‘more’ would be!” Once we prove a concept or framework, we want to add people right away, assuming this could only multiply its success. Unfortunately, adding people doesn’t always mean adding results. You don’t get double the output by doubling the teams—you may, in fact, end up with a decline in productivity. This is because the larger a team grows, the harder it is to choose decisively and correctly.
By keeping your organization small, you’re insisting that the right trade-offs and decisions are made. Smaller groups can move more nimbly than larger groups, and you can push the limits of rapid learning. Before you consider scaling, integrate as much continuous improvement as possible within the existing size constraints, either through improved practices, new technology, or the putting the right people and skillsets in place. Until you can scale to the point where 1 + 1 = >2, you simply shouldn’t scale.
To put it another way, work to ensure that it’s only the number of people in your organization that’s holding you back. Too often we put the focus on growth in anticipation of increased customer needs, rather than reducing the time it takes to incorporate customer feedback into the product or service. Instead, get one concept proven by a certain demographic (or number of customers), then scale.
Once you’re in scaling mode, do so responsibility. Go from one to two. Get that to work. Then go from two to three, and get those three to integrate efficiently. When you add teams, a few things happen: it becomes more difficult to collaborate cohesively, and more expensive. You need to make sure you’re scaling ahead of the overhead required to coordinate work amongst your teams.
From my experience, a lot of organizations begin to scale without the infrastructure to support the throughput. Before you look at increased throughput from scaling the number of people, scrutinize your existing end to end processes and practices to make sure they can keep up. Scaling is more than just producing code, especially in large organizations where you regularly work with third party audits and control functions. Ensure that when you scale, the supporting functions like audit, marketing, finance, and customer support are ready and willing to support it.
In sum, localize continuous improvement initiatives to get the most out of your current team before adding to it. Scaling will actually make you move more slowly, and it’s much easier to fail fast. Nail it—really get to know your organizational bottlenecks, without assuming adding more people will solve them—before you scale it.
Un Scrum Master que le dice al equipo de desarrollo y al Product Owner que según alguna experiencia cada miembro del equipo de desarrollo solo puede desarrollar como máximo hasta una capacidad de X puntos de historia por Sprint, este tipo de Scrum Master también aclara que intentar que el equipo haga más puntos de historia implicaría presionar al equipo de desarrollo y crear un mal clima de trabajo.
Un Scrum Master que dirige la reunión y le pregunta a cada miembro del equipo de desarrollo las tres preguntas como son, que hizo ayer, que va a hacer el día de hoy y que impedimentos tiene. En esta reunión el Scrum Master enfatiza a ese desarrollador que tiene que cumplir con las tareas que se ha comprometido.
Un Scrum Master que divide a un equipo de desarrolla al etiquetarlos con roles, por ejemplo, menciona a los “Programadores” que deben terminar su código para que puedan pasarlo a “QA” que está esperando algo que probar y que mientras eso no suceda la persona de “QA” se encuentra con tiempos muertos porque no tiene nada que hacer.
Un Scrum Master que protege al equipo de desarrollo estableciendo que como están sumamente ocupados no hay tiempo para interrumpirlos y por ello el Product Owner necesita hacer el refinamiento con el Scrum Master y evitar el contacto directo con el equipo de desarrollo porque ello podría impactar a los tiempos.
Un Scrum Master que toma el “Sprint Retrospective” como una reunión que quita tiempo, pero si se hace el enfoque es en hacer dinámicas que ayuden a fortalecer el buen ambiente de trabajo y los temas técnicos son menos importantes.
Un Scrum Master que enfatiza al Product Owner y al equipo de desarrollo que si el equipo ha venido produciendo X puntos de historia de velocidad entonces no pueden hacer más puntos de historia o en última instancia podrían aumentar ligeramente los puntos de historia, pero en ningún caso se debe presionar al equipo porque podrían sentirse mal.
Un Scrum Master de antemano establece un proceso de control de cambios que implica evitar que se incluya el “feedback” del Product Owner, este proceso va a establecer que se encuentra dentro del alcance del Sprint y que se encuentra fuera del alcance. Con este proceso se busca evitar que el Product Owner o alguien del equipo de desarrollo incluyan la información producto de las revisiones y refinamiento continuo.
Un Scrum Master que establece con claridad que es responsabilidad del Product Owner ingresar todas las historias de usuario y criterios de aceptación en la herramienta, también que el Product Owner tiene que dar todo el detalle necesario porque el equipo de desarrollo solo hará aquello que el Product Owner les dice que haga, además si el Product Owner omite algo será de responsabilidad única y exclusiva del Product Owner y que en ese escenario el equipo de desarrollo no lo va a desarrollar porque como el equipo de desarrollo ha estimado a su máxima capacidad cualquier cosa que salga definidamente no será incluido. Por ello el Product Owner es el único responsable de lo que se debe construir.
Un Scrum Master que le dice al Product Owner que la única reunión donde se va a inspeccionar el incremento de producto es en el “Sprint Review” por ello debe tener paciencia y esperar a esa reunión. Antes de esa reunión el equipo de desarrollo no puede entregar nada para inspeccionar ni dar “feedback” porque tiene que terminarse el tiempo del Sprint según lo establece Scrum.
Un Scrum Master que le dice al Product Owner y al equipo de desarrollo que no usa Scrum sino la agilidad, por esa razón los “Daily Scrum” se harán esporádicamente cuando sean necesarios y solamente si el equipo lo decide porque ellos son auto organizados.
Un Scrum Master que le dice al equipo de desarrollo y al Product Owner que no se puede encontrar alternativas para mejorar, solo hay una alternativa que es primero desarrollar el código y luego hacer las pruebas. Scrum no dice cómo hacerlo y es la única alternativa, cualquier otra alternativa lleva riesgos que no se pueden asumir porque el Sprint es corto.
Un Scrum Master que mapea los puntos de historia a horas. Es decir, el equipo hace la estimación en horas. Con esta técnica cumple con lo que dice Scrum de usar puntos de historia y también con el Jefe de Proyectos que le pide un plan detallado en horas.
Un Scrum Master que le dice al equipo de desarrollo que Scrum es una metodología para gestionar proyectos y que está metodología se basa en que todos terminen las tareas a las que se han comprometido.
Un Scrum Master que le dice al equipo que la estrategia es hacer un Sprint de desarrollo con pruebas iniciales y luego un Sprint de Testing para asegurar la calidad del producto.
The Scrum Master role is a new one and often mis-understood by teams and organizations who are Implementing Scrum. When I work with organizations often I see Scrum Masters role is not taken very seriously,
A frequent response is to make the “leftover people” the Scrum Masters. They might be nice people but often lack the right traits, motivation, and Scrum knowledge to be effective Scrum Masters. They might morph the role into something else which then becomes accepted “definition “ within the organization as the way a Scrum Master should be. So, eventually that leads to False assumptions about the Scrum Master role .
After all, the Scrum Master should know if they’re doing things correctly, right? Sometimes well-meaning Scrum Masters who are new to Scrum or not a good fit for the Scrum Master role cause things to happen that are actually counter to Scrum and detrimental to Scrum adoption, thereby transforming them into anti-Scrum Masters.
Scrum guide clearly articulates that,
“The Scrum Master’s job is to work with the Scrum Teams and the organization to increase the transparency of the artifacts. This work usually involves learning, convincing, and change. Transparency doesn’t occur overnight, but is a path”
Surviving the Traditional Corporate Culture
Traditional organizations have a project coordinator who coordinates work between teams. When you adopt Scrum, the multi-team coordination is the responsibility of the teams. Many teams are so used to having a coordinator role to do this type of work, But Scrum Masters enable the teams to do this on their own. There are many ways than Organization's culture may need to change, in order for Scrum teams to thrive. Perhaps your Organization has a culture of "dictating" and "telling" the teams on what to do and coordinate on their daily activities.
Often, this starts with some Constraints. But,
Constraints foster Creativity
Help the teams this way by Introducing Some of the Practices listed,
Create Team Agreements on Co-ordination Mechanism, eg: Nexus Daily Scrum - The Nexus Daily Scrum is an event for appropriate representatives from individual Development Teams to inspect the current state of the Integrated Increment and to identify integration issues or newly discovered cross-team dependencies or cross-team impacts. For more information on Nexus please refer : https://www.scrum.org/resources/online-nexus-guide
Introduce teams to each other.
Facilitate a discussion , only if needed
Enhance the Transparency of the teams using, Information Radiators (For ex: Dependencies, for the teams to Inspect & Adapt themselves).
Teach the teams the purpose of each of the events and ensure the purpose is understood by the entire Scrum team and the Organization.
Work with other Scrum Masters in the Organization to improve the effectiveness of the Scrum Implementation.
If teams are Distributed, Help the teams by Introducing “Good” practices on Distributed Model.
If multiple teams are working on the same backlog , help the teams create mutually accepted “Definition of Done” which will make their Integrated increments potentially releasable.
I have recently been helping a new Scrum team get started with the framework and helping them to set themselves up with the best chance of being successful with Scrum.
After a two week sprint in which they did deliver an increment and learned a lot about the product that they would be work on, it was time for their first retrospective. I decided that this would be an ideal opportunity to learn more about each other and so I was able to facilitate one of my favourite Retrospectives activities.
Remember that the retrospective isn't the only time a team can make improvements to the way it works - This can be done anytime during the sprint and they should be encouraged to do so. The Sprint retrospective is a formal opportunity within the sprint cycle to look inwardly.
First Stage - Journey Map
I took the team out from their normal workplace, just because it felt the right thing to do, and explained the overall purpose of a Sprint Retrospective. (Remember this is the first time that the team would have had a retrospective as a team)
I showed the team my journey map, something that I'd seen on my "Train The Trainer" course for the PSM, and on which I showed the highs and lows of my path to my current position.
This was done by taking a piece of A3 paper, drawing a line down the middle and then on left hand side drawing a vertical line with a plus sign and a negative sign. Then I plotted out my life so far:
going to university,
getting my first job,
a death march project,
a good opportunity etc.... plotting out how I got to be standing in front of them.
Then for 3 minutes I discussed the drawing; people laughed, asked questions, they found out my children’s names and a little bit more about me - we started to bond as a team.
I then asked the room if they were happy to share this type of information, stressing the importance that if they are, they still control what they discuss and share with the rest of the team.
I then gave the team 5 minutes to think about their lives and to draw out their journey map.
Giving each team member 3 minutes to discuss their map, we found out things that would have taken the team ages to find out:
Who moved out from their parents house to the city of their dreams?
Who used to be in a rock band?
Who failed their GCSEs because they thought they knew better than their parents and didn't need to revise.
It was great to see that the team opened up to each other more. They started building trust with each other as they shared stories of similar experiences. They stopped seeing each other by their role, Developer, Product Owner etc.. and saw each other as people, all by drawing a wavy line.
Second Stage - Centre of The Universe
For the next stage of the Retrospective I asked the attendees to clear the room of chairs and to stand around the edges of the room. I then placed an item in the middle of the now empty meeting room and told them that that was the Centre of The Universe.
By reading out a list of statements, and depending on how strongly they felt about it, the closer to the centre of the room the person moved. If they felt strongly about it, they stood in the centre of the room, if they were against the statement they moved towards the edges. Simple!
To prove the concept I asked some "warm up" questions; e.g.
I enjoy playing sports
I enjoy watching romantic comedy films
I like beaches holidays rather than sightseeing holidays.
I then moved onto more targeted questions e.g.
I like speaking in front of people
I avoid conflict with people at all costs
I enjoy public recognition
I feel that there is a lot of pressure on me in my role.
I become quiet in uncomfortable situations
After each question, I asked the team to look at where their colleagues are standing in relation to the room and to them.
This knowledge will be useful to them when people behave differently to what they'd expect - "Why does Jon talk freely one on one, but in the Daily Scrum he is a little shy? Why does Jane go quiet when we're getting heated when discussing product backlog items in planning?"
Final Stage - The Close
The whole session was meant to be a fun way finding things out about people. We also learned that:
As per our Journey Map, our journey together as a team will have highs and lows. Sometimes we will get on and sometimes we won't - but that is normal.
We all have our strengths and likes, some of these are shared and some are specific to an individual.
We know that we need to look out for after each; what one person enjoys others may not be as comfortable.
Armed with this newly gained knowledge we know a little more about what makes our new colleagues tick and the experiences that they've had which contributes into making them the person they are.
I went away with a smile on my face and I know that the team went away laughing and knowing more than they went it.
Scrum is intended as a simple, yet sufficient framework for complex product delivery. Scrum is not a one-size-fits-all solution, a silver bullet or a complete methodology. Instead, Scrum provides the minimal boundaries within which teams can self-organize to solve a complex problem using an empirical approach. This simplicity is its greatest strength, but also the source of many misinterpretations and myths surrounding Scrum. In this series of posts we — your ‘mythbusters’ Christiaan Verwijs & Barry Overeem — will address the most common myths and misunderstandings. PS: The great visuals are by Thea Schukken. Check out the previous episodes here (1, 2, 3, 4 , 5, 6, 7, 8, 9, 10 and 11).
Myth: The Sprint Review is a Demo
Sigh. It is that time of the Sprint again; the Sprint Review. The Development Team is setting up up shop in one of the meeting rooms. While Jim connects his laptop to a beamer, Susan nervously re-arranges the notes of the work the team completed this Sprint. “Shall I demonstrate the new shopping basket?” she asks senior developer John with a hint of uncertainty in her voice. John nods, and - after a pause - adds “Sure. I’ll show the new order review page then”. As the clock hits eleven, the stakeholders start dropping in and awkwardly find spots around the huge table. Mary, the Product Owner, arrives and settles in one of the more comfortable chairs at the head of the table. She turns towards the Development Team and signals the start of the Sprint Review; “Take it away guys”. Forty minutes later, the Development Team has gone through their list of completed items and demonstrated everything worth showing. As the demonstration wraps up, the audience offers a mild applause to the Development Team. As the stakeholders are leaving the room, the Development Team sighs in relief. “Well, that was a great Sprint Review!”, Mary concludes.
In this post, we address the myth that the Sprint Review is primarily an opportunity to ‘demo’ the increment to stakeholders.
This post is for you if you recognize one or more of these telltale signs:
Stakeholders are easily distinguishable from the Development Team, both occupying their own side of the room;
The Sprint Review is a Powerpoint-presentation with screenshots of (supposedly) working software;
None of the stakeholders present are actually using, or going to use, the product;
There is hardly any input from stakeholders (or they’re not invited to);
The keyboard and mouse used to click through the product never actually reaches the hands of stakeholders/users during the Sprint Reviews, but remains soundly with the Development Team;
There is applause after the demonstration completes. Or worse, the Development Team is booed out of the room;
There is a general air of nervousness in the Development Team;
The Sprint Review is actually called a ‘Demo’ by the Scrum Team and stakeholders;
By treating the Sprint Review primarily as a demo, the purpose of this crucial opportunity for inspection and adaptation is lost. Too many Scrum Teams approach the Sprint Review as their moment to show progress, to give a ‘product update’, to sell what was built to stakeholders or to talk about what they did.
“Too many Scrum Teams approach the Sprint Review as their moment to show progress, to give a ‘product update’, to sell what was built to stakeholders or to talk about what *they* did.“
The Purpose of the Sprint Review
The Scrum Guide describes the Sprint Review as an event that “is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed”. It emphasizes that during the Sprint Review, “the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value”.
“Collaboration between the Scrum Team and its stakeholders is key during the Sprint Review”
In other words, the collaboration between the Scrum Team and its stakeholders is key during the Sprint Review. In Scrum, we understand that product development is a complex activity. As we do the work, both the problem we’re trying to solve and the optimal solution will emerge from what we learn during development. The Sprint Review is a critical opportunity in Scrum to make this possible by letting insights emerge from the work that was done and to build on them to inform the next steps.
The Sprint Review is about making the state of the product (Increment) and the Product Backlog transparent. The Scrum Team and stakeholders then inspect both and share insights on what was learned from that inspection. Together with current market conditions, organizational changes, budget, and timeline, they decide together on next steps. The output of the Sprint Review consists of adjustments to the Product Backlog based on what was learned. In a sense, the Sprint Review is about answering the question: “Based on what we learned this Sprint, what are the next steps?”. This provides valuable input for the Sprint Planning.
Optimally, the Sprint Review has the following characteristics:
Stakeholders and members of the Development Team would be indistinguishable to an outsider;
Participants are actively invited to offer feedback, suggestions, and ideas;
The Product Backlog has a prominent place during the Sprint Review, and is actively adjusted as new insights emerge;
Rather than the Development Team presenting the Increment to the Product Owner, the Sprint Review is more about the entire Scrum Team (the Product Owner included) sharing the Increment with stakeholders;
The Product Owner discusses the Product Backlog and communicates likely completion dates based on the progress;
Reiterate the purpose of the Sprint Review before you start. Make sure that people understand that the event is about gathering feedback and navigating complexity together, not ‘selling the product’ or ‘accepting done work’;
Ask members of the Development Team to pair up with stakeholders and inspect the increment together. Instead of having the developer demonstrate the Increment on a tablet, laptop or desktop, give the keyboard/device to the stakeholder and let them experiment under the guidance of the developer;
Avoid Powerpoint or screenshots as a means to inspect the state of the Increment. Clicking through working software really is the best way to validate assumptions and interpretations of developers, users and other stakeholders;
Make sure that all developers attend the Sprint Review. The Sprint Review is an ideal opportunity to gather feedback on the product as improved/extended/updated by developers during the Sprint. Best case, the Sprint Review acts as a great motivating event with stakeholders that are truly engaged with the progress of the Scrum Team and are eager to see and discuss the results;
Use active formats, don’t sit around a table looking at a screen. Use facilitation techniques (like Liberating Structures) to actively engage all participants. The Sprint Review should be a ‘feedback party’, not a Development Team going through a laundry list of ‘work completed’ while everyone else falls asleep. Use format such as 1-2-4-ALL, Shift & Share or a carousel to break down larger groups into rotating pairs of small groups. Use Impromptu Networking or What, So What, Now What after inspecting the Increment to explore next steps or offer suggestions for the Product Backlog;
Invite real users to the Sprint Review. These are the people that (will) actually use the product, and are most capable of determining if the product ‘works well’. Do try to avoid turning the Sprint Review into a ‘user acceptance test’ though;
Change the format. Vary the format of the Sprint Review based on context. Sometimes, it works best to set up different ‘market stalls’ where developers set up to highlight particular aspects of the product. Sometimes a central demonstration with a facilitated discussion afterwards works best. A Scrum Team should continuously search for the best way to gather feedback from stakeholders;
As part of the closing, ask participants what can be done to (further) improve the value of the Sprint Review based on how it went;
Invite participants with an e-mail, newsletter or personal invitation to attend, explaining why their presence is important;
Be open and transparent aboutundone work. Not all Scrum Trainers agree that sharing undone work is a good idea as it may create false expectations. But we feel that valuable insights can emerge from inspecting the work that was not completed. It may tell us something about impediments, bottlenecks or other issues. Focus on identifying these issues during the Sprint Review, but leave their resolution to the Sprint Retrospective;
In this blog post, we busted the myth that the Sprint Review is about demo-ing the Increment to stakeholders. Although a demo certainly can be part of a Sprint Review, it fails to capture what the Sprint Review is actually about: a collaboration between the Scrum Team and stakeholders to inspect the increment and progress to date and decide on the most valuable next steps.
What do you think about this myth? Do you recognize the Sprint Review being only a demo? What are your lessons learned?
Want to separate Scrum from the myths? Join our Professional Scrum Master or Scrum Master Advanced courses (in Dutch or English). We guarantee a unique, eye-opening experience that is 100% free of PowerPoint, highly interactive and serious-but-fun. Check out our public courses (Dutch) or contact us for in-house or English courses. Check out the previous episodes here (1, 2, 3, 4 , 5, 6, 7, 8, 9, 10 and 11).
Being a professional with a disability is like working two careers:
The one I get compensation for - leading organizations to adapt continuous change.
The other career - managing an organization of personal support workers to allow me to have a full life.
This post about the later, managing my care. Recently I came to the realization that not every professional in the world has to deal with this…and it is a very stressful activity. Before I go any further, I recognize that everyone has things to do in the morning to start their day…and I’m not saying mine is more, rather unique.
With my Cerebral Palsy (CP) I need help getting up in the morning to get out of bed, dress, help with my workout, shower, shave, and dress for work. I hire personal support workers to help me with this. Although my wife assists me in emergencies and vacations…I prefer to keep the role as wife and support worker separate. I am responsible to recruit, interview, hire, train and manage my support workers. I have a well refined process or each step in my morning routine which requires details that if they are overlooked is the difference between an ordinary day and a disastrous day.
There are a lot of great personal support workers out there. The challenge is that I can only offer 5.5 hours a day. I’m competing against other employers like nursing homes, group homes, etc. that can offer full-time hours, benefits, and a lot of flexibility for time off as they have a full staff of people to cover one another. I employ 2 personal support workers that coordinate time off with one another.
I have a huge need for reliability and dependability for the morning shifts. Being a professional, I cannot miss work unexpectedly or be late as it might be weeks or months before I can get back in Executive’s calendars or make decisions in important meetings.
My day starts at 5am. When I mentioned the details, the margin of error in aligning my shirt, pants, underwear is millimetres. It’s the difference between being comfortable all day & able to use the washroom and pressure soars, being uncomfortable all day, and washroom accidents. Once I leave for work, I’m locked in until I get home…I don’t have the luxury of adjusting clothes myself throughout the day.
I need the trust that someone will show up…on time. If they are late it causes instant anxiety as I am trapped in bed and my wife has to start rearranging her morning to backfill.
A lot of resumes
A few weeks ago, one of my helpers gave their notice. They had a full-time offer somewhere else. Although they gave two weeks notice, it was a week before I left for vacation. Immediately I had to post a job description on job boards. My best case is that I would have someone selected before vacation and onboard/train them when I returned from vacation. I received 40 resumes, screened them, and conducted phone interviews to decide who I would bring in for a face to face interview. I conducted 28 phone interviews describing the role and emphasizing the need for dependability. One person said, “5am is a little early for me, can I do 9am?”. Unfortunately, my Cerebral Palsy wakes up when I do…so I passed.
The week before vacation I managed to schedule 4 interviews with my wife and me. It’s important to have my wife involved in the selection process as these people will be in our home. None of them showed up. I left for vacation and extended the job posting.
When I returned I screened 45 resumes, 20 phone screens, and scheduled 4 face to face interviews. Only one showed for their interview. Luckily, this candidate had experience working with a professional with a disability.
This week they start and I had to put a schedule together for training. This week I have critical meetings and presentations first thing 3 out of the 5 mornings. Luckily I found 2 consecutive days that I can afford to be late. Training causes me the biggest anxiety in the process. I have to be ‘on’ and sensitive to articulate and explain every detail of showering, dressing , etc. The morning routine will be 50% longer. I will be incredibly vulnerable as I will be naked in front of someone that was a perfect stranger only days ago. I will likely be dropped, fall down, and be pinched.
Vulnerability of being exposed and defenseless
There is a light at the end of the tunnel. After a couple weeks this will be a common routine to the new worker and it will be our new normal. Until they move on to a job with more hours…than it starts all over again.
This is my normal. I’m not complaining as this allows me to go to engage with my passion and work with a lot of incredible individuals. All of the above has made me the leader and change agent that I am today. These skills and experiences has gave me the grit to build great products and organizations.
I am so thankful to all my co-workers and boss who immediately asked what they could do to help me through this difficult time. Their offering of support made me forget about what I was going through for a moment.
I am blessed for my amazing wife. Without her support and love…this would be unbearable.
Now I need to spend some time preparing this week for the job I get paid for. Until next time...
Recently I worked with a new customer in Denver to help them move towards a greater degree of Scrum in their software development. The idea that Scrum is for everyone in your organisation is kind of new, but it reflects the modern understanding of the way people work, and the rejection of Taylorism and command and control. You cant use someone else approaches to get to agility, but you can learn from it.
Professional Scrum is for everyone in your organisation
Armed with previous experience with Scrum.org, the PSF class, and me; the CIO, CJ Singh, asked me to come along and train as many people as we could in the time that we had available. Turns out that looked like 147 people from the engineering department, and my did we had a lot of fun. While they have been constantly moving towards a greater degree of value delivery there were a lot of misconceptions built up about Scrum over the last 8 years… those misconceptions were creating a glass ceiling and inhibiting the flow of value to the business.
This is the second time that I have worked with CJ, and again he excelled at helping his team understand that it is the makers that are the ones that get things done. They are the ingenuity that delivers the value that is needed by the business and they are the ones that need to be nurtured. Without the makers coming up with ideas there would be no company, and there would be no ideas; no backlog.
I previously worked with CJ at Backcountry in Utah where I trained everyone in the company. I still get emails from folks from Backcountry, even 5 years later, and many folks considered the experience of going through the PSF class as “a game changer” for them.
The purpose of the PSF class is to not only to level set everyone on Scrum but to give them a very real understanding of what is required to get significant value from it. If, like at Backcountry (Utah), Healthgrades (Colorado), Fraedom (England), Teleplan (Norway), and HESA, I can get everyone in the organisation to participate something then interesting happens. There is enough of a catalyst, a tipping point, that starts the snowball of change rolling.
Conversations and discussion is the point
The conversations that take place over the 2-day class are ones that don’t normally take place and all of the Professional Scrum classes are designed to get people talking about their issues and what experiments might be useful to find the right way.
At Backcountry I had everyone from the CTO to the guy that drove the forklift in the warehouse. That’s right, everyone… including the CEO’s assistant… Because everyone in your organisation has good ideas, many are direct stakeholders. Getting them to feel that they are empowered to make suggestions and to have ideas is part of Agility. Getting the CEO to hear all of the questions, and discussion, around why things are not running as smoothly as they could be, and what would need to change to make that happen is invaluable. Getting the Stakeholders to understand what it takes to build software opens their eyes to the involvement they need to have in the process. Getting the developers to hear the business realities that create the pressures again changes the conversation. How can you possibly hope to change your organisation unless everyone is on board and going in the same direction?
nkdAgility Healthgrades Interview Dave Frisch - YouTube
As with all courses where one trains everyone there are usually many dissenters. Folks that don’t want to be there because they think that they know everything or they just don’t think it will be valuable. David was in the “were doing Scrum already so why bother” category, but it only took 4 hours of the class for him to realise how much his understanding had deviated from core Scrum. The fundamental understanding of how Scrum implements empiricism is something that not only do we need to know, but it’s nice to have a reset every so often so that we remember the reasons why.
Creating a bounded environment for change
So many teams I work with across the world forget, or never knew in the first place, why we have things in Scrum. They forget that we need the transparency of the past provided by the Increment of Working Software. They forget that without the Product Backlog we get no transparency on what we are doing next, and without the Sprint Backlog, we have no visibility into what we are doing now. They forget that without that transparency there can be no meaningful inspection of what is going on at each of the Events and no meaningful change to the way that things happen.
Many attendees of the Professional Scrum Foundations at all of the companies I have done it for, regardless of their existing knowledge level, come away with a new appreciation for Scrum, its Artefacts, its Events, and its Rolls. Even experienced Scrum Masters like Katherine has something to learn and find value in the reset. Its easy to become complacent with the organisational dysfunctions that are the “way that things are done here”. I worked closely with Katherine to make sure each of the 6 class that we ran went smoothly and facilitated the right discussions.
Just as Scrum creates a bounded environment so that we can all be going in the same direction in our work, so the Professional Scrum classes create a guided environment for discussion and revelation.
Iteratively tailored training not content
Each instance of the PSF class I learned new things about the organisation, its employees, and how it operated that helped me guide the classes to a better understanding of Scrum. I use the same material as every other accredited Scrum.org trainer worldwide, and I tailored the path. I learned which things we can skip over, and which we need to dive headlong into. Some of the experiences were traumatic, and the discussions heated, and by the end, there was not a single detractor from agility or Scrum in those that went through the classes.
Healthgrades now has 147 people are the pioneers, evangelists, and change agents that now feel empowered to make meaningful change.
One of the outcomes of the Professional Scrum Foundations, along with the new knowledge and excitement, is an organisational change backlog. One that has been created by those that are doing the work and understand the constraints and challenges of the work. The hope is that management then uses the Agility Guide for Evidence-based Management to facilitate changes in the organisation to get rid of those pesky impediments to value delivery that are out with the control of the teams.
Healthgrades now has a Backlog of things that need to change in order to facilitate meaningful change.
With these two things, agile torchbearers who feel empowered and a list of changes, I am hoping that Healthgrades can change their organisation and increase their ability to take advantage of market opportunities as they arise, and out-manoeuvre their competitors with ease. Refine backlog facilitate meaningful change.
Liberating Structures are 33 microstructures that allow you to unleash and involve everyone in a group – from extroverted to introverted and from leaders to followers. In this series of posts, we show how Liberating Structures can be used to spice up your Scrum Events. Move away from the stickies and the whiteboards for a moment, and explore these novel facilitation techniques. If you’d like to experience Liberating Structures first-hand, make sure to join one of the ‘immersion workshops’ that are taking place in March 2018.
Many people know the Five Whys from the Toyota Production System and incorrectly assume that the Liberating Structure Nine Whys is the same with a few extra Whys thrown in. While the Five Whys are used to trace a defect back to a faulty process Nine Whys helps teams identify their purpose.
A purpose is the main reason for working together, “an inexhaustible reason for a group to exist”. As such it is absolutely fundamental for collaboration, yet usually opaque or forgotten. A clear purpose helps teams align toward a shared goal and as a result gives meaning to all Scrum events.
In this post, we’ll share examples of how we’ve applied this structure within our Scrum training and coaching engagements.
Uses in Scrum and workshops
We have used Nine Whys for a number of applications in (and outside) Scrum:
For Scrum teams as part of a team liftoff to identify the deepest reason for working together;
For product kick-offs to clarify and communicate why the product should exist;
As part of strategy and roadmapping initiatives to first clarify purpose and then actual goals;
For Agile transition teams to shape the direction and intention of the change;
Steps to use this Liberating Structure
Ask participants to get in pairs. Invite them to look at their current activities and slowly dig deeper to reveal the deepest reason for the group to work together. To get this started, participants will have to decide who is going to be the interviewer and who’s going to be the interviewee in the first round.
The interviewer then asks the interviewee to make a short list of the most important things they do in their daily work to help the team make progress. This can include things like “Making the UI of product xy more accessible,” “setting up Docker containers,” or “fixing broken laptops.” 1 minute
The interviewer then helps the interviewee find a deeper purpose behind these activities by repeatedly asking questions with why like “Why is that important to you?”, “Why is that important to our customers?” and “Why is it important to our society?” The participants switch roles after five minutes.
The pairs get into groups of four and share their insights for five minutes.
The whole group shares their discoveries. Participants pay attention to an emerging group purpose.
There is often significant overlap between the individual purposes that emerge. Invite the group to craft a purpose statement that begins with “We exist to start…” or “We exist to stop…” if possible. The most important part, however, is that the group feels like their statement rings true and creates excitement.
A story from the trenches
A team in a major logistics company felt like they were lacking direction and meaning. Only writing one part of an application used for organizing shipments didn't feel particularly significant. We used Nine Whys and a team member shared a story he called “My son's bicycle”. He told us how he had ordered a new bicycle for his son from overseas. After a long waiting period, he received a letter telling him to pick up the parcel at the harbor. His son jumped up and down and couldn't contain his excitement. He kept telling his father what cool things he would do with his new bike during the drive there. When they arrived the team member snuck a peek at the clerk's monitor and saw that she was using a piece of software he had written himself. He told his son and his eyes went wide. He was so impressed that his dad helped him get his new bike across the ocean into his hands.
The other team members sat in stunned silence. After a while some admitted that they had never seen it that way, resorting to crude cynicism about their meaningless jobs instead. The team realized that they often didn't get to see the fruit of their labors but that they worked together to help people around the world get things they really needed.
Stringing together with other Liberating Structures
Nine Whys is a great start for a whole Purpose to Practice session. This Liberating Structure is going to help you decide what principles you must follow, whom to include, what structure to choose and what practices to follow in order to make your purpose come to life.
Use Wicked Questions to identify the hidden paradoxical challenges associated with your purpose.
Use Appreciate Interviews to share a success story and then segue into Nine Whys, using the story as the starting point.
Traditional organizational design unconsciously keeps teams separated from a true purpose. Only the higher-ups really know why something is being done. We've worked with teams where looking for a deep purpose became frustrating as it only highlighted that they were merely a cog in the machine. Using Nine Whys in this scenario can help change initiatives get started (getting teams on a quest for a true purpose) or it can destroy morale. If you fear that might happen, maybe try a more traditional mission statement instead.
The purpose has several layers. You can always go deeper or more shallow. You have found the right level when the purpose statement feels gripping, exciting and ambitious.
A purpose is never truly final. It's often a good idea to take a purpose statement for a “test drive”, see if it rings true in daily life and then sharpen it later on. Beautiful and deep discussions will emerge!
In this article, we’ve shared examples of how we've applied Nine Whys within our Scrum training and coaching engagements. We’re always happy to hear your experiences or hear your suggestions. If you’d like to know more about Liberating Structures or experience a large number of them first-hand, sign-up for one of the workshops that are taking place throughout Europe in March 2018. They will be facilitated by co-inventor Keith McCandless and pioneer Fisher Qua.
Read Full Article
Read for later
Articles marked as Favorite are saved for later viewing.
Scroll to Top
Separate tags by commas
To access this feature, please upgrade your account.