Things I’ve learned or observed recently:

  • Some say Scrum is just what good managers do instinctively. This is likely true, but Scrum articulates a minimum viable process; Scrum doesn’t have optional components. Strong customer advocacy (product owner), strong team and process advocacy (Scrum master), and a motivated, self-organizing team form a stable tripod; if any of those components is lacking, the structure falls over.
  • Observing an organization’s adherence to Scrum-like processes (even if the names don’t match) strikes me as an excellent method for assessing the quality and health of an organization’s management team.
  • Big commitments are the sum of many small commitments; if the team can’t make and meet small commitments, it won’t be able to keep large ones either.
  • Commitment implies an interrupt-hostile environment.
  • Letting go of interrupts is hard. People won’t like it, and will push back.
  • Commitment to completion is a mutual agreement between the team and product owner. The team and product owner must both internalize this concept, or either one will become a source of interrupts.
  • Completion of a story may require input from other teams or results from a long-running simulation, but these waiting-for-input states are not comprehended by story point estimates; this is the difference between story points and units of time. Overhead should be considered when sizing stories, however; if a story requires minimal effort but won’t fit in a sprint due to fixed costs, it’s worth discussing how to decompose it into smaller units of work.
  • Assume customer requests are under-specified. The urge to shirk on acceptance criteria is strong; successful teams that delight customers will resist this urge.
  • As a first-order approximation, the Product Owner and Scrum Master roles are full-time. Start there, then adapt if needed.