Can virtual Scrum training help a non-IT team learn about Scrum? or, Can an R&D team benefit from Scrum?
“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 live virtual Scrum training deliver a practical Scrum learning experience to everyone on such a functionally diverse team?”
These were the two questions one of my customers asked.
Throughout our conversation I 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, I would have 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. I felt that a purely digital challenge (as in “build this software…”) wouldn’t create a Scrum learning experience that would stimulate everyone on a team with such a diverse range of backgrounds in chemistry, physics, electrical engineering, mechanical engineering and software development. So, I 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. I remembered that Simon Bourk, a fellow PST from Ottawa, Canada, 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. I told my customer that I had an idea that I wanted to explore a bit further to see if it worked and then get back to him. I then contacted Simon and he invited me to join his live virtual Scrum class where he would use Minecraft Education for the first time. So, I joined his training where I became part of a team with equally different backgrounds.
In Minecraft Simon wanted us to build a campground. We started at a clearing in a forest, and our first objective was to be prepared to survive the night. First and foremost, that meant we had to build a shelter big enough for our team, because in Minecraft dangerous things can happen at night.
None of us was really experienced with Minecraft, so a lot more was unknown than known to us in the beginning. On the first Minecraft day, that’s 20 minutes in real time, a lot of unexpected things happened: My character fell into a cavern filled with water and almost drowned before my teammates managed to find it and dig a way out. Another character on our team was trapped in a fire and couldn’t get out, and we didn’t notice 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 us to coordinate and collaborate to create logs, build the cabin, mine coal and stone to create the furnace and hunt for food. Over time, we all became more experienced. However, we had one person on our team 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 us with irrelevant tasks. In the end, he wasn’t successful and we all failed to reach the objective.
After each Minecraft day, we took some time to check what we did, how we did and what we would do differently next time.
How is that relevant to learn about 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 us to build a campground [goal aka product vision]. We started at a clearing in a forest, and our first objective was to be prepared to survive the night [Sprint Goal]. First and foremost, that meant we had to build a shelter big enough for our team [Increment], because in Minecraft dangerous things might happen at night [controlling risk by delivering, releasing and learning early whether we create value]. None of us was particularly experienced with Minecraft so a lot more was unknown than known to us 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: My character fell into a cavern filled with water, couldn’t get out [impediment?] and almost drowned before my teammates found it and dug a way out [self-organization]. Another character on our team was trapped in a fire, and we didn’t notice 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 us 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, we all became more experienced [empiricism]. However, we had one person on our team 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 us with irrelevant tasks [motivated team?]. In the end, he wasn’t successful and we all 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, we took some time to check what we did [Sprint Review], how we did [Sprint Retrospective] and what we would do differently next time [improvements].
What did I learn from 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. Instead, it helped communicate Scrum through the metaphors. With that first-hand experience, I can now go back to my 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: