Agile Practices: Building an Arcade Machine with Scrum

Sprint Zero. Getting started.
Yes, we are building an arcade machine!!

It all started during a team lunch. We were talking about vintage video games when the idea of having an arcade machine in the company to enjoy in our free time came up. We realized that we had almost everything we needed to get started and we knew it would be fun to build. So, we proposed the idea to the company to make it happen.

As Uruit encourages agile practices, it was seen as a good opportunity to apply Scrum to a project out of the development realm.

The guy with the original idea came to be the Product Owner , and we found a volunteer Scrum Master. And so, this project became a reality.

Once we had the company’s approval, we needed to determine what we wanted as a final product. Using the Visual Story Mapping technique, we gathered all the requirements, and that became our Product Backlog.

As in traditional projects with Scrum, we refined the backlog, decided to have a two-week sprint and stand up meetings twice a week.

We had our first sprint planning meeting where we chose what had to be done during the first sprint and the sprint goal: to have a computer where we could play vintage games with an emulator running, a sound system and joysticks. That represents the core of the arcade machine, our minimum viable product.

Sprint 1 – A good start
The first Planning of the project was made. It was resolved that the sprint goal would be the first version of the product: having something, in two weeks time, that would be valuable for possible users of the Arcade Machine; i.e. a screen connected to a pc with a Mame emulator installed and two joysticks for playing.

The team was motivated by this undertaking, and tried to get the initial materials to get started.

The old 21’’ CRT that first motivated this initiative was brought; Uruit gave us a machine, and a team member some speakers and Xbox joysticks.

Also, a budget was drawn for buying the materials needed in order to continue working in the following sprints, which included, among others, joysticks, wood and screws.

So, for the first Sprint Review, the Arcade Machine v 0.1 was ready for Uruiters to play.

This first version wasn’t visually appealing; it had a lot of bugs and it wasn’t even close to the final product, but it allowed us to prove an extremely important point: our possible users loved the idea.

Sprint 2 – Not all that glitters is gold
The second Planning was held, team’s motivation was still high, and many stories were chosen for the following two weeks; but this time, the goal wasn’t so clear.

We resolved to tighten the budget; buy the joysticks, wood, and screws; mark and cut the wood; try several emulators; make a stencil design; spread our work within our company; write these posts… Anyway, a lot of work.

What do you think happened? Reality hit us hard in the face. Even though we were motivated, everyone had obligations within our corresponding projects, and, of course, a life aside from the 8-working-hours.

Typical problems in a project were now our own: we had a tight budget, limited resources, and we had committed ourselves to having every story finished in two weeks.

We started having problems for holding Standups at a suitable time for everyone; we changed schedules once and again, but it wasn’t possible to coordinate the team.

The result wasn’t good. At the end of the sprint, we only had two stories finished, the joysticks (brought from China in less than 10 days, quite an achievement), and little spreading of our goal to the rest of the company.

Team’s morale was low, but thanks to Scrum we had the Retrospective for venting. As expected, we did a little of catharsis during the second Retrospective for a sprint that didn’t come out as we hoped. Later, we started to try solving some of our problems; we determined Standups to be held at noon for everyone to assist; we agreed not to take so many stories and we added that we had to have a clearer goal for the next sprint.

Sprint 3. The Absent Product Owner Syndrome

Some minutes after the second Sprint Retrospective, we held the third Sprint Planning. We took into account what we had said and chose fewer stories; we coordinated the Standups times; we established clearer goals. We thought everything would get better.

It is worth mentioning that we hold Reviews and Retrospectives of sprints that are in progress followed by the next sprint Planning in order to minimize days and length of meetings. We named this meeting the RRP (Review-Retro-Planning). Usually, it takes no longer than an hour.

The sprint started well, but we encountered another obstacle. We hadn’t taken into account a very important fact: our Product Owner, the original promoter of the idea, was taking a two-week holiday, which would occur at the same time as almost the entirety of the sprint. We then suffered what I call the Absent Product Owner Syndrome; the person with the business vision and one of the most interested people in the future of the project was going to be absent.

We carried on with the sprint, but the team wasn’t living its best moment. Stories were too big, which resulted in only one finished story. Commitment with the project had decreased so much that only 3 out of 8 people of the team were present at the Review and later at the Retrospective.

