Delivery patterns and dark patterns

  • Retrospectives should not be the only way a team is heard. 1:1 channels with management should be the primary way that individuals work through their issues, as the manager serves to mediate what is a personal/developmental issue and what is a systemic one. Group settings are not very useful for this.
  • WIP limits are helpful but may feel like constraints. Consider a “right to left” board movement instead which encourages completion, then review, then unblocking, then collaboration, then doing, then starting.
  • Standups are helpful if the team is actually working on a project together. If each individual is working on something in a silo, standups have less utility.
  • Experiments are the core of a learning culture but require the team to be able to act based on the outcome of the experiment. If the experiment fails, the team needs to be able to pivot in order to proceed. Without this, experiment theatre serves to devalue real-world data in favour of business hypotheses. It’s demotivating and very risky.
  • Continuous delivery isn’t about merging code, it’s about delivering value to customers. Reviews should focus on what was delivered to customers, not what was merged.
  • Foundational/infrastructure work (e.g. design systems, test suite improvements, refactoring) that doesn’t have a customer-facing lens is important. In order to get it done, it needs to be treated as a project, given a name, business goals and milestones, and integrated into the day-to-day as a first class citizen backlog item. Without this, it is too difficult to judge the comparative value of this work vs customer-facing work.
  • Granular estimation has diminishing usefulness over time. Prefer a stable team with a strong backlog item definition and small pieces of work. Count the individual things delivered for a velocity proxy (dangerous) or simply measure whether you are improving the lives of customers with regular feedback.
  • Huge backlogs are usually not worth it for the maintenance cost. Over time the team will evolve their backlog item/sprint issue format and old backlog items will seem more and more irrelevant. Good ideas come back - don’t be afraid to delete.