Scrum Project Simulation Game

2017 03 01

Author: Oksana Cybulskaja

From time to time Baltic Amadeus gathers a group of students from the first courses of university IT studies, introduces them to details and everyday routines of IT development process and then offers the best students a permanent job at the company where they would continue learning and gaining expertise participating in the real projects. This year I met a challenge to explain them how Agile development works and how it is applied in Scrum. Since Scrum endorses a practical approach to development I decided not to bother too much with theory lessons and setup a game where students would have to build a toy house using as much of Scrum as possible. More over, my colleague has already introduced the students to the Scrum theory, so this sounded like a good plan to try newly gained skills in practice.

PREPARATION

Students were given a short introduction to how basic Scrum process is organized and then were assigned different Scrum roles. We had 13 people and the roles were distributed as follows: 3 Business representatives, 1 Product Owner (PO), 1 Scrum Master, 8 Development team members. I have prepared in advance lottery tickets so that we could assign roles randomly and in a fair fashion but this came out to be unnecessary. First I asked who wanted to be Business and the most active people, smart (or lazy) enough to delegate hard work to others, quickly volunteered. Next two places – PO and SM – were taken by students who were also active but wanted to take on challenges. The rest of the group became developers but they mostly seemed to be OK to go with the flow and gladly accepted the default.

Once the roles were assigned the objective of the project was presented. The development team must build a house out of Lego bricks according to Business’ wishes that will be expressed later. The whole project will take three sprints, 5 minutes each. Also, business will mostly work abroad (in our case we set up a different room and called it Norway), meaning the team will not see them for the most of the time and PO will have to balance the visits to Business with simple phone calls, saving money.

After the briefing was done Business relocated to a different room so that they cannot communicate with the team directly and the team cannot see what the Business is doing.

Once separated, the Business is instructed to come up with an idea for their project. I suggested it must be a country-side tourism villa. In 5 minutes Business has to decide on some details of the design and draw it. This part required some moderation since we had 3 business people and they all had their own ideas. Finally the picture was complete after 10 minutes.

studentai3Meanwhile the development team was doing R&D – they were analyzing what parts they had to work with (colors, sizes and types of pieces) and were experimenting with some structure prototypes. PO was observing the team and noting their capabilities and resources that team is going to work with. When the Business was ready PO went to visit them to get initial requirements while the team continued their experiments.

INITIAL REQUIREMENTS

During their first visit PO had to inquire Business about the project scope. PO could see the picture the Business had prepared but he had to talk with them and produce 10 User Stories and have them prioritized. We did not set the time limit on this initially but the whole process took about 20 minutes. My colleague Marius Šaučiūnas was assisting PO to answer questions and gently guide him when necessary.

Interestingly enough, since PO already knew about the time frame and the team potential, it impacted initial negotiations with the Business. Some of the Business’ ideas were discarded and some were lowered in priority because they could not be built before other parts. Of course, some of the produced User Stories were better than others, but this stage they did not have to be ideal so that the team could actually experience the effects of badly prepared requirements.

After PO returned with initial set of requirements they sat with the team in the first grooming session. PO had to present the Business vision and then each of the User Stories he had got. The Business was not present and PO could not bring anything else from Business trip (in particular, the picture that the Business had prepared was actually hidden from business too so that they wouldn’t fix on it). Here the team asked questions, evaluated if they could actually build what was required and provided suggestions. Scrum Master had to ensure that Scrum rules were followed but this time I had to advise her to make sure that every US could be performed in one sprint.

As a result of the grooming initial US were split and commented. PO then took another trip to Norway and had an additional session with the Business so that they would agree on the new US and could also clarify some of the requirements. After PO returned they had a smaller session with the team again so that the relevant changes could be discussed. Then the project was given official start.

SPRINTS

The whole project had to be implemented in 3 sprints. Each sprint had the same structure:

• Sprint planning. Team, with PO present to answer some urgent questions, had to select US from backlog and commit to implement them.
• Sprint itself. After planning the team had 5 minutes of development work.
• Grooming. In the middle of the sprint PO came in and presented updates on the backlog so that he would have time to work with Business until the start of the next sprint.
• Demo. The Business would come to the demonstration of the sprint result.
• Retrospective. Team would discuss how the sprint went and what could be improved in a format of Start doing/Stop doing/Keep doing.

