Software Process and Measurement

Software Process and Measurement Cast http://www.spamcast.net

Check out Software Process and Measurement Cast 273.  The SPaMCAST 273 features our essay on gamification and a new installment of Steve Tedon’s column: Tame The Flow.

Gamification is a tool to support process improvement.  It is a technique that leverages a player’s innate competitive drive to channel their behavior using game mechanisms. The goal is to have individuals, teams, and organizations adopt process changes and then process improvement.

In the second edition of Tame the Flow, Steve and I talk about constraints, bottlenecks and retrospectives. Contact Steve on Twitter @tendon or visit his website at http://www.tendon.net

For the next few weeks the Software Process and Measurement Cast will include a promo for the “Influential Agile Leader” events led by Johanna Rothman and Gil Broza.  Check out the full details at http://www.InfluentialAgileLeader.com

Get in touch with us anytime or leave a comment here on the blog.  Help support the SPaMCAST by reviewing and rating it on iTunes. It helps people find the cast. Like us on Facebook while you’re at it.

Next week the SPaMCAST features my interview with Jeremy Berriault.  Jeremy and I discussed his research on test professionalism.

The Software Process and Measurement Cast has a sponsor.

As many you know I do at least one webinar for the IT Metrics and Productivity Institute (ITMPI) every year. The ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars.  The Software Process and Measurement Cast some support if you sign up here.  All the revenue our sponsorship generates goes for bandwidth, hosting and new cool equipment to create more and better content for you.  Support the SPaMCAST and learn from the ITMPI.

Shameless Ad for my book!

Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” Support SPaMCAST by buying the book here.

NOW AVAILABLE IN CHINESE

Bartle Test

The Bartle Test is a useful mechanism for categorizing the behavior of players as you implement game mechanics.  It is built on theories about how personalities behave within games.  These classifications of players are useful when designing the implementation of game mechanisms. Each group will interact with the game mechanics differently, based on their personalities. The ability to develop a personality profiles provides a basis for planning. And when you can compare the anticipated behavior to actual behavior, models provide a basis for tuning the implementation.

The Bartle Test categorizes players into four groups.  They are:

Achievers
Key Attributes:  Enjoy difficult challenges, collect points or other indications of success, need feedback
Overview:  Achievers tend to concentrate on attaining observable measures of success and need continuous feedback on how they are performing.  Game mechanics such as leader boards are useful feedback mechanisms.

Explorers
Key Attributes: Not afraid to color outside the lines
Overview: Explorers are very interested in how game mechanics work and will actively seek out new or unexplained paths through the process.  Explorers make excellent exploratory testers and should be motivated with challenges.

Socializers
Key Attributes: Value relationships
Overview:  Socializers tend to concentrate more on interacting with other players than on game performance.  Game mechanics such as teams or group challenges will be effective in environments that have concentrations of socializers.

Killers
Key Attributes:  High competitive with other players, not good team players
Overview: Killers will go out of their way to provoke competition with players.  Generally these types of players are rare within IT because there is a heavy reliance of teams and teamwork. Killers can be used as a boogeyman to bring players together into an alliance to resist killers. In The Presentation Secrets of Steve Jobs: How to Be Insanely Great in Front of Any Audience,  Carmine Gallo suggested that one of Steve Jobs strengths was that he introduced an enemy that everyone else could unite against.  The killer can be that person.

Before designing how game mechanics will be integrated into your application or process improvement implementation, analyze the types of players you are trying to influence.  Assume that an analysis of your target audience done for a previous implementation will have changed.  Every implementation will different to some extent.  For long-term implementations of game mechanics, I recommend reviewing your initial classification of player types compared to observed behavior on a monthly basis.  Use the techniques discussed in the Daily Process Thoughts on retrospectives to find improvement opportunities.  At the end of each month perform a retrospective focused on tuning the implementation team’s knowledge of the players and how those players are being engaged.

