What is your experience dealing with product maintenance while managing development in a Sprint? This article was posted on the Scrum Alliance website.
https://www.scrumalliance.org/community/articles/2012/may/applying-...
05/21/2012 by Albert Arul Prakash Rajendran
Note: This article is based on a Scrum Alliance Google groups thread called "How to apply scrum in a mixed feature development and SLA-bou[n]d bug fixing team." I have compiled most of the solutions that were provided in the thread. Not all parts of the article are my contributions.
In most software development organizations today, there is no dedicated sustaining engineering (SE) team to take care of post-release maintenance and support. The engineering (R&D) team doubles up to complete SE tasks in addition to feature development. However, support service-level agreements (SLAs) with maintenance-paying customers are usually rigid, so SE often takes higher priority than R&D. Engineering teams that follow Scrum then fail to deliver committed features due to the high influx of SE issues and the need for their speedy resolution. Juggling between feature development and bug fixes also adversely affects team morale and motivation levels.
The following Scrum-based options were suggested by group members to overcome the problem in such situations.
Dedicating members for SE in every sprint
Using this option, one or two team members per sprint are dedicated to SE issues in a round-robin fashion. This eliminates the need to juggle tasks, and the team retains its morale and motivation. As all team members take turns working on SE tasks, they get insights into code quality, recurring development issues, and the cost/effort to fix issues post-release. Over time, this can result in a natural improvement in code quality.
Furthermore, since the capacity of only the remaining members is considered for feature development, this method ensures that sprint commitments are largely met. In case of low SE influx, the SE-dedicated members can fix other internal bugs and thus raise the overall product quality.
Kanban
The team prioritizes all SE tasks and takes them up in order of priority. Using Kanban minimizes the work-in-progress items, because each member is allowed to work on only one task at a time. This model does pose certain challenges with respect to accurately forecasting the product release cycle, but it also significantly improves product quality.
Shorter sprint
The sprint duration is reduced to one week, and bugs are prioritized each week. The success of this approach depends on SLA expectations.
Divide and conquer
The team velocity is distributed evenly between R&D and SE. The team works with two simultaneous product backlogs, one for feature development and the other for SE tasks or tickets.
SE tickets, along with their SLA goals, are brought into the Scrum ceremonies in a similar manner as development stories. For example, there may be a story to improve response times to meet SLA. During sprint reviews, the team studies ticket metrics to determine if SLAs were achieved. The team has ITIL (information technology infrastructure library) built in as part of its definition of done and as part of its Scrum board. A scheduled task is created as a reusable story and goes through the Scrum process.
There needs to be some flexibility here to change goals during the sprint if required, in case there's a major incident mid-sprint. But if capacity is well allocated between plan-driven work and incident-driven work, reprioritization is rare.
Single-day sprint
This is a new approach to resolve the problem when SLAs are extremely stringent and none of the other approaches are viable. A single-day sprint is one that starts in the morning and ends that evening and includes all the standard components, such as sprint planning, velocity calculation, and review. However, the sprint retrospective may take a backseat or may be done on an on-demand basis.
The single-day sprint model looks like this:
This way the complete turnaround for a ticket is one day and the team is inside the framework.
Hardening sprint
If the team continues to be overburdened with a high influx of SE issues, it's time to talk to management about the possibility of running a couple of hardening sprints to fix existing issues. If run properly, improved product quality will result in a significant potential cost saving. A hardening project focuses exclusively on fixing issues. No new features are developed. This reduces the number of issues and the team gets some breathing space.
Conclusion
In addition to all the approaches listed above, investing in the following areas will lead to better results over time:
Group discussion brought up all these possible solutions, and there are likely other innovative ideas out there. If your team found some, let's hear about them. Meanwhile, all the best!
Comment
John, thank you for the response. I'll mark my calendar for April 27th.
SLA Service Level Agreements did come up at the last AgilePhilly meeting on "Fixed Price Agile Contracts" by Mike Harris. And see Mike Harris at the AgilePhilly Springtime Conference downtown on Friday April 27th.
At AgilePhilly, we have been Promoting Agile Ideas since 1776
AgilePhilly is a not-for-profit user group of volunteers in the Philadelphia area dedicated to better software development practices.
Meetings are monthly. Get meeting reminders by joining here.
Our attempt with the group is to provide an environment where you can exchange ideas and meet with individuals involved in agile community.
© 2024 Created by Ravindar Gujral. Powered by
You need to be a member of Agile Philly to add comments!
Join Agile Philly