Spreading agility is no mathematics: the benefits and pitfalls of scaling frameworks

In my youngest daughter’s gymnasium, one of the classrooms has a poster on the wall stating: “Biology: the only science where multiplication and division mean the same thing”. It made me think of the peculiar way the success of small teams working with an agile framework is treated in businesses. The organic, natural, pragmatic and informal is valued over the formal, fixed and procedural way of working. As if biology is our collective favorite topic in school. We learned our lessons, right?! Yet, we expect to be able to copy or export the successful experiments we see in our organizational Petri dishes throughout business by procedures, plans, structure and formal reports. I have seen large corporations acting on agile like benefiting from a tidal wave. Implement agile frameworks, and instant success, cost savings, and staff layoffs can be ticked off the action list. The rest is ‘doing agile’, and so must we. We don’t want to miss the silver bullet train called Agile. What if something goes wrong along the way? Are scaling frameworks to blame? Did congresses, consultants, agile coaches, and tool vendors fool us? Does this ‘thing called agile’ turn into another broken promise of IT? Did management indeed make Scrum complex, as I hinted in 2015?

Only share or multiply what is successful, only the fittest will survive

Before you start scaling anything, please keep the Petri dish metaphor in mind. Ensure that the team(s) currently working agile gained the success you expected. Does one apply the process framework, guard the Agile Manifesto‘s principles, and learn from the past? You don’t want to spread malfunctioning teams, do you? Being adaptive to a new environment, being either market circumstances or a restructured organization, will facilitate the fitness needed to survive.

CIO.com recently listed 3 persisting misconceptions CIO’s have about agile. If you not already did so, please arrange for:

• pre-funded agile teams, driven by the capital budget, not the operating budget, to account for changing backlogs.
• the knowledge and resistance gap in the organization.
• understanding the difficulty to integrate the principles and the tenets of the Agile Manifesto in a mindset shift of the entire organization.

I recommend also reading Andy Hunt’s 2015 article The Failure of Agile. Note that Andy was one of the guys that gathered in the ski resort in 2001 to craft the Agile Manifesto. His bold statements may offend you or serve as a wake-up call, just before your intended organization-wide agile implementation. “The word “agile” has become sloganized; meaningless at best, jingoist at worst. We have large swaths of people doing “flaccid agile,” a half-hearted attempt at following a few select software development practices, poorly. We have scads of vocal agile zealots—as per the definition that a zealot is one who redoubles their effort after they’ve forgotten their aim. And worst of all, agile methods themselves have not been agile…..Agile methods ask practitioners to think, and frankly, that‘s a hard sell. It is far more comfortable to simply follow what rules are given and claim you’re “doing it by the book.””

What problem do you think needs to be solved through scaling?

It makes quite a difference if your underlying problem is:

• Preparation: How to break down the product (deliverable, outcome, end result) of a project or program into actionable items? How to arrange practical things like education, tools, team formation, stakeholder alignment, the establishment of the product backlog, etc.
• Release management: How to ensure that software is shipped in one or more releases and that software produced by different teams are integrated, tested from end to end, and work as a whole as expected?
• Portfolio management: How to manage a portfolio of programs, projects, and other initiatives, in which scope management may be at odds with agile product backlogs.
• Standardization: Can quality standards be set, and external standards adhered to? Can processes be standardized?
• Change capacity: How can more changes be implemented in less time? Will adding more teams or increase team size do the trick? Or must productivity be improved?
• Organizational learning: Will short feedback loops and close collaboration with the stakeholders and customers benefit the company to better align its products and services to the current needs?
• Predictability: how reliable are your estimations? Are (your) project managers and developers living on separate planets, and are there many inconsistencies between makers’ and managers’ estimations? Does the Mythical Man Month still rule your world? Are meetings perceived as overhead and disruptive concentration or flow? Aaron Gray wrote a lengthy criticism of Scrum on 24 October 2015 with many valid points impacting predictability or sustainable pace. I don’t see any of the frameworks solve these problems.

What scaling agile frameworks are available?

Different organizations have different things they want to scale. Again, there is no silver bullet. I present different angles to inspect frameworks, adopt and adapt in your organization.

• Scrum (created and maintained by Ken Schwaber and Jeff Sutherland).
• Scrum@Scale (created and maintained by Scrum.inc).
• Scaled Professional Scrum (created by Ken Schwaber for Scrum.org; Scaled Professional Scrum is perceived as the rationale for Nexus, refer to Günther Verheyen’s 2015 blog).
• Nexus (created and maintained by Scrum.org).
• Scaled Agile Framework (SAFe) (created and maintained by Scaled Agile Inc.).
• Large Scale Scrum (LeSS) (created and maintained by Bas Vodde and Craig Larman).
• Disciplined Agile Delivery (DAD) (created and maintained by Mark Lines and Scott Ambler).
• LeadingAgile (created and maintained by LeadingAgile).
• Scrum Lean in Motion (SLIM) (a pattern created by Growing Agile).
• FAST Agile (created and maintained by Ron Quartel).

In upcoming blog posts, I will cover these frameworks, methods, and patterns one by one and figure out when it is applicable and when you should not bother applying it given the problems identified above. I borrowed from the online Requirements Engineering magazine a comparison chart and completed it as today’s takeaway.