I love Agile games! I was wondering why I didn’t get a chance to know about the Scrum model earlier during my graduate studies. I have worked on various software projects in teams where I had faced issues that could be easily addressed by implementing Scrum. I had worked in teams where there have been difficulties in communicating with the team on regular frequencies, discussions on roadblocks, issues or dependencies when faced and many more. I realized that these difficulties can be addressed easily by following the Scrum model with the help of a Legos activity.
I enjoyed being in the one-day Scrum training program at UPMC Enterprises with all the other Summer Associates and new hires. It was a fun filled day of learning and group activities. The most anticipated activity was the Scrum Lego event. It helped me clearly understand the concepts by practical understanding of Agile methodology as a software development process. I enjoyed being part of this group activity of building a city using Legos and relating it to software development.
In this Scrum Lego game, we were 4 teams of 5 members each working together with a product owner (Hailey Hinkle our Scrum trainer) to construct a city, primarily with Legos. Each scrum team consisted of a Scrum master, responsible for moderating the meetings, dealing with impediments and suggesting improvements to the team. Our product owner began by presenting a prioritized backlog of buildings, facilities and other structures she required, and the teams helped clarify the requirements. We then worked together along with the product owner to estimate and assign points, required to accomplish the task based on the difficulty of the item. The points were assigned by following power of 2 series. If there was a task which required effort between the numbers in a Fibonacci series, where we had to choose 2 and 4 we would go with the higher number and assign those number to the task. We had to build the city in 3 sprints of 7 minutes each. Teams then proceeded by pulling items from the backlog, one by one and starting from the top, that they feel can be finished in the sprint of 7 minutes. The ‘staging city’ was setup on a table covered with a big white chart.
We spent a couple of minutes deciding on the tasks we would be working on as a team. We chose items from the backlog and decided on doing 4 tasks of 4, 8, 16 and 32 point task each among 5 of us in 2 sprints. It was a total of 60 points. During the first sprint we planned to deliver a bridge which was a 4 point task, a one two story building and meanwhile work on setting up things for the other two tasks. As a team we worked on the tasks with a lot of uncertainty as to the difficulty of the task. We were working to meet the acceptance criteria associated with each task provided by the product owner. We assigned one person to work on bridge, two on a two story house, one on a one story departmental store and I was to build a two storied hospital. The plan was that, the person building the bridge would finish the work in sprint 1 and would then help me build during the sprint 2. I had to collect blue blocks from the other 3 teams as my acceptance criteria for the hospital was that the building needed to be completely blue and should have a closed parking garage capable of holding one vehicle.
At the end of sprint 1, our velocity was 0. We had underestimated the points to build a bridge and we had our two story building rejected as we did not meet the acceptance criteria. Other teams did their best and contributed to ‘staging city’ and delivered what they had planned. At the end of sprint 1, we realized that we didn’t ask enough questions of the product owner regarding the acceptance criteria and we decided on a new strategy. So, the teams by the end of sprint 1 re-estimated and pulled a selection of unfinished work into the new sprint.
The team was very worried by this point. With more than 60 points remaining, the velocity was too low for the teams to finish everything. Interestingly, the second sprint saw the implementation of a new strategy. We decided to build building templates. We also had to gather requirements from other team members like the width of the river to build a bridge long enough to cross the river and also the size of vehicle so that our garage would be big enough to house it. We also started to share our work and involve the product owner to check if she liked our work. The ‘staging city’ was populated more frequently with new buildings. We had to redesign the whole bridge and complete the task with the help of other team members. By the end of sprint 2 we had finished all of our estimated points and delivered 64 points during sprint 2. As a team, we had a strong comeback by the end of sprint 2 and the product owner found the results to be more satisfactory. For sprint 3, we did not have any tasks on backlog left, so we helped other team members to finish their tasks, building the complete city model.
We all greatly enjoyed playing this game. It was quite demanding, but we also laughed a lot during the process. The game managed to be great fun for all with a very educational purpose. When done properly, it really provided a very insightful simulation of software development. In short, we highly recommend playing this game and I will certainly make this a regular part of UPMC Enterprises training sessions. I am glad that I had this opportunity to use Legos, relive my childhood, and learn about the Agile Scrum model in a fun filled environment.
Prashanth Ravindragopal, Enterprises Summer Associate