In May this year Valori piloted a serious game in which participants experience the challenges of inter-team collaboration and gain insight in the various scaling agile frameworks. Eric van de Mark, guild lead of the agile guild at Valori, explains: “Previously we developed a serious game which we call the ScrumBattle. In this simulation teams learn how it feels to work in a continues improving agile team. It’s a great way to introduce agile in an organization, but we wanted to add an extra layer: scaling agile.”
Scaling agile is becoming a hot topic. Most organizations have at least a few teams that do Scrum, and adopt the agile values. Experience learns that once these teams get going, other bottlenecks in the organizations come to surface. Typically these problems surface in the what I like to call the supply and outlet channels.
The supply channel describes how business ideas are translated into workable items that are picked up by the development teams. Not so difficult if there is only one team, a challenge when more teams are working on the same product or system. Ideas still need to be refined and chunked into smaller bits, so they eventually become user stories that fit the sprint. But when working with multiple teams, dependencies and team skills determine the planning. When multiple teams are working on the same product of system their work needs to be integrated, tested and released. In practice we see organizations defining integration sprints, set up integration teams or adopt continues integration and deployment. Whatever form they choose, this defines outlet channel.
When organizing these supply and outlet channels in order to have a better business-IT alignment and have a shorter lead-time for new ideas to become implemented one is scaling agile. Scaling is difficult,. Once you multiply the size of the agile adoption the deficiencies and problems that reside in the single teams are increased as well. Luckily, there are several frameworks, like LESS, Nexus and SAFe, that provide handhelds and guidelines. But, what framework should you adopt?
In the simulation we piloted on the TestNet Spring Event (the annual event of the Dutch Test Association) we worked towards an better understanding of the scaling challenges. The workshop starts off with a short Introduction and comparison of the three before-mentioned frameworks. But, soon groups are made and the participants get to work. They have to build a city using Lego. That has been done before, and the Certified Agile Testers (CAT) might recognize the set-up. But beware! This game is all about scaling. So all teams are working on the same project, a greenfield city that is due to welcome its first inhabitants in a short time.
During the game participants learn that independent teamwork doesn’t work. In the first sprint each team has its own backlog and it takes the first sprint review to realize that standards and planning fail due to a lack communication and insight in the work done by the other teams. Interesting is how the teams start to organize themselves and make inter-team agreements. A simple improvement is to merge the backlog. The Product Owner started the game with assigning the work. Teams quickly stand up, hold a collective sprint planning and decide for themselves what work they pull into the sprint.
Throughout the game the various scaling frameworks are highlighted so participants get an understanding how e.g. Nexus does its Retrospective and SAFe does its increment planning. Since the theory is interwoven with the game, it remains lively and playful. A lot of mistakes were made, and not all teams were in line all the time. But, be honest, are they in you organization?
As the game progresses, the game the backlog items increase in size. The emphasis shifts therefore from agreeing on the standards to real collaboration. I believe the game does this in a natural way and in the last sprint, all the teams are working on one single item. Nice to see that when teams are really collaborating the integration and testing become truly important. Mistakes are easily made when everyone is working hard during the sprint, and testing and early integration will identify the errors being made. I noticed that during the game the teams experienced that an efficient outlet channel starts with clear agreements upfront. The supply line and outlet channel are not as independent as they seem, and they merge. In our pilot session, we saw that happen while working on that one single epic. Clearly building a Lego city isn’t as complicated as building software system, but I am proud that we almost managed to complete our epic in a single sprint. Can you imagine all the teams in your department really working together to finish an epic in a one or two sprints? I know many organization that can only dream about this scenario.
I believe we all had an interesting learning experience and left the room with new insights and a better understanding of scaling agile, its frameworks and its challenges. If you want to learn more about Valori’s “a game called scaling” and whether it would be interesting for you organization, please do not hesitate to contact us.