The power of tools like the Bartle Test is to help plan and tailor implementations by focusing on the audience – the player that the change is targeting. Understanding the players will help to design and implement an approach that encourages engagement. And in the longer term, improves the stickiness of the change.

Related Posts on Gamification 

The What and Why of Gamification

How Can We Implement Gamification?

Gamification: Game Mechanics

What Does Gamification Look Like?

Software Process and Measurement Cast (www.spamcast.net)

Gamificaiton increases process adoption rates by increasing engagement and generating community. However, the concept of gamification can feel theoretical without an example, even though many of us use game mechanics all the time, such as Foursquare, Stack Overflow or Ebay. Let’s use the plan I working on to gameify the Software Process and Measurement Cast community as a working example to consider how we would use game mechanics to drive engagement.

Software Process and Measurement Gamification

(Working Draft)

Goal:
Generate increased involvement by the SPaMCAST’s audience with the Cast.  Involvement includes posting comments, providing conference reports, submitting guest columns, re-occurring columns and sponsorships.

Community/Players:

• Audience: Today the majority of the audience is non-participative, but there is a high number of multiple downloads per visit suggesting that the majority of the audience members are Explorers and perhaps Achievers (from Bartle’s Test).  These assumptions need to be tested.
• Motivation: Feedback from similar podcasters indicates that giveaways for interaction can attract spikes in listenership.  Rewards will include review copies of books, copies of my book and badges.  Leaderboards will be used to track progress.
• Culture: Phase 1:  IT culture tends to be a meritocracy that is shaded toward introspection, therefore some mechanism to track reputation would be valuable. Reputation in this case is an assessment of the quality of the responses that player. Early on, the leaderboard might be the only option until reputation tracking can be coded.  Phase 2: Execute an audience survey to generate an audience-culture profile.

Game Mechanics:

• Levels                                   Base Level (rolling six months)

Initiate                                    4 Comments

Participant                          10 Comments

Thought Leader                 50 Comments

Contributor                           2 Guest posts (essays, book or conference review
must be approved by editor)

Columnist                              6 guest posts (essays, book or conference review –
must be approved by editor)

Levels currently assume that we do not have mechanism to track reputation.Rewards to the leader in each category will be made twice annually on a special podcast using review copies of authors books and sponsored swag.

• Challenges: The challenges are presented at the boundaries between levels by presenting an extra step that the player must take in order to pass to the next level.
  • To pass from Initiate to Participant:  Provide interview question(s) for upcoming interview,
  • To pass from Participant to Thought Leader:  Participate in a recorded group discussion (Special Show).
  • To pass from Contributor to Columnist: Commitment to create a monthly column and nomination by three listeners (or quarterly poll)
• Leaderboards: Leaderboards will be used to track all categories separately.  Leaderboard will be posted on a special page on the website.  Postings will be updated on a weekly basis and the top five people in each category will get a call out on each essay show.
• Badges: Virtual merit badges will be provide for Initiates. Physical and Virtual merit badges will provided for all other levels.

Initial Measurement Goals:

1. Comments:                                        50% increase in six month rolling average
2. Content Contributions:                 25% increase in six month rolling average
3. Listenership:                                      20% increase in average monthly download numbers
4. Stickiness:                                           Under discussion

The gamification plan for the Software Process and Measurement Cast is a work in progress.  The intent of sharing the plan was to show that using game mechanics does not have to be overly complicated, but it does require planning.

We use gamification to promote engagement and to encourage players to continue using the process (i.e. stickiness).  To understand if it is worth the effort we are expending to plan, execute and maintain the game mechanics, we need to measure the results.  In the example above listenership and engagement (comments and contributions) are relevant measures, however measuring time on the site would not be relevant. One very simple measure of feedback is if no one is interested in the game. Then there is a mismatch between the players’ culture and the game they are being asked to play.

PS – Ideas, thoughts and comments are welcome.  The plan is actively being fleshed out by the SPaMCAST team.

Daily Process Thoughts:  Gamification Theme

The What and Why of Gamification

