Agile Games for Productive Teams
Dana Mitroff Silvers, San Francisco Museum of Modern Art, USA and David Hendee, Carbon Five, USA
This paper describes a set of highly interactive games and activities that encourage collaboration, communication, and efficiency for web development teams. These games aim to streamline ongoing development, improve teamwork, and promote fun for teams engaged in the messy business of creating Web and mobile software.
Keywords: agile, games, project management, collaboration
This paper accompanies a mini-workshop to be held at the 2012 Museums and the Web conference. It describes a set of highly interactive games and activities that encourage collaboration, communication, and efficiency for Web development teams. In the conference workshop, attendees will get a taste of the games with a focus on experiential learning. Attendance at the conference workshop is not necessary, however, for successful implementation of the games, and this paper is aimed at anyone seeking to streamline ongoing development, improve teamwork, and have fun while engaged in the messy business of creating Web and mobile software.
As we will demonstrate, Agile games can be successfully adapted and applied to museum Web and mobile projects. Readers and workshop attendees will learn how to:
- Find ways to be more efficient and collaborative
- Define, break down, and prioritize projects and tasks
- Establish a sustainable cycle of planning, development, and delivery.
The San Francisco Museum of Modern Art (SFMOMA) and Carbon Five, a Web and mobile software services consultancy, have been working together since 2003. Carbon Five did not formally introduce SFMOMA to the Agile methodology and the games described here until 2008 as part of the massive undertaking to redesign the SFMOMA Web site (Burnette et al., 2009; Burnette et al., 2010). Since then, the Agile process has provided a tactical toolkit to streamline ongoing development work at SFMOMA.
Carbon Five built and deployed the SFMOMA Web site with their content management system, SmileMaker, and the development work took place over an intense five-month period in which SFMOMA’s two-person Web team worked closely with two developers at Carbon Five.
Since the site launch, SFMOMA and Carbon Five have continued to partner on the ongoing development of sfmoma.org, with Carbon Five developers serving as members of the extended SFMOMA Web team, working on a regular basis to develop new features and functionalities. The SFMOMA Web team has also internally adopted many of the games and processes.
What is Agile?
Agile development is a conceptual framework that promotes adaptive planning, incremental development, iterative software releases, and rapid responses to change. Carbon Five has adopted the Agile methodology because it is a nimble, efficient process that adapts well to different clients and projects.
It should be noted that the term “Agile” is used here in its most general sense, and there are numerous “flavors” of Agile, such as Scrum and Extreme Programming, but it is beyond the scope of this paper to describe the differences between these methodologies.
Games and Agile
In The Art of Game Design (Schell, 2008), the author defines a game as a “problem-solving activity, approached with a playful attitude.” In the context of work, games can offer an alternative to traditional processes that do not typically optimize for collaboration and transparency. The game “rules” codify new behaviors and reinforce organizational best practices. Additionally, the playfulness endemic to games can help make these practices easier to introduce and institutionalize.
While Agile is not a panacea—and the focus on iteration, adaptability, collaboration, and transparency requires daily discipline—it is a set of activities that fosters teamwork and accountability. Since Agile practices tend to be radically different from many existing organizational processes, introducing them can be a daunting challenge. Therefore, redefining Agile activities as “games” increases the likelihood that these practices will be used, allowing anyone inside the organization to suggest their “play.”
The games described here are often played differently across individual organizations, and the descriptions below reflect SFMOMA and Carbon Five’s style and experience. Other organizations may personalize these games differently and implement them with variations.
In the game descriptions, players are referred to in terms of the roles typically found in Agile project teams. These include:
The product owner is the person on the project who is responsible for its success. In a museum setting, this person might be the director, manager, or coordinator of digital media or the website. The product owner is tasked with helping to define what work the team is performing, prioritizing this work continuously, and accepting or rejecting the results of the team’s work. Additionally, he/she is typically tasked with gathering input from various internal stakeholders and users, and achieving organizational consensus by providing appropriate transparency to those ultimately accountable in the organization.
In the software world, developers are computer programmers. In Web and mobile software development, their skills are further identified by front-end and back-end activities, but for the purposes of these games, anyone who is writing software can be said to be assuming the role of a developer. On large development teams, one of the developers may be designated the lead and placed in charge of managing the developers and making architectural decisions.
While design activities for creating software are typically divided into user experience and visual design activities, in the context of these games, “designer” refers to any member of the team engaged in any design activity, including user research, usability testing, wireframe development, paper prototyping, interaction design, and visual design.
For this paper, we have outlined five games and provided instructions for typical play, but there are many other games played by Agile practitioners. A good resource for other games played by Agile practitioners is the community-run portal, TastyCupcakes (http://tastycupcakes.org/).
Figure 1: The SFMOMA Web and Interactive Educational Technologies teams
In the Agile spirit of “find what works and do it all the time,” the standing daily is a short project status and planning meeting for the entire team, held at the same time each day. Players stand in a circle to play. Because the standing daily is a short, fast-paced gathering that is highly structured, it’s far less onerous than a typical “meeting.” It builds a strong sense of team collaboration and provides a high level of transparency and accountability into the work of the individual members of the team.
The main objective of the standing daily is to optimize communication among the team members. Secondary benefits include identifying risks early, ensuring everyone on the team is contributing, identifying bottlenecks, and even just getting team members to show up to work on time. Additionally, it fosters a sense of team work—and fun.
When to play
The standing daily happens every day at the same time. The perfect time is 10:05 a.m.: everyone is late if it’s at 10:00 a.m., but everyone can somehow magically show up at 10:05 a.m.
The entire project team should be present. This includes all of the developers and designers, plus the product owner.
The standing daily should always take 15 minutes or less. This is one of the reasons why the meeting is done standing: if any player takes too long, the other players will get uncomfortable enough to step in and help move it along.
No equipment is necessary, although the team must find a space large enough to accommodate them standing. Playing around a table works, but standing in a circle around empty space is preferred.
While the entire team stands in a circle, a random person is selected to begin. Play proceeds either counter-clockwise or clockwise depending on team preference. Upon one’s turn, the player describes:
- What work he/she did yesterday
- What work he/she plans on doing today
- What help he/she needs, or what is blocking his/her progress, if anything.
No player is allowed to digress from the formula, and other team members are encouraged to interrupt digressions by suggesting that the players involved in the digression set up a separate meeting (typically right after the standing daily) to discuss the issue. All requests for help typically result in pairing (team members working together on a specific task), and identified roadblocks are usually assigned to the product owner to resolve.
Stand-up meetings can be played less frequently, and can also be played with members outside of your immediate team or in a different physical location. Even weekly stand-ups can be incredibly valuable. For example, SFMOMA has a weekly stand-up between two teams that work closely together on digital initiatives: the Web team and the Interactive Educational Technologies team.
Figure 2: Mad lib stories from the SFMOMA Getty Online Scholarly Catalogue Initiative project.
In Agile software development, the specification for the units of work performed by team members is called a story. A story can be thought of as roughly equivalent to what is often called a “use case” or a “feature,” with the caveat that a story is always described in terms of its value to the end user. In other words, “set up the constituent database” would never be a story; rather, setting up the constituent database might be a byproduct of another, user-facing story about signing up for e-mail newsletters.
Every feature that shows up in the final product begins its life as one of these stories. Stories are written in the form of a fill-in-the-blank “mad lib,” a technique that encourages good story design.
The primary objective of story writing is to specify discrete features that are going to be built for the project. A secondary objective is to not over-specify features. The mad lib format helps team members frame features in terms of their value to end-users and keep stories short and clear.
When to play
Story writing is part of the planning phase for each iteration. Iterations typically last one or two weeks, and writing stories usually happens at the beginning of an iteration, sometimes just after the team presents the work done in the previous iteration.
The entire project team should be present. This includes all of the developers and designers, plus the product owner. Important stakeholders, such as curators, educators, or other staff members with specialized knowledge or investment in features likely to emerge during story writing, are often included. For example, when SFMOMA has held story-writing sessions for the Rauschenberg online catalogue, a project of the Getty Foundation’s Online Scholarly Catalogue Initiative (http://www.getty.edu/foundation/funding/access/current/online_cataloging.html), participants have included conservators, curators, educators, and editors.
Like other Agile activities, the idea behind story writing is to do project planning regularly and organically throughout the course of a project. For each iteration, only enough stories to fill the next iteration are technically needed, but in practice, most teams like to be able to project a few iterations into the future. Therefore, story writing at the beginning of a project can take the most time, so teams are encouraged not to attempt to write down every story during the first planning session.
Teams should plan on an hour per week dedicated to story writing. Teams with a two-week iteration might plan for a two-hour planning session once every other week. Each story usually takes around two to five minutes to write, depending on how much conversation happens.
Traditionally, story writing is done on index cards, and it is recommended that teams start out using a physical planning board such as a white board or cubicle wall for a few weeks before selecting an online tracking tool. Large stickies can also be used.
The story writing game is led by the product owner, with active participation by the lead developer and input from the other developers and stakeholders. Order of play is usually fairly random, with the team member who wishes to contribute a story filling out an index card using the following mad-lib format:
As a [role], I can [action] so that [goal].
For example, a story written for the SFMOMA online calendar might be: “As a parent, I can filter by family events so that I can plan a visit to the museum with my kids.”
“Role” in this context refers to a category of users of the software. These are typically abstractions of actual (or imagined) people into their typical behavior groupings. For instance, an online calendar of events might serve the roles of “members,” “tourists,” “students,” “parents,” and “educators.” Associating features with specific roles helps keep stories user-centered.
An “action” here refers to a particular task that a user needs to perform. So, for the role of the parent using the online calendar, the action might be “filter by family events,” while the action for a student might be “find free things to do,” and the action for a tourist might be “find today’s opening hours.” Some actions are more specific than others, and getting the right level of specificity is a skill that comes with practice.
The third part of the mad lib is the user goal. This important part of the story is often overlooked, but it’s good discipline to think through the “why” of the story. For our tourist who would like to know today’s opening hours, the goal might be “so that I can visit the museum today.” Knowing this, the designers and developers might decide to make today’s hours more prominent or add an interactive map near the listing of the hours.
Some common variations include allowing anyone to write a story at any time (rather than just in planning meetings) or restricting story writing to the product owner. It’s also very common to use an online story-tracking tool, such as Pivotal Tracker (http://www.pivotaltracker.com), Greenhopper (http://www.atlassian.com/greenhopper), or Agile Zen (http://www.agilezen.com), rather than index cards, but using physical cards is highly recommended, at least for the first few iterations of a project. SFMOMA and Carbon Five use Pivotal Tracker, which is free for non-profit organizations.
Figure 3: Playing planning poker.
Planning poker is a game played to estimate the level of effort for doing the work needed to turn stories into features. In planning poker, developers use playing cards to indicate how hard they think individual stories will be to build.
The objective of planning poker is to project an accurate level of effort and difficulty for implementing the stories in a project. Estimation is done based on a relative, not absolute, level of effort, which helps the team avoid getting hung up on time-commitment-based estimation.
The unit of measurement for stories is in points, rather than hours, and once the team has been working for a few weeks, the average number of points delivered per week can be used to calculate the overall team “velocity.” This velocity can then be used to forecast when future stories will be completed.
Perhaps most importantly, planning poker helps define stories further and identify project blockers and risks.
When to play
Estimate stories weekly after writing them, but before they are prioritized (see Story mapping below). Planning poker can also be played whenever a new story is written, or when a story is changed enough so that its original estimation is inaccurate.
Planning poker works best with two to eight players. It can be played with more, but large teams often work better when split into parallel project teams of eight or fewer developers. All team members are present for story estimation, although typically only developers are allowed to vote on each story’s difficulty.
Play averages 30 minutes, with two to three minutes spent on each story. If story writing is done weekly, these sessions can be quite short.
Although not required, estimation cards are a nice prop for playing planning poker. Estimation cards are note cards with pre-printed numbers, and each player gets a full set of cards. In a pinch, developers can use their fingers, holding out the number of fingers that correlate to the level of difficulty.
The unit of measurement is in points: “0” (trivial), “1” (easy), “2” (normal), “4” (hard), and up to “8” (epic). A two-point story is understood to be twice as hard as a one-point story, and a four-point story is understood to be twice as hard as the two-pointer; and so on.
All team members sit around a table with a list of stories to estimate. If the team is playing for the first time, they should choose one story to be the “baseline” story for the project. This should be a relatively straightforward story with no outstanding questions, but it should be of average size. The team then chooses, arbitrarily, to assign some number of points to this story. For example, the team might pick, “As a tourist, I can view today’s opening hours so I can plan a visit to the museum” as the baseline story, and assign it a point value of 2.
Once the baseline story is set, the product owner or lead developer reads a story that needs estimation to the group. The entire team discusses the story for two to five minutes and debates how they might go about building it. They then either decide to estimate the story or agree they cannot estimate it for some reason (e.g., if the story is poorly written).
To estimate, each member picks from his/her deck the card with the number of points of estimated story difficulty, relative to the baseline story or other stories that have been completed. The team leader then calls out “one, two, three,” and on “three,” all team members who are voting show their cards at once.
Continuing the example above, say the next story is, “As a parent, I can filter by family events so that I can plan a visit to the museum with my kids.” One developer might think that story is the same level of difficulty as the baseline, assigning it a value of two points, while another might think it is roughly twice as hard, assigning it four points.
If, after comparing the cards, all of the cards are one of two potential options (e.g., all 2s and 4s), the higher value is selected and applied to the story by writing the value on the card. If there is a wider spread (one 1 and one 4) the team discusses the discrepancy, usually with the outliers arguing why they think it is more or less difficult than the other. Then the entire team replays the estimation game, usually finding consensus immediately.
As discussed, fingers can be used instead of cards. This variation is often called “Roshambo” because it resembles the children’s game of the same name (also known as “Rock, Paper, Scissors”).
Figure 4: “User Story Mapping” by Dai Fujihara, 2011, available on Flickr at http://flic.kr/p/aBop5i, under Creative Commons Attribution 2.0. Full terms at http://creativecommons.org/licenses/by/2.0/.
Story mapping is a planning game that helps product owners get a sense of the bigger project picture while ensuring that stories are prioritized in a granular way. It helps the product owner and team visualize and focus on the big picture, showing the project as sequential milestones. In this game, cards are arranged into columns and rows, creating a “map” of the project in which each column represents an “activity” or user goal, with stories arranged in priority order from top to bottom (Patton, 2008).
The primary goal of story mapping is to facilitate prioritization. Visualizing the project as a whole helps product owners choose which stories the team should execute first. A secondary objective is to group sets of stories into milestones so that the product can be released incrementally.
When to play
Story mapping should be played at least once per major project milestone. Typically, teams perform story mapping with each iteration, often right after presenting recent work and writing stories. A longer story-mapping session at the beginning of the project is recommended as well.
Members of the project team often participate in story mapping in the beginning, but many teams play with just the product owner and lead developer. The product owner can also play alone.
Initial story-mapping sessions typically take two to three hours. When played as part of an iteration presentation, subsequent story-mapping sessions typically take 30 minutes to one hour.
Story mapping is traditionally done on white index cards. It is helpful to have a second set of color index cards for the activity columns. Carbon Five developed a story-mapping tool based on Pivotal Tracker called Tracker Story Maps (http://www.trackerstorymaps.com/), and there are other tools for story mapping, such as Silver Stories (http://toolsforagile.com/silverstories/).
If the team is playing for the first time, members must decide as a group what the major “activities” or user goals will be in the columns. The right number of activities varies from project to project, but a good goal is seven or fewer. For example, activity columns for an online calendar might be: “learn about events,” “plan a visit,” “buy tickets,” and “get reminders.” Activity columns are typically arranged from left to right, ordered by a typical user’s path through the site, or arranged by priority.
After picking activity columns, story cards are placed in the appropriate column (in no particular order). Depending on the team and the current goals for the project, a milestone marker (a piece of string or tape is a good prop) is placed on the table below, and the product owner is challenged to place some number of stories above the milestone (stories that are “in” the release). These stories are then further prioritized into a granular list, from top to bottom in each column.
In this manner, the entire set of stories planned for the current release can be prioritized from top to bottom and from left to right, ensuring not only that the most important story will be executed first, but also that all of the stories planned for the release form a cohesive whole, as determined by the product owner.
As mentioned, an online tool is often used for story mapping so that teams can share information.
Five on Fridays
Figure 5: Informal user testing on a Friday afternoon at the Carbon Five offices
Five on Fridays is a style of rapid, “quick and dirty” usability testing for designing and developing Web and mobile applications. Five on Fridays generates new ideas, uncovers bugs, and helps nurture a “user-first” focus within an organization. Five users are invited to participate in a usability test held on a Friday. Three team members, ideally including one developer, observe each user interacting with the “product.” The product can range from a concept to a paper prototype to a functional digital prototype.
The primary objective for usability testing is to get the team out of a “we know best” mindset and replace it with an approach that prioritizes learning about users and their needs over creating features with questionable end-user value. Testing helps team members build empathy for users through engaging with real people, watching what they do, and experiencing their joys and frustrations.
When to play
Five on Fridays can be played weekly, but if playing weekly proves to be too time consuming, switching to twice or once a month (a good mnemonic for once a month is “Three on Third Thursdays”) works as well. The exact frequency and number of users tested is not as important as committing to usability testing in general.
It’s important that every team member have a chance to interview users at some point during the project. Rotating team members through the usability testing roles is recommended when institutionalizing this game. It is best to run tests in pairs so that one person can ask questions and the other can observe and take notes and pictures. Other team members can also be present to observe.
Usability testing is so critical that whatever time your team can dedicate to it is valuable. If you can dedicate a full day, you could spend an hour with each user, with an hour between appointments to debrief the findings, prototype new ideas, or fix bugs before the next scheduled user arrives. But even spending a couple of hours doing quick, informal interviews or paper prototype tests can be immensely valuable and worthwhile. At SFMOMA, tests have ranged from formal, hour-long sessions with laptops and fully functional Web sites to casual conversations over paper prototypes with visitors in the museum atrium.
Ideally, tests are conducted in a quiet, dedicated room with the prototype or software and materials for taking notes. Stickies are a good way to take notes and can be quickly processed soon after the usability tests.
Fancy testing facilities are not required to do Five on Fridays. While video equipment, one-way mirrors, and professional facilitation are nice to have, testing works on a shoestring budget as well. The museum lobby, visitor lounge, or even an empty office will work!
Incentives are good for ensuring that users will show up for scheduled tests, or for recruiting users on the spot. If your budget is limited, free passes to the museum work well, but other incentives can include vouchers for the cafe, note cards, catalogues, or posters. SFMOMA has offered Amazon gift cards for longer, scheduled tests, and free passes and posters for shorter, informal tests.
If you recruit users in advance and dedicate a full day to testing, schedule each user to arrive on a two-hour interval so as to allow a time cushion between tests. Users can be recruited via Craigslist, social media, personal networks, or even other departments within your institution (at SFMOMA, members of the Finance department have been tapped in the past, as these staff members generally don’t interact with the museum’s public-facing digital media as part of their regular work).
Decide in advance who the facilitator will be and who will be tasked with observing and documenting. The facilitator is in charge of running the test, introducing the team members, and thanking the user for participating.
After introductions, the user is asked to perform a task. Rather than explaining anything about the project, the facilitator should encourage the user to “think out loud” and describe what he/she is doing (e.g., “I want to visit the museum this weekend, so I’m going to figure out what time it opens on Saturday”). If the user gets stuck while trying to perform a task, the facilitator should encourage the user to describe what he/she is trying to do, using phrases like “What are you trying to do now?” and “What do you expect to find here?”
The team member taking notes should write down one observation or user quote at a time. If using stickies, use a separate sticky for each observation or quote. A good note might say, “User misspells the artist’s name when searching,” or “User said: ‘I wish I had a way to add this lecture to my Google calendar.’”
After the test, thank the user, and process the information immediately. Some teams find it useful to post on a wall screenshots of what was tested and place the most important stickies around the related screenshots.
After the final test, the team can decide what actions to take based on the user tests, if any. Remember that the primary objective is not to rush to do everything that users say, but rather to encourage the team to view their design choices as assumptions about what users want, rather than features that must be built. The most valuable outcomes of testing are the insights and unexpected observations gained from talking to users.
As stated earlier, many teams find five user tests in a day to be daunting and opt for a slower schedule. Other variations include online user testing services. Be aware that recorded videos of user tests are rarely, if ever, watched by team members.
One of the biggest challenges to introducing the Agile framework into an organization is the discipline it takes to integrate new practices into a team’s daily work, so introducing small yet consistent new processes and activities is an excellent way to begin. Starting with games increases the chances that these new practices will “stick,” as they not only help team members streamline their work, but they also promote a spirit of fun and collaboration.
The games described in this paper cover the full life cycle of Web and mobile projects, from planning to testing. Therefore, starting with these five games can help teams begin to establish a sustainable project lifecycle of planning, development, and delivery.
We hope to have inspired you by demonstrating a non-traditional approach to getting things done. However, reading about Agile games is not a substitute for experiencing them, so the best way to introduce these processes to your organization is to roll up your sleeves, grab some coworkers, and try them out!
Burnette, A., et al. “Redesigning Your Museum's Web site: A Survivors' Guide.” In J. Trant and D. Bearman (eds). Museums and the Web 2009: Proceedings. Toronto: Archives & Museum Informatics. Published March 31, 2009. Consulted January 28, 2012. Available at: http://www.archimuse.com/mw2009/papers/burnette/burnette.html
Burnette, A. et al., “Tales of the Unexpected: A Pragmatic and Candid View of Life Post-Launch.” In J. Trant and D. Bearman (eds). Museums and the Web 2010: Proceedings. Toronto: Archives & Museum Informatics. Published March 31, 2010. Consulted January 28, 2012. Available at: http://www.archimuse.com/mw2010/papers/burnette/burnette.html
Schell, J. (2008). The Art of Game Design: A Book of Lenses. Burlington: Elsevier.
Patton, J. (2008) “The new user story backlog is a map.” Last updated December 8, 2008. Published January 28, 2012. Available at: http://www.agileproductdesign.com/blog/the_new_backlog.html