I find it a lot easier to share my thoughts through a real life example.
All of us have travelled by train sometime or the other. Let us visualize two rail stations A & B 100 kms away from each other. A train leaves station A exactly every two hours travelling at a speed of 50 Kms / Hr, reaching station B after exactly 2 hours. (Sounds like Tokyo subway?).
This is Scrum with 2 week sprints, start and end on predefined days, making sure that those who got in at station A reach station B on time. Very disciplined predictable and dependable for those who can book in advance, reach station A on or before time, and wait till the next scheduled train to arrive.
Life is not so simple.
How about those travelers living much before station A, or between station A and B? They have to make their own arrangements to reach station A.
How about those who want to get off after station B? They have to make their own arrangement to travel from station B to their destination.
How about those who want to get off between station A and B? They have to first wait till station B, feeling bad that they can’t get off as they pass their destination, and then make their own arrangement to travel back with resultant delay.
How about those who could only decide at the last moment and have a critical urgency to reach their destination on time? They obviously had no time to make an advance reservation.
Is there a solution?
How about a train that keeps going round and round, and people can dock-on and dock-off from their respective places? That’s Kanban.
Sounds chaotic? Yes it is. Anybody could just board at their own sweet will and inconvenience others who are already in. So we need some discipline; and some planning; and some visibility into the past present and the future. And an automated system for planning and sharing information to all concerned helps.
Such a system is Agile, or more specifically Holistic Agile, which to start with must clearly know for each person, or a group of persons, where they want to get off and when. That helps to start backward planning. The train’s capacity to carry the passengers is known. What is required is the available capacity for additional persons to get on board without inconvenience to anybody. For this we need a rule that no standing is allowed. A person can get in if and only if there is a vacant seat. Heard of WIP limit from Kanban? This will of course mean some empty seats from time to time. But a slack is always better than people stacking on top of each other. Those inside could move about interacting and helping others onboard.
For capacity planning we could consider stops every hour (or every 50 Kms away), and plan capacity for this duration. Something like virtual mini-sprints of a week each. Within these every 10 Kms or so away, the system needs to know number of vacant seats. Even better if information of seat availability in each compartment is being continuously monitored by the system. Such information would be greatly useful to those who are responsible to decide how many and which people should be allowed to get in.
For a start this is good enough. In subsequent posts we will try to apply this specifically software development supported by good agile tools.
Most people say they are doing Agile when they are actually doing Scrum. This is because Scrum is the most widely used agile method; with a good reason. Scrum provides a complete framework that includes roles, ceremonies and artifacts. Over last 20 odd years of its existence, it has matured and scaled to large projects.
However Scrum does not provide sufficient guidance to the teams about how to manage their work within a sprint. There is no guidance on when to start work on which story / task. It does not provide guidance on how to keep the work moving smoothly without interruptions.
It mainly focuses on capacity utilization and relies heavily on burn-down chart to anticipate the risk of spill-overs. But there are cases where in spite of available capacity there is just not enough time for quality work before the due date. Hence there is a need to look beyond Scrum for help on these challenges.
Scrum is not the only agile method. There are others like Kanban and Lean. Kanban came from manufacturing, especially Japanese auto industry, and was pioneered in software development 10 years back.
Kanban is a light-weight method and is commonly used where the 2-3 week batch mode of Scrum doesn’t fit very well. Such situations include support activities, projects in maintenance mode, or anywhere the requirements come in at random and with a short completion time.
So a common approach is to choose between either Scrum or Kanban, but not both together. However there is an area of Scrum, single iteration or sprint, within which the Kanban principles can be considered for improving the execution effectiveness.
Expected benefits of introducing Kanban within a sprint are,
• Improved Agility –Measured as turn-around time (Elapsed time from the start to finish)
• Higher Productivity – Average velocity per person per week
• Better Quality – Reduced defects and rework
Kanban relies on pull mechanism to decide when to start an activity, and has just three simple principles.
• Limit the work in progress – Complete the work-in-hand before taking up the next task.
• Observe and manage the queues – Long queues introduce an inherent delay to every item. Lengthening queues indicate a capacity imbalance.
• Identify and remove the bottlenecks – Worst bottleneck decides the system throughput. Removing it reveals the next worst.
How Kanban principles help each improvement area:
Limit WIP: Pull system allows JIT re-prioritization (Agility). Uninterrupted attention reduces setup time (Productivity). Focused attention helps do a thorough job reducing defects and rework (Quality).
Manage Queues: Short queue reduces waiting time for all items in the queue (Agility). Reduced waiting time minimizes spill-overs (Productivity). Reduced waiting time provides more testing time before the due date (Quality).
Resolve bottlenecks: Removing bottlenecks Improves flow throughout the system (Agility). Improved flow results in higher capacity utilization (Productivity). Absence of a bottleneck means no need to compete for getting beyond it in hurry (Quality).
For best results it helps to follow a step-by-step implementation. The suggested steps are,
Set up the board to clearly visualize the work:
By default a board normally contains just three states – To Do / In Progress / Done. But the total span of a team’s work typically contains multiple stages. Visualizing them on a board as different columns helps to clearly see the flow. Further breaking the stages in pairs of doing & waiting clearly separates WIP and Queues.
Put in place data discipline:
The team will take some time to ensure that the data in the tool is in sync the with ground reality. But it is important to achieve this discipline to get reliable data for measurement and analysis.
Modify board design to facilitate measurements:
Initial measurements on live data will reveal areas of high variability. The board design would be modified through setting up swim lanes and filters to reduce this variability.
Baseline the current agility / productivity / quality:
Before we can measure the improvements, the current level needs to be captured.
Agility would be measured as the elapsed time between given points in the flow. Agile tools like JIRA provide powerful reports for cycle times and cumulative flow.
When doing Scrum, the productivity and quality measures would be in place to baseline the current levels.
Keep measuring and improving:
After the successful completion of first 4 phases, the teams can start reaping the benefits. Areas of improvement and the extent of benefits achieved will vary from project to project. There is no out of the box solution; but there are available pointers to indicate possible areas of improvement. Continuous improvement needs to become an iterative activity, with a short feedback loop.
Scrum is the most widely used and powerful framework. Its power can be further enhanced by understanding and applying a few Kanban principles. The best place to start is within each sprint.