Let’s imagine that yours’ is an agile software development organization comprised of 10 teams of three to eight developers plus all of the other roles each agile team requires.  Our objective is to continually assess the effectiveness of software development personnel against known delivery and quality performance on an epoch by epoch basic, where epoch corresponds to spikes, sprints, and releases.  

 

Let’s further imagine that your Application Lifecycle Management (ALM), Quality Assurance (QA), build pipeline (CI/CD), and source code management (SCM) platforms are able to provide events on configurable business activities that result from team member activity.  Specifically, let’s say that we are currently interested in the following business events by individual.

 

ALM) From Application Lifecycle Management we want to know when the following occurs: 1) Task Defined, 2) Task Assigned, 3) Task Completion, 4) Task Rework Assigned, 5) Daily Task Remaining, 6) Feature Suggestion, and 7) Feature Acceptance.

 

CI/CD) From the build pipeline we want to know: 1) Build Broken, 2) Build Fixed. 

 

QA) From Quality Assurance we want to know when: 1) Bug Reported, and 2) Bug Fixed.

 

SCM) From source code management we want to know when there is a: 1) Pull Request, 2) Push, 3) Pair Programming Contributor, and 4) Commit Reviewer.

 

From these system generated events we can readily glean activity and community traits related to ALM, CI/CD, QA, and SCM.  But that does not tell the whole story.

 

Intangibles for which there is insufficient information might include identification of individuals: 1) most vested in helping others to succeed, 2) willingness to share knowledge, 3) responsive to other’s requests, 4) pleasant to work with or that positively contributes to quality of work-life.  These intangibles and others like them are what gamification can contribute to the data available from ALM, QA, BP, and SCM.  

 

We can understand these intangibles by allowing the team to provide information such as the following about their colleagues at task completion and end-of-day junctures: 1) Helpful, 2) Pleasant Experience, 3) Responsive, 4) Positive Observation, 5) Peer Feature Suggestion Like, 6) Unhelpful, 7) Unpleasant Experience, 8) Unresponsive, and 9) Negative Observation.  These observations land on the ledger of the person that they are about.  Each negative observation (6-8) is accompanied by a “Negative Observation” (9) observation attributed to the person making the observation, but the person making the observation is not otherwise logged so as to provide anonymity as well as to minimize negative observations being made.

 

For each auto-generated and manually contributed event type, the game administrator assigns “debit” points for positive activities and “credit” points for negative activities, according to what the organization values.  

 

For example, the game administrator might give the following values to a few of the above mentioned events.  “Task Defined” debits (positive value) the user’s game journal by one, where, “Task Rework Assigned” would credit (negative value) the user’s game journal by one.  Each of the events can be reassigned value for each game played.

 

The gamification model will keep a running total for each individual as well as each change so as to be able to explain what comprises the total.  An instance of the game runs for each team in alignment with spikes, sprints, and releases.  Refinements can be made in the configuration of each game.  Analytics can be run within and across games.

 

The next post will discuss the TLD model to support Agile Gamification.