How Can We Implement Gamification?

Gamification: Game Mechanics

What Does Gamification Look Like?

Gamification and the Bartle Test

A Nerd Merit Badge for for supporting the Command Line Podcast.

Audience engagement and successful process improvement are strongly correlated.  Creating that engagement requires careful planning and benefits from tools such as gamification.  Gamification is a mechanism that leverages the competitive attributes of the target audience, or ”players,” to channel behavior using game mechanics. The goal is to gain initial adoption of process changes, make them sticky and then to guide the players into process improvement. Common game mechanisms include: badges, competitive challenges, levels, players and leader boards used in an integrated process to guide the players towards an overall goal.

• Badges (also known as achievement badges) provide recognition and feedback.  An achievement badge is a symbol of achievement.  A Boy Scout merit badge is an example of an achievement badge. Physical badges are often one of the more visible mechanisms used in gamification.  Gabe Zichermann, the author of “Gamification by Design” (O’Reilly, 2011), says that badges work when:
  1. They balance aspiration with ability to attain (if you want one badly they should be harder to get);
  2. Look good (ascetics);
  3. Are scarce (not everyone has one), and
  4. Are integrated tightly into the gamification program (the use of badges can’t feel like an add-on).
• Levels represent different magnitudes of accomplishment.  Typically increasing a level provides a player with greater challenge. In a process improvement project, each level should take the “player” to a higher level of skill or add more complexity to the process they are learning. For example, if we were implementing peer reviews supported by gamification, the first level might be “peer review participant” followed by “peer review leader”.
• Challenges are set of tasks or accomplishments to ingrain behavior and provide feedback. Challenges create engagement, but need to be specific to the audience and to induce them to progress along the process life cycle. For example, progressing through peer review participant to peer review leader and finally to peer review master.  The challenges should help encourage the player to progress.
• Leaderboards show players where they rank amongst their peers (those people participating in the game).  The leaderboard puts a spotlight on those at or near the top of the list, which generates competition among the players. Leaderboards can be categorized based on role or teams, depending on the goals of the process improvement and the gamificaiton.
• Players are the target audience for the process or process change.  Players that discover new things, i.e. explorers, are like early adopters and should be identified and encouraged.  Bartle’s Test is a tool that is often referenced to classify the psychological aspects of players. The four general categories are: killers, who provoke and cause drama; achievers, who are competitive and enjoy challenges; explorers, who like to find new things, and socializers, who enjoy relationships among other players. The game mechanics selected have to match the types of players.

These common components are typically linked to together in gamified implementation.  They are also very common in social media applications, such as Foursquare. In Foursquare, players check-in at locations.  The player with the highest number of current check-ins at a location is the mayor (an example of a challenge).  Checking in at specific types of locations, such as coffee shops, is celebrated with achievement badges. Combined well they incentivize behavior that the developers of the process or application want, so that they can attain their business goals while satisfying the need for competition and recognition among the players.

There are many other game mechanics that are not used as often in process improvement implementation, including:

• Player sheets (or personas),
• Progress bars,
• Activity feeds,
• Avatars,
• Real-time feedback,
• Virtual currency,
• Gifting, and
• Trophy case.

The pieces of game mechanics need to be assembled like a jigsaw puzzle so that they coherently support the goal of the project and accentuate the player’s engagement with the process.  The game components should make it fun to learn and improve their skills all while working towards the big picture of goal of the program being implemented.

Daily Process Thoughts:  Gamification Theme

The What and Why of Gamification

How Can We Implement Gamification?

Gamification: Game Mechanics

What Does Gamification Look Like?

Gamification and the Bartle Test

Game Mechanics!

I recently came across some poor implementations of gamification.  In my day job at the David Consulting Group, we license a knowledge management tool that uses game mechanics as a training tool.  IFPUG uses a different knowledge management tool that uses challenges and badges. In both cases, no one pays attention to the game mechanics in the tool because they are not useful or engaging.  These are cases of poorly implemented game mechanics where someone paid a development team to create functionality that does not seem to add value and makes the product feel unplanned.

