Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Gamification - Is This Ever the Right Answer for a Business Application?

DZone's Guide to

Gamification - Is This Ever the Right Answer for a Business Application?

Almost every app has some level of gamification built in to reward users, but does this mean internal-facing business applications should adopt this mindset as well?

· Agile Zone ·
Free Resource

10 Road Signs to watch out for in your Agile journey. Download the whitepaper. Brought to you in partnership with Jile

When the team at Valve introduced Achievements within their Steam gaming network several years ago, I was excited. Not only could I achieve goals within popular games like Team Fortress 2 or Left 4 Dead 2, but those outside the game could see the results of my progress. Soon after, Sony introduced a similar Trophy feature to their popular PlayStation Network (PSN). What's better than finally reaching that level or milestone? How about having it presented on a main page for others to see? Very cool.

This whole concept has since become known as gamification and has continued to pick up momentum in applications outside of games. Perhaps you are using a mobile application where you provide your opinion for a particular good or service. It has become commonplace for your activity or actions to be tied to some type of reward system for others to see.

During a SAFe planning event about a year ago, I saw a ticket on one of the team's sprint board focused on adding gamification to one of the business applications they supported. I began to wonder if gamification has a place within business applications.

What Do I Mean by Business Application?

To provide some additional information, I think it would be a good idea to explain what exactly I mean by a business application. In the scenario which spawned this article, the development being performed was for an internal-facing application used by a private corporation. In all, I believe there were approximately 1,000 employees working for this particular division, with 50% utilizing the application at some point of their work responsibilities.

Without giving away too much about the entity, whose identity I would prefer to keep private, the application helped support their segment of the financial industry - tracking financial transactions against the lines of credit they extended and the associated collateral.

While a dedicated mobile client was built for Android and iOS devices, the application itself was not available to public users. To access the application, the company provided an ID and password. All the users of the application were known to the corporation and were readily available for training and reliable communication (email, direct correspondence, etc.).

What Is the Justification for Gamification?

At the time, my role was leading a shared service team that was focused on architectural design for the frameworks and technologies utilized by the Agile teams. Reading the ticket about adding gamification to the application led me to reach out to both the product owner and the development manager responsible for the team that authored the initiative.

In talking with the team, the core reason behind creation of the ticket was to reward users for visiting certain sections of the application or complete tasks which were often being neglected. As a side benefit, the team felt that having some type of award system within the application would translate to providing a connection to the application - similar to what I expressed with Steam and games like Team Fortress 2 or Left 4 Dead 2.

Designing Outside the 80/20 Rule

I fully understood the rationale behind the side benefit, but had to dive deeper into the primary objective. I was confused that certain sections of the application were not being utilized and that tasks were being neglected to the point that gamification was a consideration to resolve the issue.

When you think of having an application built to increase productivity, the goal is to provide something that meets the need of what is required. Consider when word processors began to gain popularity.

The word processor leveraged the power of a personal computer to take the place of the typewriter - allowing the ability to save documents in progress and also cut, copy and paste elements from one position in the document to another. Once the end-user was ready, the print functionality would send the results to a printer. If an error was found, the document could be opened, updated, saved, and printed again.

However, as word processing applications continued to generate releases, new features and functionality were added. The rationale was to provide more value for the applications as a way of driving higher end-user adoption levels. Some of the features extended well outside the 80/20 rule - to the point that the word processor was crossing boundaries into become either an image editor or publication application.

While the word processor example is not a perfect comparison, I do wonder if the underutilized features that were added to the business application are similar to the features outside the 80/20 rule in the word processor. I always think about WordArt being added to Microsoft Word. I remember checking it out and thinking to myself, "I don't know of a time when I will ever use that feature."

What Is the Value for the Business?

The question that should be at the core of every product owner's enhancement list is the true value the feature or enhancement will have on the business. Failure to have a strong understanding of the problem being solved will translate to low adoption levels across the application.

Of course, there are situations where a new feature is being driven by corporate executives, which may also suffer from lower adoption levels. In these cases, I believe a better approach is to gain a deeper understanding of why the elements are not being utilized over introducing gamification within the business application. I take this stance because of the underlying support and maintenance needs adding a gamification level would have on the application.

In time, when tickets are created and processed related to the gamification aspects, those funding the efforts are likely to not agree with the perpetual spend that the tier is having on the corporation. While open source solutions, like userinfuser (which appears to be quite idle), can cut down the development of the gamification layer, one can still expect to budget time and resources for maintaining the functionality.

I do believe that gamification has a strong place in application development; I only question if there is a place for internal-facing business applications designed to meet a set of needs for a known collection of end-users.

Have a really great day!


Download the whitepaper on Five dimensions of Scaling Agile in Large Enterprises. Brought to you in partnership with Jile.

Topics:
agile adoption ,gamification ,agile ,business applications ,business

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}