Karma and Product Feature Shelving

Author : Hari Madhavan

A few days ago , I had a pleasant surprise . A mail from a customer which went thus

You might be aware that we recently had a client rollout where one of critical module was developed by Promantia. Though this requirement came in at the last minute to the Promantia team , they were able to leverage the old implementation – convert to serverless module and with minor enhancements were able to release a very stable solution. This is now live for multiple days and found to be very reliable and predictable.

This exhibited the good design , implementation and testing quality work done by the previous Promantia members who initially developed it . What makes it even more commendable is that they completed the testing under multiple constraints and laid the foundation for a very smooth integration testing .Appreciate the due diligence on quality exhibited by both Promantia Dev and QA persons.

If any of those members are still in Promantia , please pass on this feedback .It was a job well done by both dev & QA members !! 

This was in regards to a functionality developed for a product that we managed. The feature was shelved about 4 years ago but was again picked up last month and the customer was really happy that the shelved work could be used with minimum hassle … The team member has since left the team, so let me acknowledge Rajan, Sneha and Pallavi – well done – for a clean closure of the feature.

It got me thinking of two things

• Good Karma does bring its rewards:  I’m  interpreting Karma as doing the right thing because it is right and not because of consequences. We do occasionally develop features which are stopped before they are shipped. Normally a short time is given to the team to mothball the feature after a decision is made to shelve it, and this can sometimes lead to poor workmanship on this feature, as it would not be acceptance tested or delivered to production in the near future. The big difference in quality comes when  the team feels they “own” the product as they would be motivated to preserve the partial feature in a clean way. Making this a habit helps in the long run – since while many of these may not be resumed, a few would be and a few others may provide inputs for other feature development .
• What should we update when we pause a feature? Our normal list is 
  • the artifacts in the repository ( code , tests , scripts etc ) , 
  • the stories in the tracking tool ( indicating what is completed, and if some features are not completed their statuses )
  •  known issues / bugs which are open, fixed but not tested etc 
  • documentation as per project standard ( on Wiki or in document )
  • In this specific case, stubs and mock implementations as well as vendor API documentation and samples were key – as this was an integration project. 
• These updates help to resume the stories from that point a few months afterwards. But when the shelving is for the longer period , the work would be picked up by new developers and even new teams, who would lose some of the contextual information. We brainstormed internally and came up with an additional list  which would make it easier to resume the feature development 
  • Any concerns around the code, technologies, libraries and any action that was taken to assuage those concerns
  • Any smells/refactoring opportunities that can be addressed if the work is resumed

I would love to hear other views on what else could be done to make it even easier to resume the shelved work