There are five general areas that impact whether gamification will help or hinder when implementing a process or an application. The five are:

• Goals/objectives
• Community
• Motivation
• Culture
• Design

We will discuss the first four today, and design later in the week.

The first step to implementing gamification is to have an explicit set of goals and objectives for the game mechanics you are using.  For example, take a board game that you like (I like Monopoly, but my wife beats me every time), and find the rules. Usually you find the object of the game prominently printed so that the player knows objective before they start thinking about the game or the rules.  In Classic Monopoly: “the object of the game is to become the wealthiest player through buying, renting and selling property”.  In the Monopoly example, understanding the object of the game helps the player’s learn and absorb the rules and then create their own goals for playing.  In our overview of gamification in  The What and Why of Gamification, I used an example in which the process team implemented a set of challenge goals to support the implementation of peer reviews. The implementation of peer reviews was tied to a broader goal of improving quality and overall efficiency.  By understanding the broader goal, the development teams understood both how the process changes benefited the organization as well as how the challenges related.

Most of the game mechanics that are used when deploying IT applications or processes require either interaction (group challenges) or competition (leader boards).  Players that know each other or are connected as a community are more apt to work together to attain goals and to compete on a healthy basis. Therefore gamification will be more effective to improve adoption of the process or application.

If the users of the process or application do not have a reason to play, then they aren’t going to or, if they do, they will lose interest quickly.  People are motivated in the workplace for many reasons.  Rewards, team esprit de corps, and career advancement are just some.  Reward systems based on a publicly observed tracking mechanism hits the most buttons.  Rewards must be viewed as interesting and useful to players.  The example in The What and Why of Gamification used a trip to the company’s technology conference, company recognition for being selected and the inferred impact on an awardees career as a set of rewards for participation.  The use of leader boards showed how players were tracking toward completing challenges and attaining the reward created a competitive environment.  Sales people that compete to be the top sales person of the month are responding to game mechanics and a reward structure. We use gamification techniques to increase adoption and learning.  Without motivation to participate in the “game” the use of game mechanics is a waste and can derail implementations.

Daily Process Thoughts:  Gamification Theme

The What and Why of Gamification

How Can We Implement Gamification?

Gamification: Game Mechanics

What Does Gamification Look Like?

Gamification and the Bartle Test

Everybody likes a game!

Gamification is a technique that leverages a player’s innate competitive attributes to channel their behavior using game mechanics. The goal is to have individuals, teams, and organizations adopt process changes, then process improvement. Game mechanisms include badges, competitive challenges, levels, players and leader boards used in an integrated process to guide the players towards an overall goal. These concepts might sound foreign to you, but if you have ever participated in Boy Scouts, Girl Guides, Foursquare, TripAdvisor, World of Warcraft or even the venerable Dungeons and Dragons, you have participated in the use of game mechanics. Whether an app or a game, all of these examples deliver challenges to participants and then provide feedback to generate competition. Gamification motivates players to engage and adopt process changes using that competition. However, the addition of gaming mechanics to the development community can also improve collaboration if used appropriately.

Game mechanisms, such as challenges, badges and leader boards, use healthy competition and performance feedback.  For example, an organization I worked with identified set of challenge goals for a new set of development processes.  Two of the goals set for developers were that they 1) led at least 20 peer reviews as lead peer reviewers, and 2) that the first two developers that completed 50 and took a facilitation class could be designated master peer reviewers. The process improvement group posted a leader board on their SharePoint so that everyone could keep track as team members progressed against the challenges. The challenges and the feedback generated from the leaderboard created an atmosphere of collegial competition that generated engagement. The same organization holds an annual technical conference.  Attendance at the conference is by invite only (however the entire organization’s IT group could attend virtually).  As an incentive, the members of IT that had achieved the top goals in each category a month before the conference were guaranteed an invitation and a spot on a discussion panel on IT processes at the conference.

