While having a chat with Naresh Jain, he suggested me to go through the Ted Talk – “Gaming can make a better world” by Jane McGonigal. I found the title very weird and was wondering how is that possible? After going through the talk though, I was amazed. I started wondering if I can use the gamification technique in Agile Adoption, in our Products, in Performance Management Systems, in Employee Engagement Programs?

Dhaval Dalal introduced me to Prof. Kevin Werbach’s definition of Gamification – “The use of game elements and game design techniques in non-game contexts.”

For our 4^th ShipIt Day, organized on 25^th/26^th Sept 2014 at IDeaS, I decided to explore the idea of using game elements and game design techniques in the context of Agile Adoption. The idea was to create a gaming system which will automatically collect data, i.e. without explicit user intervention,  from multiple sources like Jenkins, Rally and manually from individuals and offer Star’s for positive behavior and deduct Star’s otherwise.

The aim was to help the team get continuous visual feedback on how they are doing, adopt agile practices, visualize sense of accountability, visualize sense of achievement, drive positive behavior, create healthy competition, create a culture of appreciation, help performance tracking and create transparency.

We are moving from traditional water fall model of development to Agile way of development. We use Jenkins for continuous integration and Rally to track our stories.

Jenkins had some part of gamification techniques already available via The Continuous Integration Game plugin. Below are the rules of the Jenkins CI game

• -10 points for breaking a build
• 0 points for breaking a build that already was broken
• +1 points for doing a build with no failures (unstable builds gives no points)
• -1 points for each new test failures
• +1 points for each new test that passes

In Rally, we do story mapping. We follow certain processes like

• Every story in the iteration should have story level planned estimates.
• Every story in the iteration should have tasks.
• One should update the Actual and TODO for the Rally task they are working on every day.
• The stories should be completed and accepted within the iteration.
• Story spill overs into next iteration should be low.

It was not possible to work on this idea alone and I am glad and thankful that I got support from Umesh Kale – who helped with the UX, Vishal Gokhale – who helped with the Jenkins Plugin. Paresh Dahiwal – who helped with the Rally plugin and Sameer Shah – who helped with QA.

I am glad to present the game “IDeaS Rock Stars“.

The web-app has two sections

• A departmental leader board – that shows
  1. Star of the Day ( Top three individuals, who earned most stars in a day. )
  2. Star of the Week.
  3. Star of the Month.
  4. Most Appreciated ( Top three individuals who have earned most stars so far. )
  5. Most Appreciative ( Individuals who appreciate other’s contribution. Encourages individuals to recognize other’s contributions. )
  6. Open Missions ( Open missions/quests are visible across departments. Quests help in creating the culture of taking initiatives, being pro-active; helps in earning more Stars. Encourages cross department collaboration in addressing issues.)

• Self-Board – that shows
  1. Stars that I have got ( Show off your stars with pride. )
  2. My Department ( Where do I stand with respect to others in my department? instant feedback on how hard I have to work to earn stars. )
  3. Who is getting Stars? ( Why are others getting stars? how can I earn more stars. )
  4. Why are my stars are getting added or deducted ( Instant and specific feedback, encourages positive behavior.)

• Self-Board – Appreciate Someone
  • encourages the culture of appreciation.
  • individual can give +1 star per appreciation.
  • managers can give or deduct more than 1 stars.

• Self-Board – Create Mission
  • Managers can create additional missions.
  • Missions/Quests are a nice way of earning more Stars.
  • Missions/Quests are visible across departments. Other department may be in a better position to solve your problems! Encourages cross department collaboration.

• Badges
  • Show off your badges as you earn Stars.

Jenkins Plugin – an extension of The Continuous Integration Game plugin which sends out stars to the IDeaS Rock Star game. It also sends stars for the downstream builds.

Rally Plugin – custom standalone java program that scans Rally and sends out stars to the IDeaS Rock Star game based on the rules that we have defined.

Based on our teams values and processes, below list shows how to earn Star’s. Other teams/departments can choose to have their own structure of earning Stars.

Reason	Stars	Behavior
for breaking a build that already was broken.	0	discourages developers from checking in code when the build is already broken. Encourages them to fix a broken build.
for doing a build with no failures. unstable builds gives no stars.	1	encourages developers to produce good builds. Encourages developers to check in more frequently to collect more stars. More frequent check-in leads to faster code integration.
for each new test that passes.	1	encourages developers to add new test scenarios with every check in. More quality, automated test scenarios, lesser effort required on manual testing. Aids quick feedback.
for updating actual and todo in rally every day.	1	encourages developers to follow standard process which helps in getting correct velocity.
for setting planned estimates at story/defect level. Stars given to story owners, story task owners.	1	encourages developers to follow standard process which helps in getting correct velocity/burn down.
for completing the story within the iteration. Stars given to story owners, story task owners.	10	encourages team work, encourages developers/qa/product owners to better slice the story and finish the story in one iteration.
for getting the story accepted in the same iteration. Stars given to story owners, story task owners.	10	encourages team work, encourages developers/qa/product owners to better slice the story, finish and get the story accepted within iteration.
for giving internal training, presentations; knowledge sharing. you have to claim these stars from your manager	30	encourages and enhances presentation skills, knowledge sharing, encourages continuous dialogue with managers.
for participating and presenting your idea in ShipIt. you have to claim these stars from your manager.	50	encourages innovation, initiative, proactivness.
for writing technical blogs, articles, answering stack overflow questions etc. you have to claim these stars from your manager.	50	encourages knowledge sharing, community contribution and expression of thoughts.
for open source contribution. you have to claim these stars from your manager.	75	encourages community contribution.
for becoming ShipIt Innovator. you have to claim these stars from your manager.	100	encourages innovation, initiative, proactivness.
for giving presentations in technology conferences. you have to claim these stars from your manager.	200	encourages developers/qa to participate in conferences, knowledge sharing, branding.
Wild Card – other tangible/intangible value addition/creation. You have to claim these stars from your managers. These stars are discretionary; based on perceived value addition.	*	encourages going above and beyond your responsibilities. Encourages continuous dialog with managers.
for each new test failures	-1	discourages bugs, encourages fixing flaky tests.
if story/defect does not have planned estimates (per day). Stars removed from story owners, story task owners. Associate leads and above get -2 per story that does not have planned estimates.	-2	encourages dialog between leads and team members.
For not tasking a story (per day). Stars removed from story owners. Associate leads and above get -2 per story that does not have tasks.	-5	encourages planning
for NOT updating actual and todo in rally every day.	-5	encourages developers/qa to follow process. Historical actual data helps to determine how much efforts went on a particular module/feature/release etc.
for breaking a build.	-10	encourages taking builds on local machine before check-in. encourages fixing flaky tests. encourages team members to respect each others valuable time.
for story spill over. Stars removed from story owners, story task owners. Associate leads and above get -5 per story that gets spilled over.	-20	encourages planning, story mapping, slicing and completing the story in the given iteration and getting quicker feedback.
for leaving the story in prior iterations without getting those accepted. Stars removed from story task owners.	-20	encourages dialog between product owners, managers and members and making sure that the work is complete.
Production Bug. Stars deducted from all the individuals involved in the story. Product owners, developers, qa. Based on managers discretion as not every bug has the same impact.	-200	encourages code quality.

Simple way of gaining big stars -> If I am working on a story for a complete iteration (8 working days) and I check in code 3 times a day and I add two new test scenarios per check-in and I make sure that the story is complete and accepted within the iteration, it gives me 100 stars. Better sliced stories, following agile practices give me even better reward!

Reason	Stars per check-in	Code check in frequency	Total
Weekly Stars
completing the story	10		10
getting the story accepted in same iteration	10		10
Total weekly Stars			20
Daily Stars
giving stable build	1	3	3
adding new test scenarios per check-in	2	3	6
updating rally	1		1
Total Daily Stars			10
Total Stars for 8 days i.e (10*8)			80
TOTAL STARS			100

Once you are done with your stories, you can earn additional stars by helping other members of the team in achieving their stories within the iteration.

The game has been running for the last two weeks and my team has gladly agreed to run a trial period of about a month to see how it works.

The next step is to put up LCD to show off the departmental leader board.

I have seen a lot of excitement around the game… Only time will tell how it works… Statistics to follow…

Gamifying Agile Adoption – An Experiment – Part 2