You are here

As agile becomes more ingrained in development organizations, teams should consider game play to improve agile skills and foster professional growth.

Agile skills development through game play

public://pictures/Marty-Bakal .jpg
Marty Bakal, Principal Product Manager, Rogue Wave Software

Now that agile is becoming more ingrained in development organizations, it's important for teams to improve their agile skills, in terms of the development process, as well as the skill sets of all team members. This type of growth is a key tenet of agile. It includes honing existing skills and learning new skills too, because every team member needs to be able to take on any role. For managers, emphasizing agile skills improvement is a great way to raise employee retention because it helps increase employee satisfaction.

To understand how people learn, consider the most rapid learners out there: children. How do children learn? They learn through play, which allows them to fully engage in an activity. I see this every day while watching my five-year-old play games, either by himself or with friends. He learns to count, improves finger dexterity, creates rules, and solves problems by playing games. A study published last year by the University of Illinois suggests that simple guessing games can help children improve math skills.

Now, a trend is emerging among agile development teams that involves playing games, not just for fun but to solve real work problems. The types of agile skills that can be improved include crafting more insightful retrospectives, explaining potential communication gaps, gaining a better understanding of issues within your organizational structure, and alleviating bottlenecks.

[ Is it time to rethink your release management strategy? Learn why Adaptive Release Governance is essential to DevOps success (Gartner). ]

Building with Legos

I recently attended the 2015 Agile Games conference and participated in an exercise in which we answered questions by building with Legos. It was a remarkable experience. Everyone in the meeting was given a couple of minutes to build, and then explain what they built, to answer a question. This a great tool to use during sprint retrospectives because everyone—not just the loudest voice—gets heard, and people have a minute to think about their answers before jumping in.

In the Lego exercise, each participant thinks of one thoughtful response to each question and then builds an "answer" with Legos. As a builder, you decide what you assign each Lego piece. If you're trying to describe your biggest issue in the last sprint, each Lego piece could be a requirement you had to address. You would then connect the pieces in some unusual fashion to show how requirements interact. This can vividly illustrate how requirements might be tangled up, poorly defined, or possibly not connected at all.

We also played a game where a team of analysts or product owners sat in one room and a team of developers in another. The analysts and product owners were given a picture that the developers were required to replicate—only the analysts couldn't show the developers the pictures—they could explain it to the developers only with a written description. This demonstrated the importance of teamwork and how to optimize communication. One attendee also felt this game could be used to explain the challenges of managing offshore development. Some of these games took only a few minutes, while others took an hour or two.

[ Get Report: The Top 20 Continuous Application Performance Management Companies ]

Every agile game has a goal

Once you understand the basic benefits of games in a business setting, the next step is to understand your goals for playing games in your organization. Typically, the people involved want to be more efficient in some aspect of work, or they find a particular aspect frustrating and target that frustration with game play. From there players pick an existing game that meets specific needs and start playing.

For example, if the problem is a particularly confusing architectural design issue, you might want to try to build (model) the problem with Legos. You might represent each component with a Lego piece. Large components can be signified by larger pieces. One color can signify existing components, while another color can signify components in progress, and a third color can represent new components. Then you start connecting them. At this point, teammates may start asking questions and could make suggestions about how the architecture (the problem being described with Legos) currently works or should work.

When I have done similar exercises, I've often noticed a heavy reliance on one component, which naturally draws attention to itself. Soon, the whole team joins in and begins optimizing the design together. People tend to have lots of fun while solving work problems this way. It's also a nice break from everyday work and allows the team to see the bigger picture.

Expand game play to develop new skills

Once you start to take advantage of playing a particular game, the next step could be to expand your game play to work on other aspects of your job. You might tailor a game to meet the specific needs of your company or industry. You could tailor the game I mentioned earlier (the one with developers and analysts in separate rooms) to include customers, executive team members, or the marketing team.

I recommend that you always have a specific objective in mind for your game, and make sure every aspect of the game is helping to fulfill that objective. The goal shouldn't be to complain about other groups, because that isn't very productive in the long run. Time boxes are useful because everyone on the team knows what's expected of them, and they can work this activity into the rest of their day.

Get inventive with agile development teams

The next step is to create your own game. It could be a fairly simple word game or dice-based game, or it could be something more complex. You want flexibility based on your needs. The idea is to start with an overarching problem to solve and then decide on a simplified solution. From there, pick one component of the problem and build a game based on that specific component.

For example, I'm currently working on a game to help explain the benefits of agile development to executives. I want to show them some basic product requirements with an expense sheet and a resources list. The next step will be to roll a die where each number signifies something to be managed within a range of project possibilities—from typical development progress, to new requirements being added, to budget cuts, etc. My goal is to show how agile development can quickly adjust to these changes.

The goal of all serious game play is to solve challenges that happen at work. Note that this agile skills development through game play is very different from, say, playing ping pong as a break during your workday. I encourage that type of game as well. But agile games constitute a specific targeted learning experience which happens to be fun. You could be solving an issue involving collaboration, getting better insights during retrospectives, etc. Because of its focus on personal growth, an agile development environment naturally supports this type of learning. If you're already part of an agile team, then you've got much of what it takes to give this a try.

Image source: Flickr

[ Get Report: Buyer’s Guide to Software Test Automation Tools ]

Article Tags