Do one thing at a time

You ever been on teams that work on a lot of projects all at once? I've found it very commonplace, and it's not just something programmers do, or even just software, 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 there are people asking you to do something and it's hard to say no, 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.

Let's see how this sentence tastes: It's always an anti-pattern to do parallel work*.

The alternative is kind of obvious, but can be hard and require discipline: Do one thing at a time*. The team should focus on a single project at a time, and they should complete that project, and then move on.

"But", I hear some gasp:

• "the whole team can't focus on one thing!"
  But why not though? I'm sure there are some valid arguments against this in certain specific contexts, but generally speaking studies show great advantages in pair- and ensemble-programming in facilitating knowledge-sharing, driving down bugs, and delivering robust solutions. When a team focuses on a single project standups become simple, a lot of code-change friction evaporates because developers align, problems are overcome quicker because all brains are tuned to the current challenge, and people don't burn out from the stress of context-switching.
  
  

• "how would we prepare the next upcoming project??"
  I'm here to suggest the radical approach of just discussing the next project after the current project is done. What to work on next should be informed by what was just delivered, and what better way of doing that than to plan what's next after delivering?
  
  
  Does that mean downtime between projects? Yes!, and that's a good thing, perhaps that day or two is where the code and processes gets improved, where redesigns get discussed and implemented, and the overall product gets checked and verified.
  
  Even if a staccato stop-and-start rhythm is undesired it can be a great place to start, in order to let a team figure out how they want to overlap the end of one project with the start of the next.

There is the 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 to let 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.

I'm not here to dictate how others should work, 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 if a team decides against mono-tasking just because of engrained habits, instead of taking up the challenge of finding the best, most sustainable way 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.

* Look, 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. So there is some wiggle room in this idea. But even if the answer is not literally one it should be some low number that the entire team can have in their minds and focus all their efforts on.

Photo by Paul Skorupskas on Unsplash