A recent discussion on the leanagile list compared Scrum and Kanban with respect to team swarming. The suggestion was that swarming doesn’t occur in kanban due to the way work flows from role to another. This is a common misconception, leading to the perception that kanban is more like waterfall than agile. Here’s my response.
Firstly:
I would say that limiting WIP in a kanban system can encourage swarming because team members have to help each other rather than pick up new work
And then:
The stages in a workflow are not people, or even roles. Just stages. So anyone can do them.
It just happens that people tend to specialise their roles to stages.
So kanban allows specialisation, but also encourages people to break out of their specialisation by limiting WIP.For example, I might have an analysis stage, and Bob, a Business Analysis specialist.
If the kanban system has throttled analysis work, Bob could probably work with developers or testers to help them improve their productivity.
And vice versa.
Its this focus on workflow, while allowing for specialisation, that means that kanban is a suitable technique for teams of all agile maturity. As teams learn to swarm, then their agility should improve as a result.
It’s a good distinction you make. A way to make that idea clear (that stages are stages, not roles) is to say that Kanban can have one stage only (in process) if the teams already know what they can do to make it get to “Done”. 🙂
I agree with Marick when he says that exemplifying Kanban with “analysis -> Design -> Implementation -> Testing” leads people to confuse Kanban with Waterfall (which could not be further away from the truth!).
Don’t you get the feeling that the world is not ready yet for “Flow”? I constantly get that idea, every six months companies all over the world squander countless millions of people-hours in creating a fat list of objectives for the next 6 months. This clearly tells me that the world at large does not understand the simple idea of doing one thing at a time…
I think this is one of Kanban’s strengths. Other Agile processes have “the team” and while they are all “equal” their identity is tied up with what they do, and generally people want to do the job their doing. This can create difficulty because people (mainly non-coders) can have difficulty seeing where they fit in on an Agile team. Its a lot easier for a Java coder to help out with testing than it is for a Tester to start coding Java.
So with Kanban people see a place for their roles, they see a BA activity, a coding activity and a test activity and see where they fit in. Yet as you say its not roles its stages, so over time people see where the problems and bottlenecks are and can choose to step out of role to help with the issue.
On day-1 I would not be overly concerned if people equate stages with roles, however if that mindset continues I would be concerned, then waterfall would be creeping in. Getting people to break out of their defined role and work on what is needed in part the responsibility of the Coach or Manager.
Hi I do understand the concept and I strongly believe that the idea of stages is a good idea in production near environments.
Maintenance or product delivery where you have a continuous flow of very small features to implement. I also believe it might make sense in big projects … the concern I do have is: there are not stages in creative work. F.e. Dev. and Test as a stage is in my eyes not really useful if you do Test driven development. I integration a separate thing? Yes — because people believe it is. But it is not. Integration should be part of development not a separate stage. Analysis the same.
It is very clear for me that a lot of people want to build a class of programmers. Not self-critical adults who enjoy going to work. And for this TPS is the best you can do — squeeze everything out of the workers and when they get old, replace them. (what they do in these cool japanese companies. capitalism rules.)
Is software development a production typ of thing or a more an art type of thing?
Maybe everybody and every context has to answer this question case by case.
My dogmatic point of view 🙂 the production type view leads into the wrong direction. Break through innovation needs something else than flow. It needs a flip, an “invention.”
The TPS was the source for Six Sigma, TOC and and and. All cool things and necessary. The industry in every area does now deliver more products with less defects than ever. We all want this — more more more —-
But … look into our economic crisis … we do not need improvement, we do not need more from the same, more variations from the same. We need innovation, we need Scrum-Teams facing the odds, running through problems, people who want to go on a mission, every sprint.
Product Development – the “new new development game” was something else than production.
I know there is a place for steady and contiuous delivery of more or less the same. Customization instead of innovation.
The only things is …. we should not confuse what was for what.
Scrum f.e. was for “controlling the chaos” — KANBAN might become the state of the art for controlling the production line in maintenance and minor enhancement environments.