Dec 182014

The only thing that seems larger than the recent enthusiasm over scaled Agile frameworks is the vitriolic arguments over what they really do. The confusion lies in the word “framework,” which is a much looser concept than “methodology.” While there are significant differences among teams (for example, in how co-located all the members are), it’s easy to imagine them cleaving to roughly the same set of principles and practices. The differences among organizations — their size, culture, history, types of projects or products, governance rules, relations with the business, etc. — are too great to impose anything nearly as formulaic as the disciplines adopted at a team level. (And, of course, the variances among teams are already significant.) In the next year, some of the rancor should disappear, as more people come to understand that any organization-level framework (SAFe, DAD, etc.) is more a toolkit, less a martial art.

[Editor’s Note: This post is part of the annual “Cutter Predicts …” series.]


Tom Grant

Tom Grant is the former Practice Director of Cutter Consortium's Agile Product Management & Software Engineering Excellence practice. His expertise lies in software development and delivery, with a particular focus on Agile, Lean, application lifecycle management (ALM), product management, serious games, collaboration, innovation, and requirements.


  One Response to “Figuring Out What A Scaled Agile Framework Really Means”

  1. avatar

    Colleague and friend Murray Cantor and I were just talking about the software frameworks subject yesterday:

    1. We could not agree more with Tom: it is indeed a matter of choosing the right set of tools from the toolkit.
    2. Where we see various Agile/Lean/Kanban initiatives get in trouble is in failing to differentiate between organizational scaling versus project scaling. Fitting a software method to the needs of a large scale organization is primarily a matter of structure and flow (and culture). Fitting a software method to the needs of a large scale project is primarily a matter of the intrinsic characteristics of the project, e.g. complexity (in the Dave Sonwden sense).
    3. Very unfortunately, the two often get intermingled due to the fact that organization/structure matters in any collaborative problem solving.

    — Israel

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>