The first sprint had failed because the team overestimated their abilities and also did not have a single understanding of the sprint target. For example, in the Business vision there had to be a swimming pool on the roof, but it was not part of the first sprint. Some team members assumed that the building did not need a roof after first sprint since it would have to be rebuilt later anyway. This was not shared by all team members and, crucially, by the business. They argued that a building without roof was not usable. They also noticed that not all of the rooms in the building had doors. This was not explicitly specified in the US so the team left some of the rooms without doors. The Business didn’t like it and they insisted that PO should have understood that when they were talking previously. Anyway, all the defects of the implementation were recorded in the backlog as bugs and then prioritized by Business and PO before the next sprint. During the retrospective the team blamed PO for not providing accurate information in the US.

The second sprint went more smoothly. Planning was faster because the team had a better understanding of what needs to be done and PO also had more in-depth knowledge about the project since he took the results of last retrospective seriously and wanted to improve. The whole sprint scope was done in time with the bugs of last sprint fixed. Demo part in general went better also. During the first sprint the PO did not know how to present the result – he simply wanted to point at the table and say ‘here it is’. This time the team went through the sprint backlog explaining what has been implemented and how. One interesting point came up when Business wanted to check if all rooms had their doors finally installed. The team claimed they did what was asked but because there was a roof now on top of the building it was hard to see inside. For the sake of demonstration the roof had to be removed to satisfy Business concerns. Another funny thing happened just after the demo when Business was about to leave. One of the developers wanted to “fix” one of the arcs so that it could hold more tightly and accidentally detached the whole garage from the main building. Although this was taken with laughter there was never a better time to explain the meaning of “if it ain’t broke, don’t fix it”.

The third and final sprint would have gone perfectly because everyone got used to working together but since it was the last sprint of the project there had to be some challenges. At first the Business called PO in the middle of the sprint and asked to do last minute changes – the pool on the roof had to be additionally decorated with palm trees. PO had to take it with the team and the team accepted the scope increase. However, this part needed additional moderation since both PO and team were ready to accept the scope increase too easily. Scrum Master was instructed that the team was seeing the new requirements for the first time and there was a risk of incomplete understanding. PO was advised that since it was the last sprint they needed to think about the bottom line of the project and that fixed price contract might limit how much additional work can be performed. To make matters worse, I came in shortly afterwards, presented myself as a higher management of our company and asked some of the developers to be diverted to other projects. Scrum Master and Product Owner had to present good reasons why this shouldn’t be done and they have managed to keep the team intact until the end of the project.

PROJECT FINISH AND INSIGHTS

After the project has finished all the participants gathered again to reflect on some of the aspects of the training. Here are the most important things that have been noted:

• Importance of Product Owner. The team criticized him during the first sprint and he improved over the next two.
• Documentation. Business argued that PO should have understood that all rooms had to have doors but this was not reflected anywhere, probably because it was assumed to be obvious.
• Research. Initial analysis and concept structures before the start of the project helped the team and PO to understand their abilities.
• Business involvement. The initial Business picture of their vision was revealed and compared to the final result. There were notable differences, especially in the magnitude of project – the first vision included 5 times more rooms, additional leisure buildings and a helicopter pad. Despite the differences the Business was happy with the result.
• Quality. Garage detaching from the main building is not something that should normally happen.
• Demonstrability. The roof had to be detached to demonstrate that all rooms have doors.
• Manageable units of work. Large User Stories had to be broken down to smaller ones, some of which could be postponed or even pushed out of scope.

SUGGESTIONS FOR THE FUTURE

While in general the game was a success and it was also well received by the students themselves, it was only an introduction to the difficult practice of Scrum. The whole training took about 3 hours. If there were more time, additional concepts could be investigated. For example, we did not ask the team to evaluate the effort needed to implement the US, we did not have Epics or Tasks, and we did not stress the importance of quality (except by noting mishaps). As the game progresses, more risk scenarios can be introduced. Actually removing a team member as if he was sick, Business giving misleading requirements that would turn out to be more work than anticipated, pair programming to ensure accurate reproduction of requested pattern – these are only the first ones that come to mind. Clearly, there is plenty of room to experiment and improve, and I hope that our experience would help you to get there.