Out-of-the-Box Agile in Large Organizations

Change is hard. Transformation takes time. Scaled agile approaches are not necessarily a gateway to a more comprehensive agile implementation.

Many large organizations have a legacy PMO or tech governance division, responsible for governance and transformation, who are themselves under pressure from both senior management, and the industry as a whole. Deliver 200% more in half the time! Save costs! So implies the marketing around these agile frameworks. These organizations often pick the low-hanging fruit by dictating an out-of-the-box agile implementation:

• SAFe - one of the most well-known "enterprise" agile frameworks, since 2011.
• Usually additive frameworks, using Scrum at the core
• Often pick and choose from other frameworks and practices - scrum, kanban, lean
• Concepts around bigger sprints, involving multiple teams each running their own smaller sprints
• Often combine concepts - meta scrum, scrum of scrums

These transformations are often done badly:

• A few short training courses has no effect
• Renaming project managers as scrum masters and product owners has no effect
• Endemic stresses on project managers leads to rapid fallback into familiar behaviors

Serious practical change - in policies, in processes (all business areas, not just software delivery), in behaviors - takes a long time, and is very stressful. There needs to be a safe environment where failure may be accepted as mistakes will invariably be made under stress. There's no easy answer. No silver bullet.

On the positive side, SAFe is one of the earliest certification bodies to focus on leadership training explicitly. The content is also quite good. If you are lucky, 5% of your leaders will really listen and get it, but most won’t invest time to be trained.

However, I don't think the transformation struggle is entirely due to the implementation of these agile frameworks, but in part it's the frameworks themselves.

In the early days of Scrum, a sprint was mandated as being 4 weeks duration. These days, agile folk might balk at that - the feedback loops aren't fast enough, value is not being delivered. Enterprise agile frameworks seem stuck in the same mentality - larger is better. The scaled agile frameworks are deliberately adapted to appeal to large organizations, to offer transformation with as little friction as possible, and in doing so forgo some of the core benefits of agile. Program increments can be smaller, but they can be released as a quarterly activity - not a huge leap for organizations that currently release quarterly or biannually. Large program increments are also the result of the difficulty in getting the whole release train to collaborate in person for a couple of days. The logistics and planning alone...

Problems with scaled/enterprise agile:

• No incentive to try and reduce the size of program increments (and therefore the time needed for the release train to coordinate)
• Doesn't address de-coupling dependencies but accepts dependencies as part of the process - if you remove those dependencies, then you don't need a program increment at all...
• Teams must deliver a program increment while also spend time discovering/incepting work for the next and also supporting the previous - there is a huge cost for such context switching
• Program increments delay the release of value and reduce the speed of learning
• Accepts large teams/silos
• Empowers programme managers, not product teams

The Answer

There's no easy answer. No silver bullet. No organization is the same - by all means attempt to adapt an agile framework to ease your organization into a new set of behaviors, but:

• Accept that the entire organization needs to make behavioral change
• Allow enough time
• Create a safe environment and allow people to fail
• Embrace the core benefit of all agile practices - empirical process control
• Strive to always deliver value more quickly
• Empower small teams