Is anyone using Kanban? [closed]

问题:

Is anyone using Kanban (or scrumban) for the agile management practices? What is your experience with Kanban? How does it work in large complex environments with dependencies on waterfall projects?

回答1:

I know the BBC use it quite extensively. See David Joyce's blog for more details http://leanandkanban.wordpress.com/

He has a quite hefty slide deck in there to sift through.

I think the thing to remember about Lean thinking is that you must consider the value stream as a whole. Whilst you can super optimise the development team using techniques such as Kanban, it is more important to incorporate both up stream (Management/Analysis) and downstream (QA/deployment/support) to fully reap the rewards.

Therefore, to ask how does this fit into a Waterfall or complex process (beyond your personal effect), is not quite the right question. What is a more important question is to ask how can I begin to effect the entire value stream. I know this sounds like the beginning of religious Lean zealotry, but it is how you will realise the true value of a lean process.

For example, consider the following scenario for a typical project:

• Analysis time: 18 months
• Dev time: 9 months
• QA & release time: 4 months
• Customer adoption and rework: 12 months

Total: 43 months

If by applying Lean to the development process you improve by 100%, ie a development time of 4.5 months, bringing a new total of 38.5 months. You have then only increased the total value stream by just over 10%... insignificant!!

You need to begin to fight the fight and take the Lean thinking to upper management and demonstrate where real success lies... which is in the re-design of the entire process.

Remember Lean is NOT a development process, it can be applied to every aspect of the business.

Some interesting books on how to take this discussion beyond the the development team include;

• Lean Thinking
• Beyond Budgeting
• Throughput Accounting
• The Toyota Way
• Freedom from Command & Control
• Lean Product & Process Development
• Implementing Lean Software Development: From concept to cash

回答2:

Firstly, it is important to realize the problems that Kanban in software development tries to solve:

• Multi-tasking / Overload of work. Kanban addresses these by its Just-in-time and Queue systems. There is sufficient in the queue to keep everyone busy, but not overloaded (this comes with practice with estimation and efficient velocity monitoring). And JIT ensures that people do not have to multi-task and hence loose productivity.
• Unpredictable downstream releases. If you work in a large software organization, the piece you are developing might just be one in a large juxtaposition of software. Hence, there might be downstream teams that might wait for your feature. Kanban's queue system along with its time-boxed delivery schedules ensure that there is a certain amount of predictability in the releases.

Mostly, other agile practices also attempt to solve similar problems with different techniques.

large complex environments with dependencies on waterfall projects

This makes it hard if you have a dependency on a project that does not follow agile as then your input queue will not be predictable. If a non-agile project depends on you, the problem might be lesser - but you might end up producing more than can be consumed ('muda' in lean terminology). So, ideally you would want all dependant projects at least following some agile practices, if not kanban itself.

A nice article on Kanban, Flow and Cadence can be found here.

回答3:

Is anyone using Kanban (or scrumban) for the agile management practices?

Yes, I'm using :-)

How does it work in large complex environments with dependencies on waterfall projects?

In our environment we have >500 developers, so it is quite large. My team was the first, which used Kanban, mainly for maintenance work, and now for development. Our daily work was very hard, because the other depending teams were following classic development and management techniques, and they liked (they still do) to push the work and Kanban is about pull.

Our approach was to communicate as much as possible make our work transparent, but due to the reluctance of the environment we were focusing on our internal work. The WIP limit helped us stay focused, and with the visualize workflow we knew who is doing what at the moment.

Our throughput before Kanban was 90% (in other words, when 10 items came in, we delivered only 9), and after Kanban we had 100.4% and it was increasing. As an additional result, other teams started to came by and ask about Kanban, because they liked our results, and wanted to implement their own Kanban system. At the moment I know about 5 teams, which started Kanban in our organization.

HTH,

Zsolt