Curious case of a change request - Will it ever finish?
"My momma always said, life is like a box of chocolates. You never know what you're gonna get." A very famous line from the movie "Forrest Gump", and I couldn't find a better metaphor than this to describe software maintenance. Software maintenance is like a box of chocolates, you never know what you are going to get at any moment.
If I may, I would like to dwell a bit on what makes maintenance like a box of chocolates. Software maintenance has internal variability and external variability factors which make the execution uniquely challenging. For example: Internal variability factors such as flow of the work items is irregular or class of service mix is diversified (work item size ranges from 100 person days enhancement to 30 min effort simple user query). External variability factors such as requirements are never frozen, and they keep evolving or the priorities change overnight.
In spite of all the complexities, maintenance teams with their shining armor of platforms, tools and frameworks are very much capable of delivering work in a reasonable timeframe. One would assume that the lead time to deliver a change request is within reasonable time and meets user expectations. But the reality is far from our assumption and most certainly far from user expectation.
A typical maintenance request of 5 person days effort, on an average takes more than 150 days to get in to production. This is based on numerous studies, and I am sure you will find the same if start measuring the lead times in your engagements. Before you scream out loud saying "150 days? That's unbelievable", let me quickly walk you through the life cycle stages to justify this number.
Once the change request is raised by a user, he/she expects it to come back in two or three weeks or at the most 8 weeks, it sets sail on a long uncharted journey. It first sits in a queue waiting for impact analysis & estimation to be done, it goes through a prioritization process which typically happens once in a month, and then it sits in a queue waiting for the build. If lucky, it is build time, but it might get dropped or deferred depending on the other priorities of the team. After completion of the build, it has to wait some more to go through functional testing, system testing, user acceptance testing, and let's pray for the immediate availability of the environments and testing team's bandwidth. There is a possibility of a change in the requirement or defect leading to rework, thus the cycle repeats all over again. Finally, after packaging and deployment, the final stop is to wait for the next deployment window in to the production environment. You do know how rare these deployment windows are, don't you? It might take weeks before we get a deployment window to move the changes in to production. After all this pain...Ta da! It gets delivered to the user.
Now I guess you could see 5 months as a genuine possibility for the request to circle back to the user. This is in spite of having the best in class tools, people and processes. By the way, we did meet all our SLAs, schedule, effort estimates & other service management and engineering metrics. How ironic? I am not going to make any guesses regarding the satisfaction levels of the user community.
In my next blog, we will get to the crux of this problem & see how Scrumban can help overcome these challenges.