Some rules to make
- Kanban left-most column typically fulfils the same purpose as a Scrum product backlog.
- Whether or not the list is sorted by priority, the team needs some kind of decision rule for which items to pull first: such as -
- always take the top item.
- always take the oldest item
- take any item
- spend approximately 20% on maintenance items and 80% on new features.
- A short standup meeting (at most 15 minutes) every day at the same time & same place. The purpose is to spread information about:
- what is going on,
- plan the current day's work, and
- identify any significant problems.
- Limit the number of changes for the workflow in Kanban and changes for an iteration in Scrum.
- Scrum board is reset between each iteration while the Kanban board is normally a persistent thing.
- Distinguish the different products' flow by using different coloured cards or by having swim lances
Some rules to break
- Both Scrum and Kanban are process tools in that they help you work more effectively to a certain extent.
- Don't limit the team to one tool as no tool is complete or perfect.
- Scrum prescribes 3 roles: (Product Owner, Team, Scrum Master) while Kanban doesn't.
- Kanban limits WIP per workflow state while Scrum limits WIP per iteration.
- Scrum prescribes a prioritised product backlog.
- Scrum prescribes burn-down charts as well.
- In Scrum, the Product backlog and Sprint backlog are divided. In Kanban, they are in the same workflow on the same board.
The general mindset in both Scrum and Kanban is "Less is more". So, start with less; i.e., less roles, less cards, less rules, etc.
How to get a mature workflow => Learn to build high-quality code => reduce the work-in-progress code => shorten lead times => release often => balance demand against throughput => limit work-in-progress => create slack to free up bandwidth => improve prioritisation to optimise value delivery => always align with the business.
let's talk more about Kanban
- Kanban systems are descended from pull systems family.
- The goals of pull system approach are:
- to find a systematic way to achieve a sustainable pace of work
- to find an approach to introducing process changes that would meet with minimal resistance.
- Kanban is the mechanism that underpins the Toyota Production System and its kaizen approach to continuous improvement.
- The first virtual kanban system for software engineering was implemented at Microsoft beginning in 2004.
Because Kanban satisfies the Recipe for Success as following:
- Focus on Quality
1.1. Golden rule - Write tests first before functional coding.
1.2. Code inspections improve quality
1.3. Collaborative analysis and design improve quality
1.4. The use of design patterns improves quality.
1.5. The use of modern development tools improves quality
- Reduce Work-in-progress
2.1. Reduce the quantity of design-in-progress boots software quality.
2.2. Reducing WIP shortens lead time.
2.3. Reduce our brains struggling in coping with all complexity.
- Deliver Often
3.1. Frequent releases build trust (both within team and with business sponsor, in my case Pandeeyar).
- Balance Demand against Throughput
4.1. You can find the bottleneck of the value stream.
4.2. Much of the stress will be lifted off the organisation and people will be able to focus on doing their jobs with precision and quality.
4.3. Create slack to enable continuous improvement.
4.4. Balance the demand against throughput and limit the quantity of work-in-progress to enable slack.
5.1. Prioritisation should be done by the product owner, business sponsor or marketing department.
- Attack Sources of Variability to Improve Predictability