At this year’s Construx Software Executive Summit one of the problems that we explored was how to scale software development, especially Agile development, across projects, portfolios, geographies and enterprises. As part of this, we looked at 3 different popular methods for scaling Agile: LeSS (Large Scale Scrum), SAFe (Scaled Agile Framework), and DAD (Disciplined Agile Delivery).
LeSS and LeSS Huge – Large Scale Scrum
Craig Larman, the co-author of LeSS (and LeSS Huge – for really big programs), started off by criticizing the “contract game” or “commitment game” that management, developers and customers traditionally play to shift blame upfront for when things (inevitably) go wrong on a project. It was provocative and entertaining, but it had little to do with scaling Agile.
He spent the rest of his time building the case for restructuring organizations around end-to-end cross-functional feature teams who deliver working code rather than specialist component teams and functional groups or matrices. Feature teams can move faster by sharing code and knowledge, solving problems together and minmizing handoffs and delays.
Enterprise architecture in LeSS seems easy. Every team member is a developer – and every developer is an architect. Architects work together outside of teams and projects in voluntary Communities of Practice to collaborate and shape the organization’s architecture together. This sounds good – but architecture, especially in large enterprise environments, is too important to try and manage out-of-band. LeSS doesn’t explain how eliminating specialization and working without upfront architecture definition and architectural standards and oversight will help build big systems that work with other big systems.
LeSS is supposed to be about scaling up, but most of what LeSS lays out looks like Scrum done by lots of people at the same time. It’s not clear where Scrum ends and LeSS starts.
SAFe – Scaled Agile Framework
There’s no place for management in LeSS (except for Product Owners, who are the key constraint for success – like in Scrum). Implementing Less involves fundamentally restructuring your organization around business-driven programs and getting rid of managers and specialists.
Managers (as well as architects and other specialists) do have a role in SAFe’s Scaled Agile Framework – a more detailed and heavyweight method that borrows from Lean, Agile and sequential Waterfall development approaches. Teams following Scrum (and some XP technical practices) to build working code roll up into programs and portfolios, which need to be managed and coordinated.
In fact, there is so much for managers to do in SAFe as “Lean-Agile Leaders” that Dean Leffingwell spent most of his time enumerating and elaborating the roles and responsibilities of managers in scaling Agile programs and leading change.
Some of the points that stuck with me:
- The easiest way to change culture is to have success. Focus on execution, not culture, and change will follow.
- From Deming: Only managers can change the system – because managers create systems. Change needs to come from the middle.
- Managers need to find ways to push decisions down to teams and individuals, giving them strong and clear “decision filters” so that they understand how to make their own decisions.
DAD – Disciplined Agile Delivery
Scott Ambler doesn’t believe that there is one way to scale Agile development, because in an enterprise different teams and projects will deliver different kinds of software in different ways: some may be following Scrum or XP, or Kanban, or Lean Startup with Continuous Deployment, or RUP, or SAFe, or a sequential Waterfall approach (whether they have good reasons, or not so good reasons, for working the way that they do).
Disciplined Agile Development (DAD) is not a software development method or project management framework – it is a decision-making framework that looks at how to plan, build and run systems across the enterprise. DAD layers over Scrum/XP, Lean/Kanban or other lifeycles, helping managers make decisions about how to manage projects, how to manage risks, and how to drive change.
Projects, and people working in projects, need to be enterprise-aware – they need to work within the constraints of the organization, follow standards, satisfy compliance, integrate with legacy systems and with other projects and programs, and leverage shared resources and expertise and other assets across the organization.
Development isn’t the biggest problem in scaling Agile. Changes need to be made in many different parts of the organization in order to move faster: governance (including the PMO), procurement, finance, compliance, legal, product management, data management, ops, … and these changes can take a long time. In Disciplined Agile Development, this isn’t easy, and it’s not exciting. It just has to be done.
Scaling Agile is Hard, but it’s worth it
Almost all of us agreed with Dean Leffingwell that “nothing beats Agile at the team level”. But achieving the same level of success at the organizational level is a hard problem. So hard that none of the people who are supposed to be experts at it could clearly explain how to do it.
After talking to senior managers from many different industries and different countries, I learned that most organizations seem to be finding their own way, blending sequential Waterfall stage-gate development and large-scale program management practices at the enterprise-level with Agile at the team level. Using Agile approaches to explore ideas and requirements, prototyping and technical spikes to help understand viability and scope and technical needs and risks early, before chartering projects. Starting off these projects with planning and enough analysis and modeling upfront to identify key dependencies and integration points, then getting Agile teams to fill in the details and deliver working software in increments. Managing these projects like any other projects, but with more transparency into the real state of software development – because you get working software instead of status reports.
The major advantage of Agile at scale isn’t the ability to react to continuous changes or even to deliver faster or cheaper. It’s knowing sooner whether you should keep going, or if you need to keep going, or if you should stop and do something else instead.
| Reference: | Different Ways of Scaling Agile from our JCG partner Jim Bird at the Building Real Software blog. |
