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'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.
"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.
The bug may be better resolved by a new feature, or by a change in the customer's implementation.
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.
Code reviews are essential to learning and releasing a quality product, but they:
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.
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.
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.
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".
Alex is a QA Engineer at Kevel and a former product specialist and support engineer. He's passionate about building and testing software that solves real problems for users.