Are scaled frameworks process-focused, not people-focused.

Are scaled frameworks process-focused, not people-focused.

As noted in the Heavy Weight Championship of Agile, there has been a substantial amount of animated “discussion” about whether there is a need for scaled frameworks.  The three major players in the scaled framework arena, DSDM, DAD and SAFe all combine component Agile, lean, product flow and other techniques to address perceived needs in the overall software development community.  The primary issues are:

  1. Scaled frameworks are not “Agile.” This argument stems from the inclusion of techniques such as large scale release planning and hardening sprints (SAFe), an inception phase (DAD) and classic project management documentation (DSDM) to name a few techniques that draw attention. The argument is correct. These techniques are, strictly speaking, not Agile, however neither are the lean and product flow techniques that have become de rigor in many “Agile” implementations.  Our definition of what is Agile has evolved over time. The twelve principles in the Agile Manifesto provide a core set of values to use as a tool to evaluate whether any addition to our practice is Agile or not.
  2. The scaled frameworks are process-focused rather than people-focused.  One of the greatest successes of the Agile movement has been to refocus the software development process (including development, enhancement and maintenance) on people and communication without losing sight of the fact that software development is a process. This is generally interpreted that teams self-manage and self-organize to meet the demands for the work they are asked to perform.  All three of the major scaled frameworks embrace Scrum as their central team management tool.  What tends to be more explicitly delineated in the scaled frameworks is the role of the larger organization (management) to decide and plan for what will be done in terms of release planning.  I agree with the argument that large organizations are trading nimbleness for additional predictability (with the attendant risk). Processes and the predictability/coordination needs they address are driven because large organizations have so many more moving parts (for example marketing, sales, production, customer service, legal departments and that generally does not scratch the surface) that more free flowing communication is less effective.  This is one of the reasons why large organizations tend to be less nimble, but can tackle huge programs. 

The criticisms are valid, however overly specific to one type or culture of work.  In broader world ranging from small cutting edge firms to large, regulation-bound behemoths, there will be mechanisms needed to effectively deliver value.  We need to interpret those mechanisms through the eyes of the principles in Agile, lean and other methods to ensure we do not have runaway bloat.  What does not go away in any implementation scaled or not scaled is core premise of Agile that the people doing the work are the people who best figure how to approach and organize to get they need to accomplish done.  Teams are best positioned to react to the facts on the ground however they need to do so within the boundaries of business need and organizational culture.


Software development frameworks and methodologies are roadmaps.  Frameworks provide scaffolding based on a set values and principles. Methodologies (as we noted here) augment a framework with tools, processes and practices. One framework can be implemented by many methodologies, each representing different interpretations of the embedded values and principles.  Each different interpretation requires a different combination of tools, processes and practices.

Disciplined Agile Delivery (DAD) is a methodology that builds on many other frameworks and methodologies, including Extreme Programming (xP), which is also a methodology. Even though xP predates the Agile Manifesto (Kent Beck the creator of xP helped create the Agile Manifesto), both xP and DAD leverage Agile as their core framework.  DAD uses a three phase structure: inception, construction and transition, with iterations/sprints, stand-ups, demonstrations and retrospectives as processes in all phases.  xP features a flow that begins with an architectural spike followed by release planning, construction iterations, acceptance tests and small releases. Both represent very different implementations of Agile.

There isn’t a one-to-one relationship between software development frameworks and methodologies. One framework can be interpreted, and therefore implemented, in many different ways.  Different does not mean wrong, but it does mean that anyone that wants to embrace a specific framework needs to find (or create) a methodology that fits their interpretation of the values and principles within the framework.