Blog
(Virtual) Scrum training for R&D
Can an R&D team of chemists, physicists, electrical engineers, mechanical engineers and embedded software developers optimize teamwork and value by using Scrum? And can virtual Scrum training deliver a practical Scrum learning experience to everyone on such a functionally diverse team?
These were the two questions one of our customers asked.
Throughout our conversation, we learned more about the team, and we quickly agreed that their work of applied research and technology development includes lots of complexity. When they start a new initiative, a lot more is unknown than known to them, and only through research, experimentation and development they learn more about what is feasible and applicable. So, being empirical, one of the essential principles of Scrum, is already a big part of their work. At the same time, they were striving to improve focus and self-organization especially in the context of COVID-19 which forced them to distribute and collaborate remotely.
So, yes. Scrum could be helpful in becoming a more focused and self-organized team.
The second question was a bit more difficult to answer. If the Scrum training was an in-person class, we would have had a complex challenge at hand. A challenge that would stimulate everyone on that R&D team to build and integrate mechanical and electric hardware as well as embedded software into an Increment. However, onsite training was clearly not an option due to COVID-19, and the Scrum training would have to be delivered virtually. We felt that a purely digital challenge (as in ""build this software…"") wouldn't create a Scrum learning experience that would work for everyone on a team with such a diverse range of backgrounds in chemistry, physics, electrical engineering, mechanical engineering and software development. So, we had to think about how to create an immersive experience for all of them.
That's where our amazing community of Professional Scrum Trainers (PST) at Scrum.org* came into play. We reached out to a fellow of our own PST Johannes Geske, Simon Bourk, a PST from Ottawa, Canada. He knew that he was experimenting with Minecraft Education for his Scrum training. For those of you who don't know Minecraft, it's a building block game where you can build your own world and environment. We told my customer that we had an idea that we wanted to explore a bit further to see if it worked and then get back to him. We then contacted Simon and he invited Johannes to join his live virtual Scrum class where he would use Minecraft Education for the first time. So, Johannes joined his training where he became part of a team with equally different backgrounds.
In Minecraft Simon wanted the to build a campground. The team started at a clearing in a forest, and the first objective was to be prepared to survive the night. First and foremost, that meant the team had to build a shelter big enough for the entire team, because in Minecraft dangerous things can happen at night.
None of the participants was really experienced with Minecraft, so a lot more was unknown than known in the beginning. On the first Minecraft day, that's 20 minutes in real time, a lot of unexpected things happened: Johannes' character fell into a cavern filled with water and almost drowned before his teammates managed to find him and dig a way out. Another character on the team was trapped in a fire and couldn't get out, and no one noticed until the character "died".
Simon expected the shelter to be a log cabin that among other things would have a furnace to prepare food. That required the team to coordinate and collaborate to create logs, build the cabin, mine coal and stone to create the furnace and hunt for food. Over time, everyone became more experienced. However, the team had one person who actually had a lot more Minecraft experience. Until then, this person had politely restrained himself, but then he tried to reach our next goal all by himself and entrusted the rest of the participants with irrelevant tasks. In the end, he wasn't successful and the entire team failed to reach the objective.
After each Minecraft day, the team took some time to check what they did, how they did and what they would do differently next time.
How is all that relevant to learn about and experience Scrum?
Simon designed a scenario in a way that everything in Minecraft was a metaphor for Scrum and things teams experience in the real world. Everything was a metaphor. With that in mind, read this annotated version of the above scenario:
In Minecraft Education Simon [Product Owner] wanted the team to build a campground [product goal]. The team started at a clearing in a forest, and the first objective was to be prepared to survive the night [Sprint Goal]. First and foremost, that meant the team had to build a shelter big enough for everyone [Increment], because in Minecraft dangerous things might happen at night [controlling risk by delivering, releasing and learning early whether the team creates value]. None of the participants was particularly experienced with Minecraft so a lot more was unknown than known in the beginning [complexity]. On the first Minecraft day [Sprint], that is a 20-minute timebox in real time, a lot of unexpected things happened: Johannes' character fell into a cavern filled with water, couldn’t get out [impediment?] and almost drowned before his teammates found it and dug a way out [self-organization]. Another character on the team was trapped in a fire, and no one noticed until the character “died” [Who’s responsible for the team’s well-being in Scrum?].
Simon expected the shelter to be a log cabin that among other things would have a furnace to prepare food [ordered Product Backlog and acceptance criteria]. That required the team to coordinate and collaborate [self-organization] to create logs, build the cabin, mine coal and stone to create the furnace and hunt for food [a team that is cross-functional has all the skills required to build the product]. Over time, everyone became more experienced [empiricism]. However, the team had one person who actually had a lot more Minecraft experience. Until then, this person had politely restrained himself [hero dysfunction], but then he tried to reach our next goal all by himself and entrusted the rest of the participants with irrelevant tasks [motivated team?]. In the end, he wasn’t successful and the team failed to reach the objective [In Scrum, the Development Team works as a unit and remains responsible as a whole to deliver a “Done” Increment].
After each Minecraft day, the team took some time to check what we did **[Sprint Review]*, how they did [Sprint Retrospective] and what they would do differently next time [improvements]**.
What did we learn from participating in this Minecraft experiment?
Minecraft helped create an immersive and complex scenario that engaged students from completely different backgrounds, also outside IT, to explore Scrum. They had to work as a team and help each other to create useable Increments and meet their Sprint Goals. The metaphors worked remarkably well to learn how Scrum helps work and create value as a team. At the same time, and that is very important for professional learning, Minecraft wasn’t perceived as a game. It didn’t take away the students’ focus from learning and experiencing Scrum. With that first-hand experience, we can now go back to our customer and share this idea to help the R&D team with its diverse backgrounds and skills to explore Scrum as team.
Thank you, Simon, for this amazing idea and the opportunity to participate in this experiment!
If you want to learn about this experiment and how you as a team can explore Scrum hands-on through a series of Sprints contact us:
Let's talkAuthor:
