My New Found Hobby – Sketching

Every year during Christmas/New Year period I take a break from the routine to explore locations and at times to explore a different side of me.

As a kid I liked to draw, it got lost in transit to adulthood; So during the break of 2016, I thought of giving sketching a shot. Below is how I am progressing on my sketching attempts…

12th Feb 2017 - Afghan Girl

12th Feb 2017 – Afghan Girl


Anne Hathaway

7th Jan 2017 – Anne Hathaway


31st Dec 2016 – Catherine Zeta Jones




30th Dec 2016 – Deepika Padukone



28th Dec 2016 – Angelina Jolie




27th Dec 2016 – Emma Watson


26th Dec 2016 – Madhubala


25th Dec 2016 – Elsa





Quack Quack Quirks

Recently I underwent a LPI based assessment session by getting 360 feedback from my manager, peers, direct reports and others in the organisation I work with. Through this feedback & assessment, I got insights on how the people around perceive me and I got to know my perceived strengths as well as perceived weaknesses. This got me thinking; I started listing down the aspects of my behaviour that may be leading to the perceived strengths and weaknesses. As I scanned through the list, I realised that some of the behaviours, leading to my weaknesses, were very natural to me, they were my DNA. Did I really want to change my DNA and turn into someone else? I started wondering how nice it would be if people could accept me along with my quirks.

K.S. Prashant recently blogged about “Seeking Sheldon”… After reading it, I felt that though I am not a “Sheldon”, a lot of us have some amount of Sheldon in us and we value it as part of our identity. Some go into silence; other’s miss meals; some others look visibly disinterested and so on. Probably, understanding and respecting these quirks to some extent, would be the least we could do to help these individuals overcome the conflict with their current challenges. I echo the thoughts from “Seeking Sheldon” and agree that forcing them to do the normal and confirmatory in these times would probably lead to inefficiency, resistance and chaos.

The question was how does one drive a group to be tolerant to these quirks? Is it really possible to stick to one’s core DNA and still manage perception? I started wondering whether I would be able to increase my team’s tolerance for me, by explicitly talking about my quirks/behavioural traits? Would that help in managing perception? If I try to understand someone else’s DNA, would it increase my tolerance for that person?

Around the same time, a new member was about to join one of the teams I work with. New members come from a different work cultures, which could differ from the current mainstream. When we are not aware about each other’s work culture, it becomes difficult to understand why people behave in a particular way or what is expected from them. I believe that “culture” is based on shared “values” of the constituent members and their actions are reflections of their values. This triggered another set of thoughts. Questions that are fundamental to an organised environment. What is our culture? Does every team member consciously understand what our culture is? Do I know what are the team’s values? Does the team know what my values are? Does any new member joining the team have the same understanding and definitions?

With the endless questions running through my mind on these converging thoughts, my brain started picking up the ingredients to create a new experimental recipe. I got the team together and decided to have a “Getting to know each other” session. Each individual would get few days to prepare for the session and would talk about the 4 points below

  • Secrets of my Success – I believe that taking a pause to first introspect and then to share the behavioural attributes/actions that individuals take, which they believe has helped them in achieving success, is a great opportunity for everyone to learn from one another.
  • My Aspirations – I believe that by publicly listing your aspirations, you become more accountable in achieving those. In LPI, there are observers to observe your behaviour. Here, the aim was to have observers within the team to consciously observe and help you achieve your aspirations.
  • My Values – I believe that our actions are the reflections of our values. As you understand what the other person values, it becomes easier to understand why they behave in a particular way, which also helps in understanding their point of view.
  • Help Me – Any specific help the individuals need from their observers.


I believe that, collectively, the four points would expose the real person behind the perceived facade and just getting to know the person’s values and DNA would increase tolerance for each other.

I must say that, personally, it was a fulfilling experience for me and was also glad to see the team members opening up in front of each other.

I strongly believe, this exercise, has helped us break any communication barriers we had and helped us work with our collective strengths and mitigate our weaknesses. Most importantly, I felt at peace with myself as with increased tolerance, every individual in the team while retaining their true self and the quirks that come along, would be able to support each other well!


Have you attempted anything like this? What has been your experience? Share them in the comments section below.

Waterfall to Agile – A Journey to Remember

Waterfall to Agile

Long time ago, we were a typical java waterfall shop and our build and deployment practices by today’s standard were Stonehenge… we had 6 monthly release cycles, tentatively 2 months for discovery/design, 2 months for development and 2 months for testing. We used to have weekly builds on every Wednesday, we had to maintain change logs manually, tag files in CVS manually and have spent countless nights on the build days to integrate all the code changes by all the developers and stumble through the erroneous process to produce a stable build, really speaking a build that would compile. Lot of time was spent on manual testing and we had long regression cycles, our discovery process would also last till our testing cycle as during development as well as testing lot of requirements got cleared as not everyone was involved in the discover and the design cycle, naturally requiring more time to complete the feature. Working late nights and on weekends was a norm. There was very little trust between product management, developers and testers, requiring every piece of information to be written down as a requirement, even the smallest of smallest things. By the time information reached the developers and testers, the “why” component was lost, the goal was to complete what was written in the documents and not really on delivering value. Reading a document is very subjective as individuals based on their experiences, exposure and preconditioning can interpret a statement in any way, leading to not implementing a feature as envisioned by the product management and it was always too late to discover that something was missed. With long release cycle, it was typical to think of every possible feature and pack it in the release, because if you miss the train then you will get the feature after a year. Release delays were typical and would not meet the client expectations. None of the parties would feel satisfied no matter how much efforts they put in.

The performance of testing team members was measured based on the number of defects they find. So there was no vested interest to prevent bugs from getting into the product during the development cycle. The developers thought their job was over once they committed their code and thought that testing was testers job. There was almost a wall between every team. Developers and testers had to estimate the amount of time required to complete the feature and test the feature and the estimates were supposed to be “correct”. If the estimates were not “correct”, then the developers and testers were not doing a good job.

All this lead to lot of bad behavior and left bitter taste.

Sounds familiar?

From the start of my development career, till 2009, I had been writing code and I would spend a lot of time to make sure that the code works as expected by doing lot of manual unit testing. In 2009, my colleague Tristan Bezotte introduced me to JUNITs. I started writing JUnit tests and was in awe of the power that JUnits brought. All the tests that I had thought in my mind, which I would run with every code change multiple times manually, spending lot of time setting up the container etc, now I could code them in JUNITs and run those outside the container in seconds. It saved me immense time as they would run very fast and I would be able to run them every time the code was changed. I just couldn’t believe how I could survive without writing JUNIT tests for so long in my career. Now I cannot write code without having tests.

In the same year Tristan Bezotte also introduced me to Hudson CI. As I had spent countless nights integrating the code on the weekly build day, the power of Continuous Integration was evident and again I was in an awe of CI. I introduced Hudson for one of our core product in early 2010. It was a no-brainer and an easy sale.

  • No need to maintain change logs.
  • Automatic build whenever someone committed the code.
    1. We still had weekly builds, but the amount of time spent on those builds had reduced significantly. No more late nights for code integration.
  • Quick feedback on build failures.
    1. Ease of identification of the root cause of why the build failed because of few commits per build.
    2. All the unit tests run after the compilation, so if someone commits code that causes tests to fail, you would immediately know that you have introduced a bug.
    3. Encouraged developers to commit code frequently for faster feedback.
    4. Code quality violations using PMD, Findbugs.
  • Constant availability for the last stable build.
    1. Earlier QA would have to wait for 7 days to get a build. Now they can pick up the next stable build and start testing.
    2. Ability of deploying the war after the build.
  • Ability to get code coverage to understand which flows are not getting covered using automated tests.

The team benefited a lot from this small change. I still remember that sometime in 2006, when I also played a build engineer role, Jim Mathews had asked me to think over having multiple builds a day instead of one weekly build and I was like “why”? what’s the “need” of having frequent builds a day? I realized my naivetés only after I was introduced to Hudson in 2010. I still regret not going Continuous Integration route as early as in 2006. Anyways, better late than never and I again started wondering how could I as a developer survive without having Continuous Integration in place. The next task was to showcase the power of JUNITs to my colleagues. I could manage to pursue some of them.


By end of 2010, I moved to a new product which was being developed using the Agile philosophy and I started working as a product owner. I was glad to get the initial coaching from David Hussman. I also got an opportunity to attend couple of devjam sessions. With the two years that I spend with the new product development team and the agile approach, I was again in awe of Agile. I connected with the agile approach of focusing on “value”, “failing fast”, “learning and course correcting” over “lengthy project plans“, “estimation“, “delivering what was written” . It took me some time to go away from thinking about the entire problem at one go, to thinking in terms of “mile wide and inch deep” or the steel thread approach. Sometimes, though the concepts were understood, it was getting difficult to apply those in real life when lot of back-end activity was involved. In those two years I learned a lot.


In 2012, while I was working on the new product, I had to come back to work on the existing product and had to manage the team and the delivery of that product. This team was still working with the waterfall mindset. The team had many new members, product management got new members, and we had to create a new product offering. I had got a big requirement document and had to deliver this new product offering in time while focusing on the new product that I was already working on simultaneously. From my point of view, there was no way for me to deliver the product with almost new team while continuing with waterfall model. I was also not in a position to completely alter landscape of the way this product was being developed. Every change has its own learning curve and I did not want to cause a disruption. My option was to run a covert operation based on all the experience that I had gained in the prior two years. I decided to pick up few agile practices that I had learnt while working on the other product and to apply them in the current context without uttering the word “Agile”.

Practice 1 – Acceptance Test & Value – I started adding Acceptance tests within the requirement document. This helped a lot in terms of getting clarity on the requirement. Product Management was forced to think “why” this feature is being added and what is the value it is generating, how to know whether the development and testing team delivered as per expectation. Product management also had to go through this new learning curve of writing acceptance test and figure out the relative priority and over a period of time we all improved. The development and testing teams were involved in going through the acceptance tests and adding acceptance tests, so many surprises where taken care off and it helped teams to get on the same page for most of the requirements.

Practice 2 – Prioritizing the requirements based on their perceived value helped us in delivering the most valuable feature first. The idea is that if there are delays, then the least valuable (nice to have, good to have) items get dropped and the most valuable items are taken care off. Teams also started understanding that not every piece of code/feature is important, so they could focus their energies well.

Practice 3 – Weekly Demos – As the team was new and lacked in domain, it was imperative to gives weekly demos to the product management to ensure that we were not deviating from the expectations and red flags were highlighted early.

Practice 4 – Daily product management road block removal meeting (or stand-ups) – text is very subjective to read, this meeting gave the team members involved an opportunity to directly interact with product management and get clarification on text that was ambiguous resulting in failing fast and early course correction.

Practice 5 – Continuous Integration & Dev environment deployment – Hudson was already in place, by now it had forked into Jenkins and we opted to go with Jenkins. The goal was to add as many tests as possible and deploy the war once a day using Jenkins so that product management can look at progress on daily basis and accept the features as they were completed. The second goal was to make build artifacts available after every build so that the concerned testers can pick up the latest artifacts and start testing immediately and go away from weekly builds.

With this covert operation, we got great success and I was very glad that the small changes worked without too much of disruption. With successful deliveries of few more releases using the same approach, the trust between Product Management and SD/QA started increasing. As trust increases, the amount of what you can achieve goes up because the energy is not spent on blame games and focus is on what we can improvise. The next goal was to formally introduce agile & agile tools, I started with having sessions on Agile, Stories, Rally, Continuous Integration and Deployment for both Product Management and SD/QA. With the success in 2012, Product Management and the SD/QA team were very supportive of the changes done and were ready to move and embrace additional agile practices.


In 2013, I started completely focusing on this product. In addition to earlier practices, we introduced other practices like iterations, stories, backlog grooming. The biggest challenge of 2013 was to bring SD & QA to work together as one team, i.e. as partners and not see each other as enemies. The second challenge was to complete both development and testing within the same iteration. The third challenge was to get every one to write JUNIT tests. The fourth challenge was to get around the notion that if now I have to also write Junit test cases, along with my code, I will need more time.

QA was no more rated based on the number of issues they find and developers job was not over after committing the code. Development and testing members had to collaborate on a story and their collective goal was to make sure that bugs do not get into the code in the first place and the work is complete and delivered within an iteration as per Product Management expectations with appropriate tests. This was not so smooth journey. For both the teams, collaboration, pairing, writing automated tests and completing testing within the same iteration was a difficult habit to build. I had to spend a lot of time and energy with my leads to give them an alternative perspective of the future and helped them through the change required in the mindset and later changes required in the teams mindset. Looking back, it was a great experience and I think the blood, sweat and tears shedded were worth it. Gradually our focus shifted from manual testing to automation testing, which helped in getting closer to our goal of completing the testing within the same iteration. We started introducing lot of GUI automation tests using QTP and then Selenium and the data validation was being done on the GUI. Our automation tests started running slow. Only one person was able to write these tests and it started creating bottlenecks. By end of 2013, we had started getting better at the process part but we had not focused so much on the engineering practices.


For the complete 2014, we had Naresh Jain and Dhaval Dalal in our Pune office to coach the teams on Agile and Engineering practice. We were very glad that we had Naresh Jain with us who had started Agile India movement. Via Naresh, I got a chance to meet and attend Jeff Patton‘s “Story Mapping” workshop. Naresh & Dhaval  helped the development teams on their engineering practices. Naresh helped us realize the importance of writing blogs, community contribution and presenting in various conference. He also helped us with our hiring process.

I introduced IDeaS Rock Star, a gamification approach to help team members adopt agile practices and values. My blog talks about our effort on reducing Jenkins Build Time. Due to Naresh’s influence, I think I have discovered that sharing what I have learnt, in conferences is my new found love and I have talked about both “Gamifying Agile Adoption” and “On a Quest to reduce Jenkins Build Time” and various conferences. So far I have presented at Agile Pune 2014, Agile India 2015, Indic Thread  2015 and RallyOn 2015. My other blog talks about my first public speaking experience. There is so much to learn during and after the sharing experiences in these conferences.

Naresh helped QA with the automation tests. We soon realized that our approach with automation testing was wrong. He helped us with understanding the inverted test pyramid and changed our perspective of automation testing. Sachin Natu gave a presentation on Inverted Test Pyramid at both Agile Pune 2014 and Agile India 2015. Aditya Saigaonkar & Kirtesh Wani presented “Selenium DeTox for Achieving the Right Testing Pyramid” at Selenium conference 2014.

This year we introduced more practices like pairing, test driven development, devbox testing. We had not hired our testing team to write code. At the time of their hiring the focus was on manual testing so coding skills were not required. Now in the changing circumstance, we were expecting the testing team members to pair with the development teams and ensure that they are covering most of the scenarios as part of the unit tests and eventually start contributing to writing tests. Because of their lack of coding skills it was becoming very difficult for them to really contribute in figuring out whether the automation tests were actually testing all the scenarios as well as write any new. So they would land up running the same scenarios manually. After realizing this problem, I decided to coach them on reading and writing in Java language. We started with test driven development. I have come to realize that when any one is taught a new language, one should always start with tests and right from the get go, imbibe in their mind that without tests coding cannot be done. I think the same approach should be followed in our educational institutions. This effort was carried forward by Kirtesh Wani. This effort gave varying levels of success. Most of the testing team understood the importance of upgrading their skills, writing automated tests and knowing how to read and write code. Cucumber was introduced and most of the testing team started getting involved in the coding and over a period of time were able to contribute in the automation effort.

Based on what I learned from Naresh & Dhaval, for one of our internal support product, I decided to apply agile approach and decided to go away from 4 monthly waterfall release cycle to weekly deployments in production. The team worked with the internal clients directly, focused on story mapping and on items that added highest value, started writing automation tests in JUNITs,  Cucumber and Spock. Naresh and Dhaval helped in refining our processes, practices and reviewing our code and tests. The internal clients were involved during prioritization, story mapping, planning, stand-ups and demos. The outcome was magnificent. We had very happy internal clients as we were able to deliver high value in a given time. We had managed to reduce a lot of wasted efforts and were able generate good returns on our development efforts.

In 2015 I moved back to the new product. By end of 2014 and early 2015 our expectations were that complete automation testing should be done with the same iteration. Jasmine was introduced for GUI Unit Tests. I am very glad that Aditya Saigaonkar and Sameer Shah are leading this effort and taking it forward from where it was started. They have managed to actually realize the dream. They are also working on getting our regression time down by focusing on automation testing. We are also working on continuous deployment and reducing our release cycles.

Every day we are getting better at what we are doing and we are getting closer, in terms of agile adoption and engineering practices, to our new product which we deploy to production every two weeks. This is not the end, the journey continuous. The next I believe is to embrace the lean startup mindset… We are on our way forward!

On a quest of reducing Jenkins build time – Part 2

Previous – On a quest of reducing Jenkins build time – Part 1.

With all our efforts we had managed to get our build pipeline time down to under 12 minutes. Our quest still continues…

pipe line 1

We were using cvs and our build job was taking couple of minutes just to determine the change log. The next target was to check if migrating from cvs to svn would help us reduce our build times further.

Matthew Meyers (our infrastructure guru) who works at IDeas Inc, had setup a cool Jenkins infrastructure in IDeaS Data Center for our next generation product. While having a conversation with him he suggested that we could do an experiment of migrating the local Jenkins infrastructure to data center and also migrating from cvs to svn to check if it helps us further reduce our build times.

Matthew created a dedicated Jenkins Slave for this effort, migrated cvs to svn and did the setup of this parallel experimental infrastructure. After some initial hiccups, we got all the tests running fine and we were delighted to see that the total build pipeline time had reduced down to less than 8 minutes. SVN migration, bigger better machines, SAN infrastructure had helped reduce the build timings.

We finalized a date when we would cut over to this new infrastructure. The cut over went through fine too. Now we have a nice consolidate Jenkins infrastructure in our data center.

This migration had its own share of new learning…


Matthew introduced me to robocopy. Robocopy is so cool. Earlier we were using simple copy command to copy workspace, database and files in general. Robocopy has a feature of mirroring files in the source folder to destination folder and the cool thing is that it can automatically skip copying files that are not modified. This feature helps in saving lot time while doing file operations.

This ability helped us in adding two more test jobs 1) REST Test 2) Business Driven Tests in our build pipeline which we could not do earlier as both the jobs required us to deploy the application and have a larger pre-populated database to carry out our tests, which earlier was a time consuming activity.

Could not reserve enough space for object heap

As we added two more test jobs to run in parallel, the jobs started failing with error “Could not reserve enough space for object heap“. So far I had faced this issue when I exceed the -Xmx<size> (set maximum Java heap size memory) limit for a 32 bit process. In this case it was a 64 bit process, we had 32 GBs of ram available and while the jobs were running I could see ample memory space still available on the box.

After spending couple of hours googling and observing the task manager while the jobs were running, I learnt something new. The task manager has a section called as “Committed Memory”

Task Manager

I observed that though the machine was showing lot of free memory available, I was getting the memory error whenever the committed memory was crossing the physical memory threshold of 32Gbs. You can see the actual memory consumed and the committed memory per process in the task manager.

Committed memory

Using the task manager, I found that all the java processes and some mysql processes were showing that most of them were consuming 2+ GBs of committed memory. After reducing the value of -Xmx, the committed memory on the java processes went down.

After reducing the size of mysql variable key_buffer_size, the committed memory for mysql processes went down.

Finally, after bringing down the committed memory size, all the jobs started running in parallel without any issue.

Now even after adding two more test jobs, our build pipeline time is down to 10 minutes.


Previous –  On a quest of reducing Jenkins build time – Part 1.


Gamifying Agile Adoption – An Experiment – Part 2

Gamifying Agile Adoption – An Experiment – Part 1

Gamification is now in place for over two and a half months at IDeaS and the data is looking better.

Iteration Burn Down

The game was introduced on the second day of Iteration 8. The iteration burn down data started looking better since then. Stories got planned well, they started getting accepted earlier in the iteration. Iteration 11 and 12 data is not looking as good because of holidays and 5th ShipIt day that was scheduled on 1st two days of iteration 12.

Iteration Burndown

Velocity Chart

Velocity Chart is also showing better data starting iteration 8. In-iteration story acceptance has increased. Due to holidays, the velocity data is not up to the mark for iteration 11 and 12.



Behavioral Changes

We saw some interesting behavioral changes

  • The team members started following processes well.
  • There was more interaction and collaboration between SD, QA, Product Owners and Product Managers.
  • The negative points started bothering the team members and they became a bit risk averse.
  • Some members started pushing product owners and product managers for early story acceptance to get additional bonus stars at the cost of quality.

Enhancements to the game

  • Now -ve stars do not impacts the total stars that are already credited. -ve stars give you Devil Badges.
  • Earlier “Badges” is now called as “Levels”.
  • Introduced “Badges” –
    • Badges give specific feedback on the contributions done in a specific area.
    • Different departments can have different badges.
      • Badges have three levels
        • Bronze
        • Silver
        • Gold
      • Different badges can have different star count to reach a level within the badge.
    • There are Angel and Devil badges.
      • The goal is to earn Angel badges.
      • Devil badges represents activities that one should not be performing.
    • new-badge-list
  • Leader Board now has a left panel that shows Badge Leader board.
    • new-leader-board
  • Self User Profile
    • Clicking on the user name on the right top corner brings the user on the User Profile page. The user profile page also two sections
      • Left Panel shows
        • User section
          • Total number of stars earned so far.
          • All the badges earned by the user. The color represents the badge level.
          • Appreciate someone by clicking on thumbs up icon.
          • Create new mission by clicking on the bulls eye icon.
        • Department Section
          • List all the users in the department in descending order of the number of stars received.
          • Appreciate the individual using the thumbs up icon.
      • Right Panel
        • Accordion shows all the badges that the user has received.
        • Progress bar shows the number of stars received for a given badge and the number of stars to achieve to reach to the next level of the badge.
        • Photos
          • The middle photo is of the self user.
          • The left hand side photo represents the user who is just ahead of the self user.
          • The right hand side photo represents the user who is just behind the self user.
    • new-user-profile
  • User Details
    • Click on any image on any screen and you would land up on the user details screen. The screen shows all the badges earned by the particular user.
    • Hover on the badge and you will see the reason why the user received stars for the concerned badge.
    • new-user-details

IDeaS Rock Stars is now opensource!!!

You can now download IDeaS Rock Star application war and use it in your organization. The source code and configuration help is available at Github.

Download Bots



Gamifying Agile Adoption – An Experiment

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 4th ShipIt Day, organized on 25th/26th 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 doingadopt agile practices, visualize sense of accountability, visualize sense of achievementdrive positive behavior, create healthy competitioncreate a culture of appreciationhelp 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.)

Leader Board

  • 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.)

My Screen

  • 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.

Appreciate Someone

  • 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.

Create New Mission

  • 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

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

“ShipIt Day” – First Anniversary @ IDeaS

In August 2013, I came across a video by Dan Pink titled “RSA Animate – Drive: The surprising truth about what motivates us”. During this video I came across 3M’s “15 percent time”, Google’s “20 percent time” and Atlassian’s ShipIt Days. From Dan’s talk, I could instantly connect and relate to the three motivators… Autonomy (Our desire to be self-directed), Mastery (Our urge to get better and better at something that matters) and Purpose (our yearning to do what we do in the service of something larger than ourselves).

I have been getting a lot of Autonomy in my day to day work and that’s one of the primary reason why, even after completing 13 years at IDeaS, I tremendously love what I do and my energy levels are very high. I would say I was lucky enough… Not every-one gets that! That’s why I was thoroughly impressed with Atlassian’s ShipIt Day concept. It provides employees the Autonomy that they crave for.

I had to convince my fellow colleagues and the executives on the value that ShipIt Day could bring. I was very lucky to get tremendous support from Sanjay Nagalia, Rajiv Nashikkar, Steve Finck, Prafulla Girgaonkar, Prasad Kunte, Linda Hatfield and many others without whom it was not possible to organize ShipIt@IDeaS.

The first ShipIt was held on 10th and 11th October 2013. Time flies… It has been one full year and so far we have had 4 ShipIt Days.

Give Autonomy to your employees and see what wonders they can do! You should witness the energy and enthusiasm with which they stay back whole night and pursue their own ideas! Hats off to the participants.

Below are some stats.

Total No Of ideas received 164
No of ideas presented 137
No of distinct participants 91
No of Winning ideas 28
No of ideas absorbed by teams 6
No of ideas absorbed in product 2



On a quest of reducing Jenkins CI build time

In my organization we are using Jenkins as our CI tool. The core build is followed by multiple jobs consisting of unit tests, integration tests, SAS integration tests, PMD, all running in parallel, running over 3000+ tests which took the entire build pipeline to run over 1 hour 30 minutes to produce the build artifacts. The amount of time taken was too high and it was very frustrating specially when the tests failed, as multiple developers would check in files while the earlier build was in progress, the next job would start and by the time issue was identified and fixed, it would take more than 4/5 hours to get a stable build. QA would not get build artifacts on time. Valuable development time was getting lost. There were frustrations all around.

This persistent issue pushed me on a quest to reduce the CI build time.

The problem with duplication

The discovery of Ant JUnit task options

The assumptions around IO and SSD

The alternative for SSD – in-memory/in-process db

The “eureka” moment – discovery of RAM Disk Drives

The excitement and the disappointment

Test on smaller data set

CPU profiling for rescue

Today Ajay moved our Jenkins VM to a box having hybrid disk and now the build pipeline time has reduced from 25 minutes to 15 minutes and all the test jobs run in less than 10 minutes!!! And I am feeling very happy and satisfied on my quest of reducing the build time. This journey took more than two months, during which I have learnt a lot.

 On a quest of reducing Jenkins build time – Part 2