At eimagine, we manage engagements at various points in the software development lifecycle – from initial software release to production support. From a development perspective, we leverage Scrum to manage the work that our team does.
As with most development teams that utilize Scrum, we engage in daily standups, iterative development, tracking of burn down and heavy customer involvement throughout the development process. While Agile is fairly uncomplicated when applied to software development projects, specifically Scrum in the case of eimagine, its application is not as straightforward from a production support perspective. This is especially true for companies early in their quest to become Agile as translating the ceremonies of traditional Agile tools can be daunting.
So what is a development team charged with application support to do? For production support, we have found that there are a few key principles and practices that make all the difference. These include:
1. Identify a Bug Fix Team
Charging your entire development team with addressing production issues can slow (or completely stop) progress on new projects. Identify a specific group of individuals that will address these issues. This will make it easier for the team to see trending issues, commonalities among issues, and identify specific users that are submitting tickets most often. As a result, additional training, upgrades or infrastructure improvements are recognized more quickly.
2. Estimate Bug Fixes Prior to Completing Work
Estimating bug fixes prior to completing the fix is similar to estimation activities that take place on waterfall projects. Tasks are estimated upfront based upon the “area” of the application, the developer’s knowledge of the technology and/or code, and the time it takes to complete similar tasks. This is not an exact science, and research has shown how utterly terrible we are as a species (human for those playing at home) at estimating the time it takes to complete work. For bug fixes in particular, it may be easier to judge the relative size of the task rather than a specific timeframe, which is why “t-shirt sizing” bug fixes work so well. Estimating something as “small”, “medium” or “large” provides a good starting point for estimating the time involved in fixing a bug with a large amount of variability. A bug associated with the display of content or CSS might be a “small” size while something related to the way that data is being populated may be “large”.
3. Establish Gates
Consider instituting “gates” regarding the amount of time that is to be spent on a single bug fix. If for example a 2 hour gate is established on “small” bug fixes, once the developer spends 2 hours on a bug fix estimated as “small”, he or she should regroup with the team. There could be many factors contributing to additional time needed to fix a bug including a poor understanding of the root cause, an erroneously reported bug on the part of the end user, unfamiliarity with a particular code base or application, or even gold plating. Using gates as a check in point ensures that potential road bumps or blockers are reported to the team sooner, and next steps can be promptly identified.
4. Limit Work In Progress
Limit the number of bugs that can be concurrently worked by one developer to ensure that developers are completing a task before moving to the next. If work in progress or WIP is not limited, a developer could conceivably work on bug fixes all week, month or year without fixing a single issue or bringing blocking issues to the team’s attention.
5. Make It Fun! (or as fun as it can be)
Recognize that production support is not always the favored task of developers. Most people get into development because they want to work on new software, not support existing systems. If you leverage a bug fix team, consider rotating team members on a bi-weekly or monthly basis so that not any one developer becomes bogged down with support. As with any development team, remember to celebrate accomplishments, it’s important to give credit where credit is due.