Using public leader boards can help your group identify leaders in the process knowledge community. Employees can be rewarded for participation and or their contributions to the organization’s process knowledge base. Gamificaiton not only increases process adoption rates by increasing engagement, it also helps to generate community. In the example above, one of the more interesting side effects was that loose teams formed to push members to the top of the list. A second side effect was that members of the overall development community were motivated to adopt the new processes early so that they would not be disadvantaged in the competition (if you start too late you will never be able to catch up). The bottom-line goal of gamification is to influence the organization to adopt desired behaviors.

Daily Process Thoughts on Gamification

The What and Why of Gamification

How Can We Implement Gamification?

Gamification: Game Mechanics

What Does Gamification Look Like?

Gamification and the Bartle Test

Tipping Point

The Tipping Point by Malcolm Gladwell, Re-read Week 4 – Chapter 3: The Stickiness Factor

Chapter Three of Malcolm Gladwell’s The Tipping Point is a reminder of why this book continues to be important and useful. The density of ideas in this chapter is amazing. Stop borrowing your best friends copy and buy a copy of the book for yourself!  

Chapter Two, The Law of the Few, describes the role of people in passing messages along.  Chapter Three tackles stickiness. Stickiness is the attribute that determines whether a message is heard and internalized. Messages that are heard and internalized stand a chance to be acted upon. In this chapter, Gladwell uses Sesame Street and Blues Clues as the vehicle to discuss how messages can be packaged to make them sticky.   (more…)

Metrics Are About Prediction

There are three reasons to measure. The first is to guide specific behaviors. The second is to provide information on the status of process. And the third is as a tool to help predict the future. At a team level it is easy to take a very narrow view of metrics and measurement, however the organization is another significant stakeholder in the collection and consumption of metrics information. Teams and other organizational stakeholders have different metrics needs for each of three basic reasons for measuring.  Part of maturing as an Agile organization is the development of a common understanding of metrics needs that includes the differences between groups.  Reaching a common understanding is a step toward developing the mechanisms to accommodate all of the relevant metrics needs within the organization.

Different stakeholders have different measurement needs and perspectives.  Occasionally there is a suggestion that the only measurement data that Agile should generate is what the team needs.  While teams and other organizational stakeholders, such as product, IT and executive management, can (and should) use similar tools, organizational data needs extend to being able to monitor and guide the Agile transformation and other process improvement efforts. Those needs will require everyone involved collect a wider range of data and generate different metrics.

The Software Process and Measurement Cast features my interview with Gene Hughson.  Listen to it here. We discussed Agile, solution architecture, people, processes and his blog. An early holiday present!

