Process Analysis Write Up

The Problem

            Soon after the formation of Studio Scrapbot for our capstone game development assignment we began hosting meetings. We started out strong planning each meeting at least a week ahead of time, printing out itineraries that outline the exact process of the meeting, and defining hard-out times allowing us to better budget our time. However, once Spring semester began this all collapsed. With the expectations piling up on the team’s leadership we were less able to contribute the time necessary to plan our meetings. In fact, meetings became more focused on explaining things than on making decisions. A massive redesign of the systems in Snowmads necessitated more meetings, and more meetings necessitated a shift in production focus.

The Observations

            It wasn’t hard to see that meetings were dragging on and keeping our developers from the work they needed to get done. Unfortunately, however, data collection didn’t come into play until further down the line, a month into development. We did, however, have our meetings in the studio schedule allowing us to have a solid idea of the length and the amount of time in between when it was scheduled and when it was held. This is the core of the problems we aimed to solve.

The Data
            The primary aim with adjusting our process was to reduce meeting times by 50%. This data demonstrates why meetings were a problem for our team. These were the averages for meetings before we made any adjustments. This graph shows averages without stand-ups.

Capture2.PNG



In about one month of development we had held 17 meetings (33 including stand-ups) totalling 41.5 hours (45.5) individually. These meetings mostly included the full development team adding up to around 622.5 person hours taken away from development in one month. However, the most notable problem this posed was more centered around the high-water mark being 6 hours for an individual meeting. With 10 developers present we lost 60 hours of development time in one night.

Another core issue was the time these meetings were planned ahead of time. Many of these meetings were indeed important to hold, but frequently developers would not be able to attend, and the leadership would be unable to plan a schedule or make an itenerary for the meeting because they were scheduled last-minute. Namely, the average days ahead of time that January meetings were scheduled was approximately 2.5. This might not seem too last minute, but that value if we exclude meetings with our faculty advisor who often scheduled with us at least 7 days in advance that value drops to 1.6.

The Adjustment

            Around when our team focused our efforts in a large-scale design overhaul we made a number of process adjustments. These were largely focused around improving the organization of the development process. We transitioned from a Scrum methodology to Spiral. The changes that this incurred were removal of daily stand-up meetings, a dedicated risk-analysis day, a scheduled test and evaluation period, and most importantly, scheduled development time. Development time was set for Tuesday-Thursday and during that time leadership was strongly discouraged from hosting meetings. Instead we encouraged communication on an as-needed basis, and started setting our meetings for Monday, Friday, or finding alternatives to hosting meetings in the first place.

            Developers found this very beneficial. They reported feeling more focused, more interested in their work, and working better than before. Prior to this shift four separate developers from three departments reported that the time they were able to contribute to their tasks (and subsequently, their hourly requirements) were disrupted by excessive meetings. After the change each of these developers reported a more efficient workflow.

The Data Mk.2

            Qualitative information can only show so much, the data bears out that these changes were not a perfect solution, but they were successful at adjusting two major disruptions to the development process. After declaring a development period, meeting averages for the following month shifted dramatically. The average meeting length was 1.1 (bear in mind stand-up meetings were no longer being held) and the highest meetings were only 1.5 hours. Most importantly, however, the average time scheduled ahead was 5.6 (4.8 without advisor meetings).


Capture3.PNG

The Charts

Capture4.PNG

            As the chart demonstrates, there’s a clear drop off in total meeting time after the process adjustment was made. It’s worth noting that countless other factors impact times developers spend in meetings, but this bears out that at least the expected outcome was achieved.

The Flaws

            This adjustment did not come without any problems. Namely, the data is partially skewed by the natural development process. It makes sense that meetings will be far more relevant in pre-production than during core production working towards a vertical slice target. Developers and leadership have reported a dearth of communication between developers, a natural consequence of the absense of daily stand-ups. Further process changes to correct this discrepancy is certainly necessary. Developers have, however, reported being more available to do their tasks, and often overperform in doing so completing their tasks before reaching their hour estimates. Included now in their workflow is time spent communicating with other developers and working on paired tasks.