The best teams I worked in or know of, have the following traits and apply the accompanying practices.

My “ideal” team …

• is customer oriented
  • cross-functional team composition
  • involves real users
• understands requirements as assumptions
  • starts with the minimal desirable product
  • experiment/data-driven decision-making
• is autonomous, has no external dependencies
  • self-organises
  • pull system
  • >= 3 members
  • “owns” their product end-to-end from ideation to operations
• improves over time
  • learns constantly from each other (pairing, BBL, CoPs)
  • communicates well
  • regular process improvement and product feedback cycles (retros & reviews)
• delivers efficiently
  • is aligned, works towards the same goal
  • <= 9 members
  • visualises to communicate internally and externally
• delivers predictably
  • continuous flow (of stories on board)
  • predicts with lead time
  • approx. same size stories; no estimation
  • no planning meeting; backlog refinement as needed
• delivers at will
  • highly automated tests / deployment / monitoring
  • clean (enough) codebase

What works best is highly contextual, so I won’t try to force any of this on a team. I realised though that most process improvement experiments I suggest are guided by my vision of this “ideal” team.

Photo by Joshua Earle