SCRUM vs Kanban
This video by Development Pays was a perfect introduction for me of the differences and similarities in both the Scrum and Kanban frameworks and how each might be used effectively within various companies.
Kanban Overview and Resources
Taiichi Ohno, is credited with the development of kanban to improve manufacturing efficiency as part of the Toyota Production System, which subsequently led to the development of Lean Production in the US.
Kanban is structured to promote and reduce any resistance to change within your business. Agile encourages you to embrace change – change is a good thing and we want people to be empowered to speak up at all levels within the organisation. Many organisations though are still quite reticent to receive feedback and requests for change from their customers and not see it as a positive statement.
Scrum also encourages change and uses the Sprint Retrospective as a group review of how thing went and what improvements to the process could be made to improve delivery in the future.
Kanban, on the other hand, allows you to stop the process immediately an issue is found and recommend improvements, which I think is a better option in many ways as you get to discuss issues, while they are fresh in your short-term memory. On the other hand, the Sprint Retrospective, like any meeting, can become a ceremony for the loudest voices to grandstand and some team members will zone out of these discussions and only the larger issues stored in longer-term memory will be recalled for review.
When you see people struggling to write anything on their Mad, Glad, Sad (or Start, Stop, Continue) post-it notes, during a retrospective, you know those opportunities for improvement have been lost.
- Start with what you do now – basically understand the steps in your current business processes. How are they actually practised? What are the existing roles, responsibilities and job titles? You don’t need to reinvent your processes simply integrate kanban and lean practices within your existing operations.
- Agree to pursue improvement through evolutionary change
- Encourage acts of leadership at every level
Julia Wester’s article describes each of these principles in more detail.
David Anderson also describes 5 core principles in Kanban – Successful Evolutionary Change for your Technology Business.
The principles of transparency, inspection and adaptation are at the heart of the empirical process control optimizing the value of the Scrum Team’s work.
Five Scrum values support the core principles of transparency, inspection and adaptation:
In Essential Scrum Kenneth Rubin describes Scrum as a “refreshingly simple, people-centric framework based on the values of honesty, openness, courage, respect, focus, trust, empowerment and collaboration” and for me, the inclusion of empowerment, collaboration, honesty and trust are essential values which should be embraced by any successful agile team.
In conclusion, both are great frameworks and I’ve implemented each of them within different companies. For one agency I used Kanban as I had to handle multiple clients’ requests on multiple projects that could arrive unpredictably each day. Kanban was a much easier way to manage this “production line” of tasks. I could handle multiple workloads simultaneously; keep WIP (work in progress) at capacity, while ensuring team members were not overworked; assign tasks to internal and external resources (developers, consultants, designers and writers), who may be moving between multiple projects within a day; and still be able to forecast and plan activity for weeks in advance.
Kanban can also be a useful tool for service design, triage systems and BAU (Business as Usual teams) who handle multiple tickets and smaller tasks.
Delivery requests were often repeating (provide keyword research or undertake a technical audit on a website) and these may only take a few days to complete for each client. So Kanban was a lighter solution to manage their agency production needs: less bureaucracy, rapid turn around, frequent reprioritisation, multiple clients, fluid resourcing, visible reporting and multiple concurrent projects.
Over the years, I’ve found Scrum to be more useful on larger, complex, and long-term software and application projects, where there are a greater number of unknowns around the problem, solution and development strategy. You also tend to have a dedicated team assigned for a specific period of time with a fixed budget, a large product backlog, and a single business owner. I’d advocate Scrum if you have: One backlog, one product, and one product owner.
So, consider both frameworks and refrain from only utilising one option for all your production needs. Utilise what you consider to be the most appropriate and relevant approach to your unique operational needs. You’ll find a logical choice will make production so much easier and enjoyable.