I recently discovered John Cutler’s Twitter and blog. Everything I’ve read from him so far is excellent and highly recommended, but this table in particular felt like it was worth sharing.

It’s amazing to me how unhelpful our intuition often is when we’re under pressure to speed up. I’ve observed clear examples of several of these items personally over the last several years.

  • I’ve seen my team go significantly faster with less stress by shifting projects to being serialized with pairing and collaboration rather than giving everyone their own project 1

  • I’ve watched attempts to get ahead on planning be thwarted by changing business priorities. This can be frustrating in the moment until you realize the problem is a planning process that can’t adapt to new information cleanly.

  • I’ve been part of another team that doubled in size and then got cut back in half without much discernable impact in actual output over time.

  • The most effective change my team has made this year has been de-emphasizing filling sprints in favor of being clear about what we’re trying to accomplish in the sprint. I don’t think we’ve gone far enough in that direction yet.

Some items I’d add to John’s list:

  • Manual QA / Deployments vs Test Automation as part of development2
  • Senior devs filling up on feature work vs Senior devs mentoring, enabling and unblocking other devs3

  1. Besides the creative and redundancy benefits of pairing, shared resources like PMs/EMs/QA become bottlenecks as you parallelize. ↩︎

  2. This relates to the “handing off” QA point in John’s list. If the original people responsible for creating the feature aren’t writing automation as part of development, there is likely to be inefficiency or gaps in the testing. ↩︎

  3. Even worse if this is a manager doing this, something I struggled with as I transitioned from being a dev-manager hybrid to managing a larger team. ↩︎