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?
+3
A:
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.
Anirudh
2009-05-29 02:51:07
+6
A:
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;
Xian
2009-07-14 22:28:45