1 Matching Annotations
  1. Jul 2023
    1. the team can see all of the work associated with deciding precisely what to build, not just the coding work

      Let's see what the Rock Crusher approach is.

      Imagine business ideas as rocks, backlog as a stone storage container, and code-writing as a stone processing container. Rocks are mixed in sizes, different in materials, and fall from outside into the storage container unpredictably. The stones are selected from the storage by PO, and BA reshapes them into smaller-sized stones and instructs Developers how to adjust their code-writing stone-processing containers to start dealing with the material of the rocks and their size. When the next rock is selected by PO, BA splits it into a new number of pieces, and Devs re-adjust their processing containers to the new materials and sizes. And all this continues to happen with the pressure on the team to be consistent in delivery speed with unpredictable pieces of rocks.

      The essence of the Rock crusher approach is in displacing the team’s focus. It should no longer be on how well the stone processing container is adjusted and how quickly the rock pieces are processed. Instead, the most attention should be paid to the pre-processing stage - to what is sent to the stone processing. These rocks-ideas should be more carefully selected, better prepared, split, groomed, combined, and assessed separately and in combination with others. That work even sounds huge and should be a team challenge and objective, there the team’s efforts should be put in.

      Analysis of an idea - not development - is a focus and priority for all the team!