Making the judgemental calls becomes one of the many important things you need to do as a management executive, seriously you cannot run away from them! There had been various instances in the past during project execution when I had to make certain decisions which were difficult to prove right or wrong at that very moment by substantiating them with the facts, but they came out to be right only when we looked at them backwards after certain time. I would like to pen down one of those judgemental call which I had taken during one of the project delivery.
Well, we all are aware of managing new requirements and requirement changes in the industry. Many a times, sales and product management team come back with a feature at a very later stage during the product development cycle and accommodating the feature in the platform/system becomes really challenging for development teams. In one of the similar incident, just few days before the delivery timeline, we got a request from the product management team to incorporate a missing user experience feature in the upcoming final release of the device to market. Honestly, it was on a short notice!
As the team had some bandwidth available (ambitious I), and the missing feature felt like an important user experience, we decided to start implementing the feature initially, but at the final stages I had to take judgement call not to merge that feature to the main line because of the possible impacts it can have on the other features which were already working and gone through the final testing cycles.
Challenges were many, my team which used to work on the application framework part of the device platform, was recently moved to a new vertical as part of organizational restructuring. As we started owning that part of the code recently, we were aware of the general architecture of the device platform (from our previous projects), but we were not completely aware of all possible intricacies in the new project which was similar to previous ones, but not the same.
Only after the development process was completed by the team, and we reviewed final code, we realized that the required feature was affecting too many critical areas of device platform which were used by various other applications as well. Even though development and testing team had done a round of testing on the newly written code, and it seemed to be working well, I was not completely convinced if sufficient amount of testing had been performed on the newly added code in given amount of time. To be doubly sure, we perused the code closely again, and realized that the areas of the platform where changes have been made is actually getting used by various other critical applications and services, and if we merge this code in the mainline, there is a good chance that we might be impacting other features which are not possible to go through complete regression test at this point of time.
Before we could merge the newly added code to the mainline, I thought over it for couple of hours, and revisited the advantages and disadvantages of adding a new user experiences on a short notice vs effecting critical features like call, messaging, emergency dialling, email etc. Once I was clear about the advantages and disadvantages, I tried to look at various factors which are going to affect my decision like the amount of experience developers have with the core area of code they have changed to add this feature, number of lines of code which has been added, number of important files which have been changed, amount of testing we have been able to perform after making the changes, weighing the real world importance of user experience vs impacting an critical feature, impact of bug on the business vs the advantage (a bug might be visible to several users, but a small user experience feature may or may not be used by many users during initial days of device launch – and also this feature was not present in previously available devices in the market), my previous experiences with a major code change and the amount of testing it requires, alternatives which are available with us like pushing this feature back to the device as part of the maintenance release rather than doing it right away.
Once I had the above data points in mind, I arranged for a meeting with other leads to do the brainstorming based on my above points and evaluate the alternatives before I can go and propose the same to higher management. Based on the brainstorming and above data points we decided to propose for the alternative and go with a maintenance release rather than merging the code to the mainline right away, as it will give us sufficient time to test the impact of the new added feature across platform.
Here we go, we made the internal team decision, although it was a big task to explain the higher management not to go with the newly added feature, I was able to convince them with the facts that we have already done the changes so we are not running away from the work and also explaining all the risks which are involved in pushing changes in such a critical area of the platform and its impacts, along with proposing the alternate option which can be used to push this feature back to the device in a nearby time frame.
As we did not have any quantitative facts to justify the decision of not putting the code in the mainline, it was a tough call to take at that moment. Although we did realize later that it was a right call for us at only when we faced with couple of important issues in other features during the complete device regression cycle few weeks down the line.
Trust me, it wasn’t easy. My wrong call would have affected organization’s business, and my team’s performance both. And yes, I do believe - where your mind goes, your energy flows! And it does give you a way to analyse the problem at hand at a bigger scale. It’s perfectly fine to live with the idea of ‘nothing is impossible’ but when you are working with a team you should know the elasticity, the extent through which a team can be pushed. To commit and to deliver - can’t work on assumptions. For a team leader/manager, these are the real testing times. Your experience teaches you to take the judgement and your ability to take these crucial calls strengthens the trust which your team mates have in you.
No comments:
Post a Comment