How 'Kanban' can help in Agile development?
One of the reasons for many agile projects to not achieve their release targets could be that the team signs up too many work items without moving each of the items into 'Done' state. This could be because of 'waiting for dependency with other work items', pending with the testing team, environmental issues or build break issues. During the last weeks of the sprint there is always a rush to claim maximum story points committed for the sprint and hence the team hastily starts other work items although the other work items are still pending. For ex: The developers have completed coding for the user story and it is pending for testing and the testing team is unable to test the user story due to some environment issue. But the developers, as discussed earlier, in order to claim maximum story points continue to sign up newer user stories. In the end the team might achieve target velocity for the sprint but there is no potentially shippable product. So velocity often may not be sufficient to track the success of a sprint and hence we need other metrics to track to achieve sprint goal.
Teams can overcome this kind of scenario through Kanban. Kanban enforces continuous improvement and lean practice through metrics like WIP, Cycle time and Throughput which are transparent and actionable. Transparency here is the visibility into the team's progress. Let's see the definitions of the above metrics relevant to agile methodology.
WIP (Work in progress): It includes all the tasks which are in between the 'To Do' and 'Done' status on the sprint task board.
Cycle time: It is the total time elapsed for the task to reach from the status 'To Do' on sprint task board to 'Done' status.
Throughput: Throughput is the number of 'Done' work items per unit of time (like day, week or iteration)
These three metrics are related through 'Little's law' which states that:
Average cycle time = Average work in progress/ Throughput
Thus change in any of these parameters results in a change of the other. So if we want to decrease the cycle time of the tasks then we need to decrease the WIP. Hence to bring a positive change we need not undertake a complex transformation but simply control the number of things that are being worked on at any point of time. For ex: In the above example when there is an environment issue at the testing team end, instead of signing up for newer user stories the developers should help the testing team to resolve the issue and probably even test the user story by themselves to bring back the testing team to get rid of the backlog which piled up due to the issue. This is the whole idea of Agile which is about team spirit and self-organizing, cross functional team with team members able to switch roles when the situation demands to achieve team goals instead of the typical handoffs and blame game that happens in traditional development models..