I often hear: “How I can use Agile on support teams who do defects and small enhancements on multiple platforms?” Support, “business and usual,” defects, and enhancements are ideal for an Agile team. Think about it for a minute: the changes are usually small and independent, they are doable in a short time, and can often be deployed without major architectural or data related changes. This article describes how Scrum was modified to improve a support team’s process.
In the fall of 2005, a production support team of developers, testers, and analysts was setup to support 5 different production systems. The team was responsible for completing customer support requests for defect fixes and small enhancements. Major enhancements were handled by the platform teams. There were 5 different customers that made requests for each system. The team was setup to use Scrum, with Amy Ripley, CSM as Agile Coach and a single Product Owner. The Product Owner worked with the customers to define a single product backlog with priorities for all requests across the 5 systems. While each customer had different needs, many of the systems had interactions, so priorities were easier to determine than if all were disparate systems.
The team was co-located in an Agile team room and started out using standard Scrum with a 3 week iteration length. As the team and the Coach worked together, they realized that Scrum did not account for some of the unique properties of an enhancement and defect support team such as:
- Customers want quick turn around on fixing defects found in production
- Defect and enhancement implementation is small piece work compared to building new application features
- Requests for changes are independent of each other
Managing 5 customer’s expectations lead to pressure for more frequent updates to production. The Coach and the team saw this as a valid concern, and decided to make changes to their Scrum process that would better suit the small piece work and customer needs for faster turn around. The changes included:
- Weekly releases to production. Given the production support nature of the team they changed their release pattern from once per 3 week iteration to weekly releases.
- Allowing work to cross iteration boundaries. Some requests would be started later in the iteration but could not be completed by the iteration’s end. Given the weekly releases, this was acceptable, since the customer would not have to wait for a whole iteration to see the item in production.
- The regular story board was not providing enough clarity as to what was in progress and its state. A more structured Kanban style board would allow the team and stakeholders to more accurately track progress of work items. A Story board was implemented to show the status of a User Story that was in progress. The story would move with its task cards through analysis, dev, test, and release columns on the board. Each the 5 systems had rows for their stories.
- A team agreement was made to take each work item from beginning to completion before starting a new work item. As could be expected in a large organization, issues frequently came up that would stop progress a work item. When progress was stopped by obstacles outside of the team’s control, then a team member could start on a new work item. These obstacles were escalated to the Coach, the Product Owner and management for resolution.
This kanban style User Story board really helped the Scrum team, Product Owner and stakeholders understand the state of work at any time. The kanban style User Story board also helped reduce work in progress, since once a story was started, team members would not start on another story until it was completed.
The team continued to use the Scrum practices of self organization, the 4 meetings and a 3 week iteration length. The team and stakeholders valued the planning, it helped set expectations for everyone as to what could be completed in the near term. The demo meeting allowed the 5 Customers gain visibility into all the work done by the team. This “see the whole” is a key principle in Lean and with this team it provided a key benefit to maintaining stakeholder equilibrium, as all of these systems served the same department and overall business function. The Scrum principle of self organizing teams was also maintained, as they achieve higher performance and have higher morale than directed teams. Self organization also frees leadership to innovate and create more effective work environments.
Congratulations to Agile Coach Amy Ripley and team for inventing this Kanban style board and process for their Scrum.
“Two strong personalities and too much debate. Need is the mother of invention”
– James Grenning on inventing Planning Poker