In order to avoid Kanbut we have to ensure that the six rules of Kanban are implemented and followed by the team:
- Visualize. Visualizing the flow of work - making it visible - is integral to understanding how work proceeds.
- Limit work-in-process. Limiting WIP implies that a pull system has been implemented and will act as a stimulus for continuous changes to the system.
- Manage flow. The flow of work through each state should be monitored, measured and reported.
- Make policies explicit. Explicit policies and understanding enables a team to discuss issues more rationally, empirically, and objectively.
- Implement feedback loop. Team members collaborate to review the flow of work and demand versus capability measures, metrics and coupled indicators.
- Improve collaboratively. Kanban encourages incremental, continuous, and evolutionary changes that stick.
We applied six key Kanban practices to a real case we were working on with a project team for the program of a major investment bank. Completed in February 2013, the team is still using Kanban method as it was designed for them, demonstrating the successful adoption of the approach and its adoption by the development team.
The project team and its customers faced longstanding and familiar problems with the development process. While the total length of the release cycle was up to 3 months, the process was hindered by frequent changes to the scope. In business, waiting three months for urgent requests means creating undesirable delays. For smaller business requests the delivery team tried to take the scope into consideration, but each case was like a new story. Change request procedure was debilitating for both the team and the customer. Due to the monolithic design of the project team, each request disrupted work on the strategic solution, diverting the attention of key players. The development phase was planned upfront and usually without scheduled buffers for contingencies causing the project to run into overtime.
Because SL3 units of work require instant investigation and clear ownership, more difficulties were connected to SL3 support. Time to production is critical and requires dedication.
This is commonly the case when a project team is facing two major types of work: strategic and streamlined. When the streamline rate becomes predictable it makes sense to manage it using Kanban.
To be successful, the method should be implemented using a Kanban board in the workspace that lays out key elements and steps in the process. See the picture below.
These key elements include:
- Kanban phases: Vertical columns describing the particular stage of the development life-cycle, for instance 'Testing.’ Each phase consists of two columns, ‘In Progress’ and ‘Done.’ The first column contains the top 5-8 items in the request queue.
- Limit Work in Process: Another Kanban element, implementing Lean principle to eliminate wastes. ‘Work-in-Process’ is a waste in the Lean classification. We set up a WIP limit for each phase. The team should ensure that the number of tickets do not exceed limitation. Good Kanban is characterized by reducing the WIP limit over time.
- Explicit Rules: Explicit rules are designed and printed for individual phases. They indicate when a ticket can move fr om the ‘In Progress’ to ‘Done.’
- Other information: May include current ticket ownership, intended release, work type, blocked label, etc.
As in Scrum, the Kanban team will benefit fr om being cross-functional and self-organized. Kanban team members should ask themselves what it will take to reduce the inventory on a board and how to advance tickets as quickly as possible. Retrospectives, or utilizing the 12th principle of the Agile Manifesto, are never ending. The Kanban board should evolve over time.
In general the Kanban team should encompass all phases and consists of different specializations, fr om developers, testers, and business analysts to release engineers. In our case, the team also had a dedicated, full-time team coordinator. Each team member is responsible for moving the SL3 or CEP ticket through the phases, with their primary focus being the phase they specialize in. Each role can contribute to resolving issues arising in problematic phases as well as bottlenecks in the chain.
- The team owns the Kanban process and is responsible for delivering on customer requests
- The team also has a dedicated ‘Product Owner’ from the client side who manages and prioritizes the incoming queue.
- The team coordinator is responsible for the triage phase and sorting all incoming requests. As this project had a fairly complex triage workflow, it was clear that team needed a strong coordinator and facilitator for that process, leading to the role of the SL3\CEP Team Coordinator, who owned and managed the SL3 triage workflow. The coordinator monitors all incidents and requests raised and registered by end users, ensures that all incidents follow a specific path during the triage phase, and involving all necessary parties in a decision chain. The coordinator educates the SL3\CEP team to ensure that everyone understands the triage process when he or she is unavailable thereby transferring greater triage ownership to the team.
The Kanban method does not prescribe a specific daily algorithm for team collaboration. For our project, we established working agreements in line with the six core Kanban practices:
- On a daily basis team members synched their work and upd ated statuses.
- A ticket had to confirm the explicit definition of ‘Done’ for a phase before it could move into the next.
- A team member could not advance a ticket further if it was not located in the ‘Done’ sub-column of a phase.
- All team members controlled the process, holding regular retrospective meetings to change the definition of the ‘Done’ designation.
- A team member could not advance a ticket to the next phase if WIP lim it did not allow for it.
- Each ticket in process had a designated ‘owner’ for it depending on which phase it was in.
Make policies explicit
In the pictures, the pages at the top of the board contain a check-list of ‘to do’ items, essentially the definition of done. The ticket or work item could not migrate to another stage if any item in the check-list had not yet been completed. Clear-cut rules made the process reliable and predictable. The team should own the process and the definition of done. As you can see, some items are crossed out, some items were improved, and new items were added by hand. The check-list is a source of continuous improvement, and should update all the time. Such changes are a hallmark of good Kanban process.
Implement feedback loop
A couple of words about feedback loop: The quality of the feedback loop is based on the quality of inputs we provide for any kind of meeting or discussion. Metrics feed the objective picture and good decision-making. With this team, in addition to the physical board, we used JIRA, mainly to report needs. It was the main tool connecting the team to the outer world. JIRA contained all customer requests organized in queue, unlike the physical board, which contained only the top 5-8 items from the queue. With JIRA we were able to calculate such metrics as:
- Number of ‘not closed’ defects, reflecting process quality
- Number of items in progress, reflecting process effectiveness
- Average time from the time a work item was created, to start analysis, in days, showing customer expected team throughput
- Average time from analysis to done, in days, showing the team's actual throughput
- Time spent on different types of work (SL3 vs CEP), in hours, reflecting the complexity and quality of the product
A core benefit of the Kanban method is that it respects current processes, roles, responsibilities and titles, unlike other Agile methodologies. Due to the nature of software development it is not hard to apply the 6 Kanban practices to any process, but in order to master Kanban significant shifts in culture and mindse t have to be taken into consideration. Great Kanban still requires mastering Agile values and principles. Without them, Kanban won't raise you up to your full potential.