IT projects are by definition complex, and programs—usually multiple projects, related to each other in support of a common goal—are naturally even more so. For decades, project management organizations such as PMI, IPMA, and APMG have tried to crack the code to successful program delivery by describing program elements, the processes that must be followed, the competencies needed, etc. You might think that having a PMI-certified program manager on your staff would make your projects and programs failure-proof.
But people outside the project management department typically don't understand programs or the role that program managers play in facilitating successful projects or programs. I have even worked in organizations that insist, “We do not run programs. Everybody knows that programs fail, so we only have large projects!”
To me, this is just wordplay. Whatever you want to call them, your programs will not go away. The question is, How do you manage them? Different organizations have built methods and frameworks for scaling agile. Can those frameworks help? Maybe, maybe not.
I'm not aiming to compare SAFe, Nexus, LeSS, DAD, etc., or to describe these methods in detail. My point is to emphasize the fact that people are struggling with scaling agile for exactly the same reasons that have made us struggle with scaling to the program level for the past 50-plus years.
The ISO standard for project management
Take the International Organization for Standardization (ISO) 21500 standard for project management, for example. Below you see the “project system” as defined by the ISO. I have added the red boundary and comment explaining why I believe that still so many projects/programs fail.
The project system is complex, but scaling it to the program level adds yet another layer of complexity. Now interdependencies between projects must be handled. We might as well face it: Programs will always be difficult to manage, whether you control them using traditional or agile methods.
Don’t buy into a mere dream
Agile methods began taking the stage in the 1990s, and many folks have written about how to make agile methods work—“If only you could make the organization change its 10-, 20-, or 30-year-old project habits.” The “business” must act in a certain way, the team structure must change, people’s mindsets must change, the project culture must change. Some methods suggest that project managers are no longer needed.
But the move from traditional to agile project management is not a simple transformation. For instance, if we look at Scrum, the process seems to be so simple that it should be almost failure-proof. But we are still not close to 100 percent project success in the Scrum space. Why? Because this "simple process" is not very simple for many organizations that may have worked with a different mindset for many years.
Just as you cannot make programs go away just by calling them by a different name, the project system depicted above remains the same no matter how you decide to control its different parts.
Many organizations are selling the dream that “if only you convert to our ‘religion’ your project or program problems will disappear.” This is a wonderful dream, and you might not want to wake from it. But no matter how easy you make it appear on the surface, program complexity remains unchanged.
No doubt, good agile teams deliver quality more quickly than traditional project teams. I have seen that often enough. This is backed up by, among others, the Project Management Institute's report on impact of organizational agility. But please note: There is a big difference between organizational agility and team agility. Organizational agility is frequently lacking, or absent altogether.
Scaling agile
While there are many “ifs” in Scrum at the team level, the uncertainties multiply when you scale to the multi-team level. It may look easy on paper, but it's difficult in real life.
SAFe looks simple on the surface. One single sheet of paper depicts the whole method. But try analyzing the content, and try to work out what competencies are needed to make the whole thing work; you will see that it is very complex. It puts demands on the organization from top to bottom, which requires considerable organizational agility.
At the portfolio level, Kanban is used; at the team level, Scrum, XP, or Kanban. The middle program level introduces DevOps, shared services, etc. Before you even start, you must decide how to put SAFe to use and then educate the organization. You must analyze what all three organizational layers are doing now and then transform them into a “SAFe organization” that works smoothly together at all three levels. This is not a trivial journey.
Nexus and LeSS are examples of Scrum scaling methods. In Nexus, an extra management layer is introduced. The process is described, a few new roles are introduced, but other than that, organizations have to figure things out for themselves, how to make it fit their context. You get a lot of “what,” but hardly any “how.” For more on this, see the Nexus guide.
LeSS, too, can be depicted on a single page (see below). But the system is neither simple nor easy to make work. It requires both lean thinking and systems thinking, which affects each individual employee. A lean mindset does not come overnight or simply because management made a decision.
Why does it have to be so difficult?
While development teams will more readily buy into agile thinking, the management layer is usually harder to convince. That's probably because we are touching the power structures. With agile methods we disturb the organizational hierarchies, their silos, their habits. The management level fears loss of authority and decision-making power. Often we are moving from a “command and control” situation, to a system where the keywords are "trust" and "self-organization." This is in fact a paradigm shift.
My point is that scaling to the program level is complex and needs to heavily involve the management layer. The complexity as described above therefore implies that we are no better off with SAFe, Nexus, etc. compared to the old methods for program management. I know this will rankle some readers. Fans of different project methods are often very dedicated to them, and rather than looking objectively at the pros and cons, they cling to their specific method, insisting it will work if only people start to behave properly.
But if their “right way” is difficult to master, and especially if their way is counterintuitive, making it work is not likely to happen.
Having worked with a number of different methods, I truly believe that they could all work successfully if put to use as intended. However, project methods mainly live at the project management level or the team level. What's missing is truly engaged management involvement. Without it, this missing link is a common ingredient in project/program failure.
How to make scaling work
But let's take a more positive outlook. First of all, you need to consider the whole project/program system, and then you need to analyze:
Where are we now, and are we happy with our results?
How mature is our company?
How mature are you, project-wise?
Do we support our programs as needed on the management level?
Do we wish to become more agile? If we do, how can we make agile work in our context?
Not until you 1) take a look at the whole project/program system, 2) analyze where you need to change, and then 3) make that change will you get better results. Any method, whether traditional or agile, requires an organizational effort. If you don’t make that effort, you will just be buying a dream. Often a very expensive dream.
Keep learning
Take a deep dive into the state of quality with TechBeacon's Guide. Plus: Download the free World Quality Report 2022-23.
Put performance engineering into practice with these top 10 performance engineering techniques that work.
Find to tools you need with TechBeacon's Buyer's Guide for Selecting Software Test Automation Tools.
Discover best practices for reducing software defects with TechBeacon's Guide.
- Take your testing career to the next level. TechBeacon's Careers Topic Center provides expert advice to prepare you for your next move.
