There’s a fascinating video on Vimeo about 3 case studies in which the kanban system was used. In each of these case studies, agile worked really well in some ways, and not well at all in others.
Jalipo
A developer-centric company that built something technically very impressive, but didn’t get the market right. Users could get the same content for free elsewhere, so why would they pay for it through Jalipo? This is a good example of how agile works for developers.
Scheduling work in Kanban
This describes the dangers of silo-ing knowledge – they had less process, and in the short term, increased morale. But the lack of process led to a conflict with the waterfall approach of the rest of the business. The business required accurate predictions of when features would be developed, and scrum couldn’t give this. Accurately scheduling work requires a good team to give good estimates – a heavy emphasis on people. It was interesting to hear about the tension between a traditional waterfall business and an agile team.
Pitfalls of a large Kanban implementation
Scrum wasn’t working for the customers (why on earth is it presented to the client?) Kanban worked well, but it required a convincing case for adoption to make people want to use it. A lack of mid-level governance made it hard to get business-wide buy-in, and the quality of the team is still important.