These are some thoughts on Kanban after reading Priming Kanban.
Most important thing to remember:
#Kanban is a change method!#
| Methodology | Kind of process | Change adoption |
|---|---|---|
| Plan Methodology | Too much proces | Resist change |
| Agile | Just enough process | Change is the fuel that keeps the engine running |
| Bug Driven Development | No process |
Ask yourself these questions at every iteration:
- What did we do well?
- What have we learned?
- What can we do better? Be sure to do a proper root-cause analysis.
- What puzzles us?
Kanban is about measuring. We ask a team member to perform a task. The member does not have to worry how long it takes until it's completed. We'll measure how long it took afterwords so that we can manage the flow of value in our system in the future.
We should make a queue of items. We shouldn't estimate the time but we can scale based on size.
We measure flow of value in the system. The flow is our main management tool.
E.g. How many days does it take on average to deliver a quality feature of size X? Being able to answer that question based on results in the past becomes our goal.
Because we only measure flow we can now focus our attention on improving it by removing bottlenecks to reduce flow variation.
Visualize, visualize, visualize! Make sure your team is aware of bottlenecks and what we're all working on.
Specify value in the eye of the customer.
Identify the value stream in your organization and eliminate any waste by finding tasks that stagnate or block the value stream.
Make value flow through the system at the pull of the customer. Kanban is really a pull based system at heart.
Continuous process improvement is most important. Don't focus on getting things right at the start because you won't. Just make sure you can improve your process continously.
Just-in-time delivery should be the goal of the system. Get to the predicatable part of the process as quickly as possible.
Everything is "your problem". Never push anything that is partly or wholy broken into the next part of the process.
Every bug is a change to reflect on how it managed to get into your system and how you can prevent that from happening again.
You cannot be quick, cheap and qualitive. Choose two out of the thre dimensions.
Questions I have:
- Can stuff move backwords on a Kanban board?
- Define constraints (on what?).
- Should each step be filled with the allocated Work in progress size? And if not pull a kanban from upstream?
Feature > Story > Task
Always improve the process!
A kanban is a work permit in the system. The amount of Kanbans in the system can never change.
Get better in your work:
- Visualize your problems and your flow.
- Limit your work in progress.
- Make your policies explicit.
- Measure and manage flow.
- Identify improvement opportunities.
Making a board:
- Start with what you do now.
- Agree to pursue incremental evolution.
- Respect the current process, roles, responsibilities & titles.
What is your release cadance?
By sizing issues you can improve estimations based on past flow of value through the system.
Visualize your constraints on the board.
Kanbans can expand and collaps on your board.
E.g. Scenario's expand when planning work and collapse after code review.
Cycle time = WIP/(Throughput/Unit of time)
When setting your work in progress limits you should think of the team size and the column size.
Anything you measure should be something you would act upon. It only makes sense to measure things if you will act on significant variations of that value.
Cumulative flow diagrams are great for measuring and estimating WIP and capacity.
Cycle time for estimates and process improvements.
Defect rates for adjusting processes.
Limit the number of real bugs.
Track blocked items.
- How long are items blocked?
- Why are they blocked?
- How can we remove these bottlenecks in the future?
Diagrams can help visualize performance but be careful to use too many. A few is usually better. They are a means and not an end.