Kanban for developer health

One of the questions I've been asked more than a few times over the years is how I've been able to nurture engineers, how I've been effective at getting teams to grow and mature into amazing engineering departments filled with wonderful people. There are a lot of answers to those questions, but one of the big ones that I like to bring up is how I work very hard to prevent engineer burnout.

It is extremely difficult to walk into an office, sit down, get into the flow, and be high-performant day after day after day. Solving problems with code is just this hard thing to do, and it takes a lot out of a person to be able to maintain that level of efficiency and quality that we expect from them. The world is filled with engineering resumes that have 1-2 year chunks of companies because the burnout factor is so extreme.

Scrum versus kanban at the mental level.

The number one issue I've had with adopting scrum is that scrum takes a lot of work to maintain a positive environment, whereas primarily focusing on going the kanban route will be easier to encourage people, provide good feedback, and have a positive nurturing place to work.

Scrum's ceremonies are designed to air dirty laundry; the retrospective tends to gloss over the "what did we do well" aspect of the previous sprint, in favor of longer discussions around "what do we need to improve". While having these kinds of conversations are meaningful and help engineers think about how they work, they can also exact a toll if every two weeks engineers are spending a good chunk of their time talking about negativity.

Similarly, sprint planning in scrum can become an environment where an inordinate amount of time is spent on stories that slip to the next sprint. Instead of "holy cow, you got that many points done, great job" there becomes an atmosphere of "these two stories slipped, what happened?" and the mental toll of these questions weighs heavily on engineers. For junior and mid-level engineers, these questions will make people want to work faster, which naturally introduces more bugs, which naturally introduces more technical debt, and an incredibly bad cycle can start.

How can kanban help with burnout?

I know what you're saying: "Mark, you need to just change the way you talk about this in retrospectives, and assign an accurate amount of points in planning" and that can definitely help, but no matter how you frame the discussion, the root point of having two week deadlines that are hard to achieve can cause even the best engineer to get burned out very quickly.

When using kanban for your development methodology, the simplicity and very visual sense of achievement are tangible clues for engineers to track their progress and celebrate their accomplishments. Hey, this card is moving! Hey, all these tasks got done! Hey, I'm pulling even more in from our backlog!

That thought in the back of an engineer's head, "can I finish this by the end of the sprint" becomes more one of "what am I going to work on once I get this done" and that can have a huge impact on mental health and wellbeing, much more so than your organization's vacation policy. Moving a card to the done column becomes this celebrated task, and it is that kind of positive feedback loop that will get every engineer to be a valued part of the team.

Hitting deadlines with kanban.

One of the biggest challenges with kanban is managing a long-term, multi-quarter or multi-year project which has a very specific deadline. Having kanban epics that line up with development times are the best solution, and very diligent tracking of how quickly the engineering team is moving will help, but the nature of kanban is simplicity, with no set deadlines from sprint to sprint.

Kanban, for me, has worked well when I'm able to define most of the tasks that need to be done in order to complete the project. If I know enough about the features or product that I'm creating, then I can accurately scope out the whole of the project beforehand, and any additions to the backlog won't materially influence the project deadlines.

Scoping under kanban becomes much more important, just because of the nature of keeping on time track for a given deadline, but also because future planning of development and features can rely upon past successes and time estimates. A deadline in kanban becomes more of "as soon as we're done with this story, we have a product or feature ready to launch" and less of "we're launching on May 1".

The best way I like to explain how we roll out a product using kanban is the scooter, bicycle, car analogy. You can build a scooter very quickly, and that will get you started. While you're operationally running your scooter and figuring out how people work with your scooter, you can also work on upgrading your scooter to a bicycle.

There isn't one date where your customers say "oh, now we're using a bicycle" but instead that natural transformation from scooter to bicycle gives your users a sense that your organization is consistently improving - which is the core of kanban. Similarly, moving from a bicycle to a car gets you from that working, effective solution for your users, to a high-powered application that moves faster than anything before it.

Transforming from waterfall to kanban.

There are still a lot of organizations that run as waterfall environments, where products are built to exact 100% spec and polish, tested within an inch of their life, and only after a dozen signoffs of stakeholders and department heads and the like, do projects ever find their feet, after which the maintenance cycle winds up boring engineers to tears, or they move right on to another crunching project, or they get to a natural point where they just want to leave the organization.

It can be a daunting task to introduce an agile development methodology into these kinds of organizations. It is a leap of faith to switch into a mode where an MVP gets released to the world, and tested by fire with real users hitting the MVP and acquiring data about usage, bugs, and improvements. However, the velocity of agile engineering departments speaks for itself and can quickly win over executives.

Additionally, transforming from waterfall to agile, specifically to a kanban environment, can be easier than you think. With fewer ceremonies, the relatively simplistic process, and a visual representation of your progress, engineering departments can move to a kanban methodology without a massive overhaul. The resulting switch can be very very good for engineer mental wellbeing, and can show immediate benefits when projects start landing sooner.

What I've learned about being agile at Skechers.

It was a few years before we formally introduced the agile methodology at Skechers. We brought in a PM who acted as scrum master, and introduced all of the ceremonies. She did a fantastic job and the team definitely went through a ramp-up time to get used to the concept of sprint deadlines, but the transition to scrum went well.

Part of the reason we were successful was that prior to the formal introduction to scrum, we had been operating as a kanban-esque shop for many years prior. We certainly did large waterfall-ish deployments every couple of years, just to do design refreshes or overall architecture changes, but for the most part the time I spent at Skechers was one where we were constantly improving from week to week.

Reflecting back on that time, I would have preferred for us to stay as a more formal kanban team, just because of the impact that I saw on our engineers. They started to perceive pressure where there wasn't, and while we were very good at keeping our ceremonies positive, I saw how easily they could have turned into net negatives.

Acting as that kanban-esque team, where I was internally maintaining the board and doling out tasks to engineers, wound up with a very reliable, very efficient environment, and getting to that spot isn't difficult for teams to pull off.