So, we asked ourselves what we could do to motivate the team once again. Using this question as a basis, we came up with some good ideas.

We realized that the team was a distributed team; even though we all worked together in the same company, we were all in different rooms, and our schedules for working in the Arcade Machine project were different. Distributed Scrum Primer focuses on the importance of communication; bearing this in mind, we decided to create a diffusion team to insist on the participation in meetings as well as communicating anything related to the project effectively through Skype.

We saw that we were working on much too big stories and progress was difficult to notice. We all know that seeing something at a standstill is no motivation at all, so we decided to divide the stories into smaller ones keeping in mind that seeing movement would create more movement.

We came to the conclusion that we had to give more importance to the key tasks of each sprint in order to achieve the goals. We thought it would be good to highlight the stories by marking them with a star.

Finally, we decided to improve the taskboard for a greater visual impact to the inertia we expected to create.

Hoping these new actions would make the project to take off again, we started the fourth sprint.

Sprint 4 – The results of a good retrospective

After a disastrous third sprint, we put all ideas that came up during the last retrospective into practice in order to put the project on the right track once more.

We created a Skype group for all team members, which was used to notify them, 5 minutes before, of the first Standup. Surprisingly, all members were present, including the Product Owner who had already returned from his holiday.

We put everybody up to speed on the project status looking at the new taskboard, and we divided the stories. During this sprint, we had, again, a clear goal: we had to make something new for the product since, at the last two sprints, we had given our users nothing new.

This time, we wanted to build the control panel, and connect it to the PC to allow playing with joysticks, as well as install more games in the emulator.

As agreed, the stories that made the sprint goal were marked with a star on the taskboard, and were considerably smaller. Some were: checking drawings, marking and cutting wood, designing the control panel, testing the assemblage and building the circuitry for the joysticks, and assembling the control panel.

We had the main supplies, wood and joysticks, to start building the control panel. So, without further ado, we got down to work.

The assumption “seeing movement creates more movement” really works. While some people worked on marking and cutting wood, others tested the joysticks. At the same time, we made some noise –literally– that caught people’s attention, people who weren’t interested on the project at first, and now wanted to join in.

Therefore, at the end of the sprint, not only had we accomplished our goal, but also we had made a lot more progress than we had planned at first.

During the retrospective, we congratulated ourselves for all the work done, and we promised to continue working this way.

Sprint 5 – Spreading agile practices in the company

After a successful sprint, the team was once again motivated, and the project was at its very best. At the last sprint, two new members joined the team, and we were achieving two important goals for the company.

The first goal was having people from different areas of the company to join the project. Three people from three different projects, and people from infra and admin, were now also working on the arcade machine.

The second goal was spreading agile practices in the company: we were teaching,  in a practical way, how to use Scrum to people who weren’t using it in their everyday life.

As we all know, many companies fail to adopt and spread agile practices. We firmly believe that the adoption from a dynamic and entertaining approach can significantly diminish the probability of failure.

Having this in mind, we decided to present the Arcade project to the rest of the company and to the Board during the Q; the Q is an internal meeting of the company where the most important facts of the last months are presented.

Therefore, we included a story with that presentation on the Planning, which led us to consider having the arcade structure finished a few days before the end of the sprint in order to have more impact on our presentation.

Thus, for this sprint, we decided to build the frame, create the internal design, install more emulators, get more games, install Jukebox to play some music, and, finally, paint the wood to make it look better.

Unfortunately, we didn’t have enough time to paint the machine before the presentation. Nevertheless, it was the main attraction of the evening, without being overshadowed by grilled pizzas and beers that were also present for the meeting.

At the end of the sprint, we finished almost every story, including the first coat of paint.

Anyway, another successful sprint. However, when you’re having a run of good luck, you can become a bit arrogant and fail to see problems looming over the horizon.

Sprint 6 – Scrum’s flexibility

The new sprint brought new challenges. With the intention of making the arcade machine presentable for the Q meeting, we had exceeded our available budget; we were in the red.

Scrum doesn’t mention how to solve this kind of problem; it is seen as another impediment that affects the project and has to be solved.