Gene Hughson is an Applications Manager for Fidelity National Financial in Richmond, Virginia.  Gene has over 17 years of experience in software development, combining application and solution architecture, management and process improvement, even managing to do some hands-on coding from time to time.  Gene has been a member of the Richmond Chapter of the Association of Information Technology Professionals (AITP), serving as President for 2013 and continuing in that capacity for 2014.  Gene has written guest posts for CitizenTekk (http://citizentekk.com/author/genehughson/) and maintains his own blog, Form Follows Function (http://genehughson.wordpress.com/), where he opines on architecture, management, and software development processes.

Other ways to track Gene down …
LinkedIn: http://ow.ly/rMrN9
Twitter: @GeneHughson
Google+: https://plus.google.com/+GeneHughson/posts

The Software Process and Measurement Cast 269 features our essay on gamification. Gamification is a technique that leverages innate competitive attributes of IT development” players” to channel behavior using game mechanics. A powerful tool for channeling and supporting organizational change.

Also, for the next few weeks the Software Process and Measurement Cast will include a promo for the “Influential Agile Leader” events led by Johanna Rothman and Gil Broza.  Check out the full details at www.InfluentialAgileLeader.com

The Software Process and Measurement Cast has a sponsor .

ITMPI provides a great service to the IT profession. ITMPI’s mission is to pull together the expertise and educational efforts of the world’s leading IT thought leaders and to create a single online destination where IT practitioners and executives can meet all of their educational and professional development needs. The ITMPI offers a premium membership that gives members unlimited free access to 400 PDU accredited webinar recordings, and waives the PDU processing fees on all live and recorded webinars.  The Software Process and Measurement Cast receives a fee if you sign up using the URL in the show notes. http://mbsy.co/fGdw  All revenue our sponsors goes for bandwidth, hosting and new cool equipment to create more and better content for you!  Support the SPaMCAST and learn from the ITMPI!

Do you have a Facebook account?  If you do please visit and like the Software Process and Measurement Cast page on Facebook.

One more thing!  Help support the SPaMCAST by reviewing and rating the Software Process and Measurement Cast on iTunes! It helps people find the cast.

Shameless Ad for my book! Mastering Software Project Management: Best Practices, Tools and Techniques co-authored by Murali Chematuri and myself and published by J. Ross Publishing. We have received unsolicited reviews like the following: “This book will prove that software projects should not be a tedious process, neither for you or your team.” NOW AVAILABLE IN CHINESE!

Have you bought your copy?

One persona or many?

Fleshing out the user needs is one of the most critical steps in the process of generating an Agile Story Map.  Sometimes it is easy to jump over the creation of user needs and the stories that are needed to satisfy those needs, and jump directly into the mechanics of building the Story Map, but you will not derive the same value in the end. Personas are an oft-practiced tool used to  help you focus on the generation of user needs and stories.

What Are Personas?

Personas are a metaphor for groups of systems users that were originally introduced by Alan Cooper. Roman Pitchler later suggested a template for a simple version of personas, which included: the persona name, a picture, behavioral characteristics, and business needs.  The first two categories help define the “who” part of the persona, while the rest describe the “why,” i.e. why the person would use the system. The concept of personas is used widely, inside and outside of IT.

The information used to define a persona varies by how the persona is going to be used. Thus there are many other, specialized versions of personas that include other data.  Examples of the other data include: capabilities, attitudes, involvement, age, location, likes and dislikes and technical comfort – just to name a few. I strongly suggest that persona you use be only as complex as it absolutely has to be. Use only the data that is relevant. For general IT projects, I generally use Pitchler’s template and then add location and technical comfort. (We will revisit this concept when we discuss gamification. There more complex personas may be needed.)  Always include a picture when defining personas.  Pictures help to draw in visual learners While I am not an artist, I feel that a hand-drawn picture is better than a photo to reinforce the idea that a persona rarely represents a single person, but rather is a metaphor for a group.

Mining or Defining Personas

Many Agile teams use User stories to delineate pieces of work.  User stories follow a pattern of “As a <user type>, I want to <function> so that I can <business value>.”  User type can be considered as generic starting point for defining a persona. If you use user stories, isolate the user types, group like user types together, give them a name and then complete the template for each persona.

Another place to start, if you have been using use cases, is to gather all of the “actors” that have been identified.  As with user types, group like actors together, name them and complete the template.

If you are not using use cases, user stories or any other user-centered documentation methods, start with a brainstorming workshop to identify the types of users and personas you and the software will be interacting with.  To help the session along, I use seed questions such as:

• What departments will use this software?
• What types of users roles are there?
• What customers will interact with the software?
• What are the goals type of customer trying to accomplish with the software?

When you have completed the brainstorming session use mute grouping (affinity diagraming) to cluster the roles.  Then name each distinct group and complete a persona template for each.

In Agile, personas are a tool that is used in many situations, such as developing user stories or generating an Agile Story Map. They can be used to focus the discussion of requirements, needs and stories on the types of people that will be interacting with the project or application. Because personas are named and tied to a picture, they are far less impersonal. It is easier for team members to feel a relationship.  The ability to relate to the people that the persona is a metaphor for improves our ability to put ourselves in their place and discover their requirements and needs.