In February of this year, I brought the varied members of my development team together here in Richmond, VA for a single purpose: I could sense their growing frustration with the development process. As a team built to serve an entire company with dozens of potential clients, requests for new development and design were coming from all angles and often from folks who lacked the technical background to make informed requests or to understand the complexity of the “ask.” Put simply, my goal was to create some form of exercise that would allow members of the team to better understand where their frustration was coming from, and to help managers to understand how to overcome many of the communication hurdles that lead to scope creep and spell certain doom for development projects. What follows is a description of this exercise, shared with the audience in the hopes that other lead developers might find useful elements to use with their own teams.

1. Replicating the problem

Identifying the issues dooming a development project is much harder than it seems. The complex tangle of finite manpower (and funding) combined with encroaching deadlines and shifting priorities cannot be pinned on any single team member or project stakeholder. If it were so simple to identify the problem, companies would always merely eliminate bad elements from the development equation and move forward with significantly reduced losses and acceptable end products.

Identifying the issues that plague many development teams and scuttle their ability to reach victory is quite complicated, and any excercise meant to replicate those complicated in a non-threatening and non-judgemental format must reflect those complexities by artificially creating hampered communication and evolving goals. For the basis of my “project requirements” in this exercise I used a deck of cards from a game called Superfight. The game, very similar in format to games like Cards Against Humanity, contains cards of several types. There are cards that represent the objective (or the opponent for the players to defeat,) there are cards that serve as weapons or accessories for the opponent, and there are even cards that serve as the venue or arena for an imaginary battle to take place. All of these variables would allow me to structure a fun imaginary set of requirements for the team to complete, and drawing new cards at regular intervals could replicate the experience of scope creep. Participants were forbidden to share or show their cards to one another, so that communication between teams would be limited, and players might find themselves competing for similar (or identical) resources without knowing it.

Pro-tip: something similar could be accomplished by writing fake project requirements on small slips of paper, depending on what creative format is used from the next step.

2. The creative experience

If I wanted to replicate the creative experience for an audience of varying levels of technical and aesthetic skill, the creative format must involve elments that could be accessable for every participant. I decided early on that I needed some form of building toy that would allow the users to complete or compile some goal, while presenting the lowest possible technical challenge.

What I chose in the end, because of my leanings towards geek-related hobbies, was to use a family of products by Hasbro called Hero Mashers. These toys are a line of figures and creatures comprised of modular components, so that each character can be created by swapping out the arms, legs, torso, head, and accessories of other characters from the line. Hero Mashers fit so well with my choice of Superfight for the project requirements that I decided the entire “game” would revolve around participants being challenged to construct a character capable of defeating one of the black objective cards. For instance, if the card saying “King Kong” were drawn, the user would need to construct a character capable of defeating King Kong with the available parts. If later “King Kong” is modified with a weapon card of “using a flamethrower,” the user must now modify his character so that they’d be capable of defeating King Kong weilding a flamethrower. And if the venue card of “in outer space” was drawn, they must now consider how to construct a character capable of defeating King Kong who is weilding a flamethrower in outer space.

Pro-tip: with slight modifications, one could use other building toys like Lego (or one of the many Lego knockoffs) much more cheaply. If the objectives from part 1 involve building structures or vehicles, the net effect will be very similar.

3. The time crunch

For this exercise it was important that the participants experience a very real sense of the finite amount of time that developers experience. I chose to use a timer on my phone to give an overall deadline of thirty minutes to the game, and to draw new modifying cards every five minutes. The random variables placed in front of each “developer” may feel unfair, and create a sense of stress as the overall deadline approaches. In a particularly large group, the resources to build each character dwindle rapidly, leaving a pile of cast off parts that no one particularly cares for sitting unused on the table. This replicates the reality that many developers experience where they are handed outdated cell phones or laptops, or signed on to networks with subpar connections that throttle their download and upload speeds. These are the very real technical hurdles that developers can experience in even the most tech friendly companies due to budget constraints or poor infrastructure. As the clock ticks away on a critical project I’ve witnessed many a developer struggle with a blown motherboard or dead monitor, only to find out that requisitioning an approved replacement might take days or weeks.

Pro-tip: modifying the project “deadline” is one of the most realistic elements of the game. I’ve never been part of a corporate project that didn’t involve the artificial extension or truncation of a deadline due to various changes in the project. Experiencing this element might be the most eye-opening part of the exercise for many non-creatives.

4. Presenting the final product

Perhaps the most important part of the game occurs when, at the end of thirty minutes, the act of constructing heroes ends, and each “developer” must present their work to the “client.” Some developers have very specific explainations for each component of their build, using this character’s head for their inteligence, or that character’s torso for their durability. One developer of mine had gone so far as to consider the element of psychological warfare, and had chosen parts from Marvel’s Deadpool in order to allow his character to better insult and intimidate the opponent. Another developer was very thorough in the choice of specific weapons and accessories, such as jetpacks and rocket launchers, to allow their character to manuver in the assigned venue with ease.

Surprisingly, one of the participating developers chose to merely reconstruct an existing character (the Hulk) and explain how that pre-existing set of options was capable of defeating its opponents  without any type of modifications or additions.

Pro-tip: feel free to be critical of each developer’s solutions. Clients don’t always understand the provided solution to a problem, and sometimes feel that what is presented in no way solves their perceived needs. The criticism often forces developers to sharpen their skills in communicating their reasons for various choices in lay terms. Allowing the other players to “vote” on whether the final product could succeed is another realistic alternative. Often, approaches to producing a final product are approved by teams or groups of stakeholders, each with their own opinions and reasoning about the goals for the project.

5. Chance comes into play

As mentioned before, developers often face obstacles that cannot be forseen such as hardware failures, software glitches, unplanned logistical hurdles, and even personal health problems. The world around us has an entirely random way of complicating or delaying even the best-planned projects, and can leave us struggling to compensate through no fault of our own.

To simulate this element I chose to use dice, the literal symbol for chance, and have players roll them to settle ties.

Pro-tip: “rock, paper, scissors” is another method to let “developers” reslove disputes over parts for their projects. It allows for some strategy while remaining simple enough for a quick resolution.

6. Following the exercise with some insights

So much can be learned about the psychology of each participant by how they choose to solve the problems they are faced with. The developer who chose to re-create the Hulk was a team member who approached every task in our day to day projects by first searching for an “out of the box” solution. Salespeople or managers who are presented with this excercise can often be counted on producing a final product that has logistical limitations, but explaining that final product splendidly and winning over the “stakeholders.”

Fully engaged designers and coders often find themselves laughing at the observations of non-creative team members who participate. Complaints like “it kept changing,” or “it wasn’t clear what I was supposed to do to solve the problem,” or even “there weren’t enough pieces left for me to finish,” ring so true with the real world creative experience. It can be eye-opening for non-creative leaders to suddenly be aware of how scope change, deadlines, poor communication, and limited resources can challenge an otherwise “simple” project.

Pro-tip: use the post-exercise conversation as a time to hand out some training about communication and project scope. There’s no better time to change team culture than when your participants have had a chance to switch roles and see things from one another’s perspectives.