Scrum is the common way for our Global Delivery Center (GDC) to run our development style projects. This has worked very well through the past couple years. While project types are expending in the GDC, problems are found. Take this discussion for example:
Sam: How is Scrum fitting into your project?
Eddy: Well, my team is working on a ticket-driven project rather than a common development project.
Sam: Yes, and then?
Eddy: I can’t have a fixed scope for a 2-4 weeks sprint since the work on our plate keeps changing.
Sam: Did you think about reducing the fixed-time for the sprint? Can you have a fixed scope for a week?
Eddy: Not really, actually we are receiving requests from the client almost everyday, so the priorities are always being adjusted.
Sam: Do the requests coming from the client usually take less than a day to fix?
Eddy: No, usually those take a couple days.
Sam: Then a one-day sprint can’t fit into that either. Well, did you ever think about throwing away the sprints?
Eddy: But then it is not Scrum anymore.
Sam: Scrum is only a tool for the project to use, but we are not going to force the implementation of Scrum.
Eddy: Then how can we do it?
Sam: Kanban might help you.
Eddy: But I like the rest of the Scrum practice.
Sam: Definitely, you can have those together with Kanban.
From my personal perspective, Kanban is suitable for ticket-driven projects (maintenance projects). Kanban does not require a fixed time-frame and fixed scope. It only cares about all the states of work in the workflow, and the WIP (Work In Progress) designed for each state.
In a very easy to understand example, you can identify the states in the workflow as “Pipeline”, “In Progress”, and “Done”. Sound familiar? Right, it’s very similar to the Scrum board of the sprint – “Backlog”, “In Progress”, and “Completed”. The difference is that in Scrum, you will have a relatively fixed backlog, and you have a fixed time frame to finish everything in the backlog while Kanban does not. Kanban will only define the WIP for one/some/all states. See the following pictures:
Kanban does not have a fixed scope and a fixed time frame, so burndown might not be suitable, CFD (Cumulative Flow Digram) is. See the example:
Measurements:
- Team Efficiency – Average Lead Time: The average time cost from a task being put into the “Pipeline” to “Done”
- Team Capacity – Average Total WIP: The average task number with the state not being “Done”
See Lead Time and Total WIP example:
How to define the WIP?
The number will keep changing when the team experiences the project. An initial value for the “In Progress” state could be 2 * team size – 1
Currently we have a couple projects we are piloting with Kanban. We are looking forward to seeing the results from those.
By the way, Kanban can also work together with Scrum.
This is very educational for me. With this we can monitor ticket driven projects clearly. Thanks!
I have two questions here:
1. Why we need to set the WIP limit for pipeline?
2. Is it OK we do not set the WIP limit for “In Progress”, and keep monitoring the velocity and capacity using this model, and make it public to team?
The response to your questions:
1. The WIP set for the pipeline will enable the team to keep a healthy workload. Since from the client point of view, once they throw the tasks to the team, they already starts the counting of the time you take to get those done. So the time that the tasks are pending in the pipeline will be also consider as part of the time you spend on finishing those. For maintenance projects, that time will impact the SLA.
While, setting the WIP for pipeline or not really depends on the project reality.
2. It is OK for not setting the WIP for “In Progress” while most cases the WIP should be there, it depends on the project reality. After the team experience the project for a while, there will be a WIP no matter it is formally announced or not. To set the WIP will help you to control the workload for the team.
Overall, Kanban is very flexible, all depends on the project.
Pingback: Getting useful information out from the CFD - Multi Shoring - A Perficient Blog
Pingback: Manage requirement changes inside a Sprint | Multi Shoring