Notes about the "Myths of Kanban" session from Agile Open Northwest
"MYTH: Kanban teams don't need to estimate"
* Kanban doesn't dictate that you need to do estimates. It's up to the team.
* Most valuable part of the estimates is the meeting, and the conversations that happen during the sizing conversations with the team. As humans and software developers, we can do Small, Medium, or Large. We're not as good as much differentiating within each of those.
* Team morale goes down if there is no progress, and then need to use WIP limits. Big tasks will just sit there and the cycle time goes to 3 months if you don't complete work.
* Used to use fibonacci sizing in scrum, but spent a lot of time without a lot of effort. Found that their 90% of the stories were either 1 or 2 weeks. It's so they sized tasks as big (2 weeks) or small (1 week), and it seemed to work really well. Cycle team is from when it was taken from the working queue to being accepted by the P.O.
* Suggestion is that if you get every task down to one, then don't need to estimate.
* Everything is a story without numbers, but need to break it down to get it down to smaller pieces.
* Write stories the way you want to written, and then track your tasks over time. Doesn't matter if it's big or small as long as it consistent. Track statistics and make sure your standard deviation doesn't fluctuate widely.
* Estimating can be seen as waste. Do the estimate, but not do anything with it. If you need to improve the estimates, and you get paid according to it, then there is business planning implications.
* Release planning is why you should be interested in estimating and velocity.
"MYTH: You Can't Do Release Planning with Kanban"
* Kanban says nothing about release planning. There is no official way for how to deal with it. However, there is a Monte Carlo simulator at FocusedObjective.com that will take scrum and kanban projects and will return simulations. Sensitivity analysis to isolate defect rate, rework rate and cycle time. They are building this within Lean Kit. Input has to be XML files. Instead of doing a telephone game where at each increasing level estimates have a fudge factor applied. WIP limits can represent staffing levels. Give feedback to which inputs that you can tweak (cycle time, defect rate, WIP limits) in order to get better idea as to when you'll reach a certain point of work completed.
* Release planning could also be seen as useless. But there is also business value to it.
* Team almost never does what's in the release plan if you're doing release planning. Essence of agile is to do what is the highest value and goals that you're pushing for. Decide over time. But need to have a sense of the bucket and value you're trying to provide.
* Release forecasting is inaccurate for a long time, but even with Kanban flow will still want to have a sense of the goal. Then how to recalibrate with Kanban? Continuous release. Being paid to solve a problem. Difference between a roadmap and release plan.
* Agile transitions, marketing cannot market things that are not going to be in the feature. Yet, you can also define the task that it isn't done until marketing is done.
* Story acceptance requires that there are statistics done, and so there is an early push of code in order to get stats from production.
* Single-piece flow, it's strange to have a column called "Done done." -- But not if that column is well-defined.
* There are columns that are wormholes like something within the code migration department. You can measure and say that it takes 6 days to get to code migration, but then it takes 8 days within a certain department.
"MYTH: We're disciplined enough to not need Work in Progress (WIP) limits"
* Beauty of visualization is that it'll show you your problems, but it won't fix your problems.
* There may be a cultural thing to not let people know what is happening, and so they will avoid exposing what it is really happening.
* Value stream and status board only having 3 columns. Will show when things are really stuck. Can start to discover the bottlenecks. Then can start to break out tasks and create more columns. Can have five tea
* Can see average task assigned per user. It used to be 15, but got it down to 6.
"MYTH: You can't do retrospectives with Kanban"
* Kanban is added to existing process, and so if you're already doing retrospectives, then add it in. Kanban will help you to inspect and adapt. Change WIP limits, and change process. Kanban is a good way to get to the how instead of talking about issues, but not changing. There are also non-process issues. Kanban helps to focus on the system and adaptations.
* Changing technology is easy relative to changing human behavior. If there is no new code, then found that developers would start writing tests, which was a big cultural change.
"MYTH: Kanban has no iterations"
* Sure you can have interations. You have different cadences, and break them up into different cycle times. You can decide how often to have demos, retrospective and planning meetings. In scrum, these happen in predictable times, but the timing of these can happen in more flexible times with Kanban.
* Scrum is theoretically malleable as well, but it seems like a rigid structure. That's because you're told to do all of the scrum practices right first, and then modify it to your needs.
* Scrum allows you the structure to be able to work together as a team. Kanban can then track how individuals do work and just be a way for individuals to track their work. Sometimes the work isn't well-suited for a cross-functional team -- such as maintenance on a legacy product (which is a myth).
* First virtual Kanban teams were software development teams doing greenfield development, but it also works well for maintenance teams.
* Scrum implementors have a sense of telling the developers that their process is wrong, and they're not doing it right.
* If a developer team is saying, "We're not getting anything done in a 2-week sprint, can't we try Kanban." It's not about Kanban, and it's not a silver bullet.
* Developers desire Kanban so that they can be an individual contributor, and use Kanban to kick over to next column and department. But are are they specialists? Or do they not want to do specific type of work?
* Example of having a team of 5 with a WIP limit of 15. Specialists who have the mentality of not my problem. If you don't have a square to move, then you'll be fired. Simplified it, and then determine the next thing. Need to have someone to step up. Don't know how to do it? Need some training? No... I can do it. If you lower the WIP, then people will step up to do the work.
* Can have both scrum and Kanban. Kanban is about visualizing your work.
* There's a lot of non-software teams using Kanban, and the concepts can be easier
* If you visualize the whole value stream, then you can see the overall cycle time. It provides evidence for the team performance based upon individual bottlenecks.
"MYTH: You should only ever have 3 columns"
* To-Do, Doing, Done are the essential columns. There is resistance to the expanding the number of columns to avoid people not working as a team. But if the cycle time is huge on Doing and there are ways to break it down, then it may make sense to expand the number of Doing columns.
* Track the flow of value through the system whatever the unit is. Use a pull system and not a push system. You can mix things of different sizes, but know which ones your tracking in your statistics. People use Lean Kit for visual management.
Personal Kanban has only a few columns including: Committed tasks, Would like to do, Doing, Delegated to others.
"MYTH: You can't have different stakeholders provide input with Kanban"
* Source of demand as inputs: Marketing, finance and product development. Put a limit on the input for how much can go in. Have a queue replenishment meeting every couple of weeks. Not forced amount of output. There are three spots as input, and let the different external stakeholders negotiate the priority and ordering.
* If WIP is 8, then can have a 3 and 5, but don't recommend that. Lean Kit developers try to do things in 2-week chunks.
* Percentage allocation doesn't work. There's only number one first priority slot. Try the buy a feature game. The different stakeholders can have a different amount of money allocated to spend depending on the prioritization.
* Why this team decided to use Kanban was that there 14 developers 6-7 product managers. Before Kanban, then there was a lot of siloing, and behind-the-scenes negotiating. Max of 6 to min of 2. Have a queue filling meeting, but no one could decide what to work on. Kanban forced the issues. Developers shouldn't decide the priorities, then the product manager should be doing that.
* Need portfolio development and discussions at the higher level. Pet projects don't always turn into revenue.
* Big topic in Kanban community is using Kanban at the portfolio management level
"How to manage everything at all of the levels without software?"
* Had a big room with lots of posters and cards. Lots of duplication for the different levels. Record keeping for Kanban doesn't have to be a nightmare. You can do things on the cards themselves. Wait until the card is done, and then record it to Excel.
There's no need to estimate with Kanban. Can't be done.
How can you plan with Kanban?
Can't manage releases with Kanban
Kanban replaces your existing process
Kanban works best for maintenance teams
Kanban does not have iterations
Some tasks can't be broken down enough
There is no such thing as a "Kanban Team"
Kanban encourages command and control structure
You can't track velocity when you use Kanban
Kanban board is the same as a Scrum Card Wall
You don't need WIP if your disciplined enough
Kanban is easier than scrum
Kanban is one of the many agile methods
Kanban requires all work items to be the same
Kanban doesn't work very will with backlogs
Can you do electronic Kanban? Yes.
Kanban is good for managing irregular-sized tasks
