Hi, writing a book on Kanban... A lot depends on what you mean by Kanban - the kanban systems (inspired by Toyota's systems but with very different mechanics),

Hi, writing a book on Kanban... A lot depends on what you mean by Kanban - the kanban systems (inspired by Toyota's systems but with very different mechanics), some locally-designed flow-based development process, or the Kanban Method - a thing you apply to what you do now (eg Scrum) to help it evolve. The David J Anderson book mentioned in the article describes the last of these; so will mine (disclaimer: David and I are colleagues). Scrum and Kanban (in the last sense especially) actually work together very well. Whether the end result remains recognisably Scrum is somewhat in the eye of the beholder. Two techniques that seem particularly provocative (in a good way) in a Scrum context are tracking work items until they have been validated in production, and planning (or simply doing) releases later rather than up front (perhaps in conjunction with technical moves in the direction of continuous delivery). There has been a lot of debate in recent months about estimation but neither method stands or falls according to which technique (or none) you use. It comes as no surprise to read that burnout reduced and productivity increased. Quite apart from the timebox thing (which works fine in some contexts, but can be very unhelpful in others), limiting work-in-progress (WIP) is often key to achieving sustainability at team level, and it almost inevitably leads to work being completed sooner with higher quality. A lot of teams stop there and it's hard to blame them, but paying attention to flow end to end can be just as big. For a team that is turning inwards or over-protected from real-world customers (as opposed to their proxies), Kanban might be just what they need too.