Kanban and the Five Stages of Grief

Over the past few weeks, Kevel has been testing out a variation of our Kanban process that was inspired by Elisabeth Kübler-Ross' five stages of grief. We've found this model to particularly well-adapted for our organization — a Clojure shop with eight developers and a highly technical support and account management team.

It may seem morbid to base a system for product development on reactions to death, but software is a world of constant change, and with change comes loss.

It's better to maintain the view that all our code will eventually break or become obsolete than to assume that the code we write will last forever. (Not to mention features launched that are abandoned by customers or fail to solve their problems.) Ultimately, grieving and software development are not unrelated.

Switching to a stages of grief based methodology wasn't difficult— it's only a minor modification of our previous Kanban-based process. The new labels for columns in Trello are the most notable difference, and our VP of Product Larry Karnowski has gone above and beyond to make sure we use the new names during our engineering standups and meetings.

Stage 1: Denial

"Denial" doesn't mean ignoring the facts in favor of a preferred reality. Rather, Denial in our methodology refers to a healthy skepticism about whether a proposed feature or issue should enter the development pipeline as described in the card.

Even if our support team is able to reproduce a bug reported by a customer, its card will remain in Denial until we've determined that working on the card will resolve the underlying problem.

The bug may be better resolved by a new feature, or by a change in the customer's implementation.

Stage 2: Anger

Let's be honest — software development is frustrating. Coders can work for hours and make no progress on a ticket, or even revert previous progress. Instead of representing the development phase as a smooth, linear process, we accept that during the coding phase there will be Anger.

This doesn't mean we expect our devs to be literally angry as they code (at least, they usually aren't). However, frustration can lead to greater determination (or desperation) to try more creative problem solving strategies. Anger isn't always a bad thing.

Stage 3: Bargaining

Code reviews are essential to learning and releasing a quality product, but they:

• Interrupt the flow of dev work
• Require the developer making the pull request to push other developers to review

Bargaining isn't so much a state of a ticket but a process. We've set up a Slack channel named #bargaining where devs can offer to review others' commits and have their commits reviewed in return.

Stage 4: Depression

Psychologists view depression as anger turned inward, which is also how we view our QA process. QA reviews the spec of the card as defined in Denial, and if the dev work fails to meet the spec, the card will return to Anger until the card passes QA and can move to Acceptance.

Some cards in Depression have a difficult time moving forward. At this point, we hold a review to determine where the blockers are and what intervention methods we should use, including abandoning the card or changing dev tactics.

Stage 5: Acceptance

Acceptance consists of the finishing touches to complete the card: updating our Knowledge Base, reaching out to customers to create closure, and creating follow-up cards for future work.

What's next?

Will we continue to use the stages of grief system after the beginning of April? Yes, we probably will.

The grief system is well-liked internally, and while we haven't noticed a significant increase in productivity, it makes our meetings more interesting when we review cards stuck in "Depression" or "Anger".