Agile Development as a Game

While writing my recent article what defines a game, I realized that the Agile Development process had many similarities to a game as I had defined it. I worked in software development for over fifteen years, and for the last five was working in an agile team. This is a particular development methodology with a central philosophy and several different implementations. At my last full-time IT role, we used the Scrum method, and it was a highly effective way of delivering valuable features to our customers. It also had the benefit of being able to react to changing requirements.I am not going to define all the features and processes of agile development here. However, I think if we look at from a gameful viewpoint, we can see some features of the method that resonate with games. These add another reason why many, many developers find the Agile development process a way to work that leaves them motivated and engaged.

Agile Development as a Serious Game

1. A Goal

The goal of most development projects is to release a piece of software that provides value to the end user. What that value is is defined in a set of use stories (extended requirements), curated by a product owner in a backlog. The goals can change over time, but all the while there is still the single list of what being is slated for the release. Some teams will make a call to release at a point when there is sufficient value in the completed work. Others have a process of continual release, with every completed story being pushed to the production systems as soon as possible. In all cases, the goal is to get to 'done'. As we used to say 'ABC - Always Be Closing'. With apologies to Alec Baldwin.Many games have changing victory conditions and ways to score points. Sometimes they are under your control, sometimes they are changing by other effects. The goal doesn't need to be static, but there has to be one.

2. Rules

Agile development has a set of rules and defined interactions. In Scrum, there is a defined cycle of development (the sprint which can be from 1 to 3 weeks long) which is capped with a kickoff, ended with a review, and interspersed with regular stand-up meetings.Agile teams will define what task completion looks like. These look a lot like rules of a game: what we do in a round (a sprint), what happens during that round, what happens at the end of the round, how we score a completed task. Everyone agrees to these rules and knows what to expect, creating a shared momentum and rhythm to the work.

3. Feedback

Progress towards the goal is very clear in Scrum development. If it's not, then there's a problem in the process that needs fixing. Each sprint the team brings in a set of tasks to complete. Each day, at the stand-up meeting, the team reviews their progress. Each sprint, the team review their overall progress to the end goal. Moreover, tools like JIRA allow the team to see the total burn down of work left for a sprint, and for the overall release. These allow adjustments to be made - more effort in one area, focus on helping people who are blocked at completing a task, or adjusting early for failure to meet the sprint goals.Mid-game adjustments are important, as they let you change strategies and tactics. And the only way to see if your adjustments are working are to have feedback. Otherwise, it's guesswork and gambling; features that don't lead to the benefits of serious gameplay we are looking for.

4. Voluntary Participation

This is one of the key features of Agile development. Everyone agrees to use it, everyone gets engaged in the process, and everyone contributes to the overall process. By the review and retrospective mechanism, tweaks can be evaluated and made. Does the meeting time for the daily check-in not work? Let's agree to change it. Have we assigned to much User Interface work to one person? Let's look at spreading out the load and being intentional about it. The feedback from these meetings is what makes the process tick.Agile development works better when the team is all engaged. One of the challenges to starting up using this process is getting on board, and seeing the benefits. The old way of working can seem better, the challenges and changes with the process can seem like a hard mountain to climb. So participation may not voluntary at first. After all, in the workplace, we sometimes have to go along with things we don't like. Generally, though, Agile teams become engaged as a group, because of the feedback process and the mutual collaboration of choosing the sprint goals. Group ownership of the task list happens. And the skeptics get won over.I know this from my own personal experience, as I was a critic of the process before I tried it. I was especially concerned for the testing work I was responsible for, as the time seemed too short to do meaningful work on brand new development. After three months, I could see how it all worked better for having a well reviewed and validated software system, with an intense focus on what was to be delivered each sprint.

5. A Failure Mode

How do you know when you've failed to deliver? In Scrum, this is actually obvious. Each sprint, there's a set of tasks assigned to the team. The team tracks towards them during the sprint. And during the review the stakeholders get to see if they were met. If goals were missed, they tell it in the review. Failure is acknowledged. In the retrospective, it is analyzed, looked at and acted on.This is the Kolb Cycle in action: do -> reflect -> review -> plan -> do. It's how we learn, and it's wrapped into the Agile method. And with a clear failure mode per sprint, you can adjust, and recognize failure to adjust. Without it, development can continue without acknowledging the problems. This leads to missed deadlines, missed quality goals and lacking functionality. If we are going to have a failure, let us have controlled, acknowledged failures we can learn from.

Conclusions

Agile Development does share many aspects of a game. The failure mode is more per sprint than overall, and the participation is not necessarily voluntary. The goals can shift too, but that's not always a problem in a game if everyone is aware how they can shift. The claim isn't to treat the agile development life cycle as one big serious game for improved results. Instead, it's how using what we know from how people engage and learn from games, we can see some reasons why the Agile/Scrum process creates highly engaged, goal-achieving teams.Want to talk more about how serious games can be used in your Agile Development Process? Want to learn more about gameful thinking in your software team? Want to get an example game for your next Scrum Retrospective? Contact Chris@EngimaticEvents.com.