At the Planning, we took it as another story, although a high priority one since it hindered progress on other stories we expected to achieve during the sprint.

Moreover, this project was already taking two months and a half. This may seem a short time for projects we’re used to carry out, but for a project outside working hours, without compensation; even though you’re building your own arcade machine, two months and a half can be too long for some people.

I believe this is why some people who participated in this project from the beginning said this was their last sprint, at least for a while.

In addition, an invaluable workmate left us: the 21’ CRT which, after almost three months in this project, closed its bright eye never to wake again.

Luckily, when some run out of power, others take over the task so the project can continue.

It’s here where we can see a strong point of Scrum. Planning work for short periods of time, in this case two weeks, makes it relatively simple to adapt according to the number of participants in the sprint and the amount of time each one can devote: this is known as team Capacity.

Thanks to this working method, it was easy to adapt to having new team members as well as losing some of them.

So we managed to adapt and get new funds to carry on thanks to our Product Owner, who, in fact, also changed.

This is another point in favor of Scrum, because it prepares you for changes, not only of the product, but also of the environment, the roles and the team.

At the end of the sprint, we had a temporary substitute for the CRT, a second coat of paint, some improvements on the frame and the control panel, an easier ON/OFF switch, new posts to be published and a notepad so our users could suggest games.

Sprint 7 – A well-oiled Machine

It had been three months since we started building the Arcade Machine and during that time many people came and went from the project, but there were still plenty of us who wanted to continue.

And continue we did, however we realized that the drive we had at the beginning of the project was starting to wane, so we made a decision – give the project a deadline. We decided to have two sprints, the one that was beginning and just one more.

This decision allowed us to focus on what we needed to do to achieve our goal of having a polished final product.

I think that if we hadn´t been using a methodology such as Scrum, which made us keep a sustainable rhythm, setting our pace with meetings and time boxes, we would hardly have arrived at this point.

Likely, without Scrum, the team´s efforts would have been individual and the process advancements would have been slower, disallowing us to see the motivating results that helped us continue.

An analogy that comes to mind when I think of our team at that time, is that of a ‘well-oiled machine’ – even after the energy that generates the impulse is gone, the bearings keep rolling for some time.

So, that is what was happening with our team at the time, the energy that generated the impulse was gone and the impulse was weakening, but the rhythm of the working method we had adopted and accomplished to date was keeping us moving; we were used to attending planning sessions, standups, reviews, and retrospectives, which were effective and adequate in length and in which each one of us already knew what to do.

That was how we were successful in adding new “functions” to our product. We put WiFi on it to listen to music online, downloaded new rooms to make our list of available games bigger, continued writing these posts, advanced the external design, and created a new “saving bank” for users to collaborate with the team and get funds to make the design happen.

Finally, knowing we had only one sprint left and that by buckling down and maintaining focus, time would fly by, we got ready to prioritize the stories that would help us get the product to as “done” as possible.

Sprint 8 – Pareto is on our side

The Project was about to be finished, it was our last Sprint. Once again Scrum´s tools have helped us decide what was going to be included in the Sprint and what should sadly be left out.

No matter how much clients, users, managers or even developers dislike it, in every project there are always things that will be out of reach. Why? Because the functionalities we can think of are almost infinite. However, if we succeed in prioritizing the backlog -as it is proposed by Scrum- by the end of the Sprint we will probably have a product that meets most of the users ‘main requirements.

Applied to software development, Pareto’s Principle indicates that 20% of the functionalities are used by 80% of the users. Taking this into account we could say that any project ‘success lies on discovering those 20% of functionalities and implementing them in the best possible way.

Writing this post, a few months later, I quickly see how true that is.  Although we didn´t develop all the stories the backlog contained, the final product was an absolute success. Not only The Arcade Machine is frequently used to play the games we included, with different emulators but also works as a Jukebox in every party we throw!

At the end, beyond the created product, we can definitely state that the Project was successful. All the participants who learned Scrum “by playing” are now able to apply Scrum to the projects they are part of and have become agile principles ‘great defenders.

We, the Arcade Machine builders, believe the best way to know a methodology is by using it and we are now seeking for new projects to gain experience, and why not play, while learning more about other agile methodologies.