Do one thing at a time

You ever been on teams that work on a lot of projects at once? I've found it very commonplace, and it's not just something programmers do, I think we as humans have a natural tendency to start things because our attention drifts and finishing can be hard and it feels productive to get started on the next thing. And in a business context where people are asking you to do something it can be hard to say no, and so another project gets started.

And what's the result?

• More projects in progress than there are developers 🤯
• Stressed-out product-owners that try to keep on top of all the details of those active projects 🥵
• Stressed developers that feel overwhelmed with so many balls in the air and all the context-switching 😥
• Long standups as developers talk about projects the others don't care about 🥱
• Degrading code quality because there's a sense of not having time to do things properly 🐞

etc. etc.

It can be hard and require discipline to do one thing at a time*. But it is a worthwhile pursuit to focus on a single project at a time, and then complete that one project, and then move on to the next.

"But", I hear some gasp:

• "the whole team can't focus on one thing!"
  Well… w
hy not though? Generally speaking studies show great advantages in pair- and ensemble-programming in how it drives down bugs, delivers robust solutions with better designs, and creates knowledge-sharing. And it avoids waste: When a team focuses on a single project then standups become simple, a lot of code-change friction simply evaporates because developers align, blockers are overcome quicker because all brains are tuned to the problem, and people don't burn out from too much context-switching.
  
  

• "how would we prepare the next upcoming project??"
  I mean, look, if you need to introduce some concepts for the upcoming story I think we can handle having our focus on the active project and have high-level conversations about what's coming next. Something like a meeting once a week to discuss the next big thing isn't the kind of context-switching hell this article targets.
  
  But also, keep in mind maybe what to work on next should be informed by what was just delivered, y'know? Generate those learnings and react to them.
  
  Would that mean downtime between projects? Yes!, and that's a good thing, perhaps those days is where code and processes gets improved, where redesigns are discussed and implemented, and the overall health of the product comes into focus.

  

There is a classic agile motto: Stop starting, start finishing, which speaks exactly to this topic. One of the fundamental tools of Lean and agile thinking is applying Work-In-Progress (WIP) limits, to ensure the smooth flow of value. If we take that idea and set a Projects WIP limit of 1*, then we get a powerful forcing function that lets the team orient around a single, shared goal. It's a simple way to ensure everyone works together.

Henrik Kniberg, the famous agile and Lean coach, has a fantastic 7 minute demonstration of the benefits of finishing one thing at a time here:

Even in that simple example Mr. Kniberg demonstrates a 5-7 times speedup by focusing on a single thing at a time.

At the end of the day only you know your own context and you decide what works for you. I just think it's a shame when a team decides against mono-tasking just because of engrained habits, instead of taking up the challenge of finding the best, most sustainable ways of working together. There are no silver bullets and mono-tasking doesn't solve everything, but I do think it's an incredibly powerful technique that's well worth knowing about and at least experimenting with.

* I keep saying do "one" thing, but really I mean some very low number of ongoing projects. It might be one, but the exact number will depend on the scope and state of your actual projects and teams. So there is some wiggle room in this idea. It should just be some low number that the entire team can have in their minds and focus all their efforts on simultaneously and without stress.

Photo by Paul Skorupskas on Unsplash