Kanban as a Nice Add-on to Scrum
our methods are mainly using scrum methodologies but we added some Kanban twists to it.
Kanban primarily follows four core principles (info from link)
Visualize work
- Create a visual model of work and work flow, so as to observe the flow of work moving through the Kanban system. Making the work visible, along with blockers, bottlenecks, and queues, instantly leads to increased communication and collaboration.
Limit work in process
- Limit how much unfinished work is in process and reduce the time it takes an item to travel through the Kanban system. Problems caused by task switching and the need to constantly reprioritize items can be reduced by limiting WIP.
Focus on flow
- By using work in process (WIP) limits and developing team-driven policies, the Kanban system can be optimized to improve the smooth flow of work, collect metrics to analyze flow, and even get leading indicators of future problems by analyzing the flow of work.
Continuously improve
- Once the Kanban system is in place, it becomes the cornerstone for a culture of continuous improvement. Teams measure their effectiveness by tracking flow, quality, throughput, lead times, and more. Experiments and analysis can change the system to improve the team's effectiveness.
We need features from both
| Advantages of Scrum | Advantages of Kanban |
|---|---|
| Transparency | Flexibility |
| Improved credibility with clients | Focus on continuous delivery |
| High product quality | Increased productivity and quality |
| Product stability | Increased efficiency |
| Team members reach sustainable pace | Team members have ability to focus |
| Allows client to change priorities and requirements quickly | Reduction of wasted work/wasted time |
Why can Kanban help as add-on
Kanban: A Good Fit for Teams that View Work as Firefighting.
Toyota production plants and Scrum teams exist to build product. The literature speaks of successful application of Kanban in the service industry, analogous to firefighting or hospital emergency rooms. It's tricky to schedule your next fire unless you live in the world of Fahrenheit 451.
Many development teams run in firefighting mode, often with "swooping" from the Product Owner during a Sprint. And getting into a discipline is hard: it's easy to want to be able to react immediately to customer change instead of integrating a request into the business plan, and it feels good to release whenever you see fit. (link)