When tackling a new project, feature, or application, it’s often useful to define a ‘minimum viable product’ or a ‘minimum viable feature’. The pure essence of this idea is to identify the minimum amount of requirements that produces a valuable and usable product. This ensures we focus on just a few features and deliver them quickly. Ultimately, we want maximize the value we provide, which means we may not implement all of the features we have planned. To truly maximize the value teams deliver requires a critical eye on requested features and a product team that is not afraid to say “no”.

While we strive for that level of rigor in our product backlogs, do we enforce the same level of rigor in our agile practices? As we add more teams to an organization and add more coordination points, we may be tempted to reach for some scaling agile practices, such as Communities of Practice or Scrum of Scrums. We may even reach a point where a scaling framework like the Scaled Agile Framework (SAFe) or Large Scale Scrum (LeSS).

But we should hold ourselves to the same level of rigor with our organizational changes as we do with our product backlogs. That means we should aim for minimum viable scaling; the least amount of scaling we need to achieve value from it. That means we need to say “no” to some scaled agile practices and aim to implement the most valuable ones first. Our aim in our scaling efforts should be the same as with a product backlog: focus on what gives us our ‘biggest bang for the buck’ first.