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.

While Scrum is a rigidly defined methodology, kanban is less rigidly defined, but the linked article here covers the main difference and provides useful additional links.

The huge overarching difference is this: Scrum is based on timeboxed releases (sprints) into which individual units of work are grouped, while Kanban is flow-based allowing each unit of work that delivers independent business value to proceed independently. This, in theory, eliminates friction that exists in Scrum around managing sprint size/content.

I did Kanban for a few years. The process was something like this:

1. (bi)weekly review of backlog items for prioritization 2. When a dev is free, they pick a story from the board, and work on that exclusively (more or less) until it's done. 3. When a task is done it goes over to the QA area 4. QA grabs tasks that are ready for testing. They do the testing and then approve for deployment 5. Dev picks up a new story.

We pushed to production pretty regularly as soon as features were done. It is nice to not have this idea of "end of sprint" and having your task done by then. You just work, push to test, and pick up something else.