When maintaining and developing a large software system, the many change requests and service requests coming from the support (including bugs and incidents) are usually solved as soon as possible by the production team. The requests that comes from the sales and R&D and contain new customer needs (as opposed to let’s say: bugs) must be examined and passed to the development team.
Why Lean Change Request Management?
For our system, dozens of requests are raised every day, so we have a proper change request management in place. As the change management team gets overloaded, we asked ourselves how to apply Kanban and Lean techniques (in particular limiting and measuring the work in progress) to balance speed and quality.
How to do it?
We are experimenting with the following set of principles:
- Maintain a prioritized entry queue: The change requests are first roughly estimated and placed in a request queue until the Change Management Team pulls them. The queue is roughly prioritized by value and urgency. There is no limit to the work in progress (WIP) here, since this is the initial request queue. Emergency requests are directly handled in a dedicated flow.
- Limit the amount of Requests in progress: The prioritized requests are pulled from the queue by the change request management team according to the team’s capacity or work in progress limit (WIP). Change Requests and User Stories are analyzed. Requests that are sufficiently understood are pulled by the development team. This makes capacity free for new Change Requests.
- Avoid early commitment on the deadline: We stop to call the changes a “2 days change” or “10 days change” from the start. Estimation is done with the collaboration of development team once a common understanding is reached.
- We add a different flow for requests with fixed deadlines and for emergency requests.
- Formulate the business value to make them understandable and valuable. For example:
Increase / Protect / Promote <something of value>
Decrease <something reducing the value>
Don’t forget to estimate the effort, the impact and list the risks.
- Add examples whenever useful to make them understandable and serve as acceptance test, such as:
Then <resulting action>
As we will gain more experience, we surely will have to adapt. So far, it sounds logical to apply some lean techniques here, since there is some effort to be done for each single request and we can’t control the amount of requests we get. With some lean and agile techniques, we can process all requests in sufficient detail depending on their priority, find the highest sustainable speed and enjoy our weekends.
Trackback from your site.