Posts Tagged ‘Kanban’

Kanban Lean techniques applied to change requests management

Written by Blaise Rey-Mermet on . Posted in Agile Configuration Management

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.

Kanban board for Change Request Management

Kanban board for Change Request Management


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:
    Given <precondition>
    When <action>
    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.

Mixing requirements techniques and wrapping them with Kanban.

Written by Blaise Rey-Mermet on . Posted in Agile Requirements Management, Lean & Agile Product Development

cooking session with light - blend
With motivated colleagues, we are helping other development teams in one large IT organization to improve business analysis and project management. As we meet the diverse teams (from business analysis up to the implementation and production teams) we find various methods of development such as the Unified Process or the V-Model. These proceses have been defined as standard by the management and partly established. Despite that most team are struggling under a long list of high priority requirements and changes, some benefits of the deployed process are visible. It is therefore not an option to replace the established processes with a new agile process.

Instead of replacing your development processe, improve it with Kanban.

This matches the situations described by David Anderson [1]. By establishing a Pull System to limit the work-in-progress and balance the demand against the capacity of the team. The first effect will be to visualize inefficiencies; we can then improve the processes accordingly.

There is logically no predefined way to tailor the existing process with Kanban, since it will depend on where your teams needs an improvement, but in general it makes it easier to

  1. keep the process in place for the overall control of the project, and manage the work load with a pull system,
  2. then use a simpler process for the daily work, Scrum if you like, and also control its flow with Kanban.

At the project / product level, keep the established process as appropriated, to control the flow and add Kanban as pull system.

At the team level use Kanban to drive the work.

You will need to adapt the requirements at all levels (user requirements, product requirements). A possible solution is to apply User Stories and Tasks at the team level and group them into large Use Cases at the project level to understand overall product. Read more on blending Kanban and other processes: Mike Cottmeyer [2]

Key points:

  • You may not need to throw away the established processes – improve them with Kanban
  • Instead of replacing Use Cases with User Stories – apply them at different levels
  • Kanban enables improvements with minimal resistance.
  • Big-bang changes do not work – Kanban enables continuous improvements.

Feel free to comment or discuss your experience about tailoring Kanban and other development processes.

[1] David Anderson – Kanban, Successful Evolutionary Change for Your Technology Business
[2] Mike Cottmeyer – Blending Scrum and Kanban to Create an End-to-End Agile Enterprise,