What agile framework is right for your organization?

Bitsy answers IT questions like the following on her Medium blog:

Dear Bitsy,

My company adopted a Scaled Agile Framework (SAFe) software development approach for a system that was originally written before some of my team members were in grade school. It’s a pretty fragile piece of software, and whenever we change anything, it breaks something else in a completely unexpected way.

We’ve been chatting about how easy it would be to recreate most of what the system does with modern open source software and public cloud services, but we have no idea how to get this idea into the whole SAFe process.

Can you help?

SAFe Cracked

Dear SAFe Cracked,

Congratulations on seeing opportunities for improvement! Agile software delivery includes ceremonies like retrospectives and activities that encourage continuous improvement. SAFe is one of multiple "scaled agile" frameworks marketed to larger organizations or corporations that often have older, unpredictable systems and organizational sprawl. SAFe does indeed keep some organizations safe from unpredictable software and unpredictable stakeholders.

SAFe is a perfectly good approach for systems with shared dependencies on traditional infrastructure, such as physical servers and databases and systems with poor unit and contract test coverage. These characteristics make systems brittle and hard to change because the impacts of change are not predictable. Longer-term planning and careful analysis of every change can be important for these systems because every change event can bring service interruption due to the lack of assurance that automated test coverage provides.

[ Learn how to automate DevSecOps in Red Hat OpenShift. ]

Why, dear old Bitsy remembers this type of careful planning from her mainframe programming years, when unexpected results from system changes were also very costly. SAFe, like waterfall, is a perfectly good approach to software delivery when dealing with older systems having poor test coverage and complex shared dependencies.

For organizations taking their first steps toward agile delivery, the longer planning cycles and formality of SAFe can also help nudge stakeholders away from "tapping your favorite engineer on the shoulder" and introducing new or poorly defined features with last-minute deadlines. SAFe is still very much needed in many large organizations, not to measure engineering velocity but to keep them safe from unpredictable legacy systems and stakeholders. But, SAFe adoption sometimes hits a ceiling and may not provide an approach you and your friends could take to quickly reimagine and deliver a system as though you were in a garage next door.

When software can be deployed in smaller pieces, with decoupled dependencies and robust automated test coverage, it is much easier to make changes and promote changes to production in small batches. Automated tests will tell you when any given change creates a negative impact on the system. Modern software can be built for continuous integration and continuous delivery (CI/CD), which requires good test coverage and the kind of tooling most commonly associated with "cloud-native" technology. The focus shifts from long-range planning to continuously grooming and prioritizing well-defined features and stories that deliver independent value and do not have complex dependencies on physical servers or shared infrastructure.

[ Get the ultimate CI/CD resource guide. ]

With this type of software development, you can pursue lighter-weight processes such as Lean or Large-Scale Scrum (LeSS), which normally require less organizational overhead and emphasize placing bets or creating hypotheses such as:

We might be able to recreate most of this very quickly, like entrepreneurs trying to disrupt our own business.

You’re exactly right! Today’s technology stands on the shoulders of giants and the vast sea of open source software that is readily available to rapidly compose innovative solutions. In fact, most modern applications consist of 70% to 90% open source software (OSS). "Build vs. buy" is dead, and "compose (from OSS) vs. buy" can be a great way to innovate, differentiate, and maximize value.

[ Read 3 outdated architecture practices that may be holding you back. ]

But large organizations often have a lot of organizational overhead, and questioning the amount of middle management involved in software delivery can be a very un-SAFe thing to do. To test the water, try to discover your organization's plans for public cloud adoption, which often brings opportunities to rethink existing software delivery processes.

If you find people are looking into public cloud adoption and CI/CD, hitch your wagon to those efforts. Your knowledge of the existing system will be valuable when it comes time to free it from processes that make it brittle and unpredictable. If the current system cannot be predictably changed or cannot scale resiliently to meet the needs of your business, a software engineering process like SAFe may address the symptom but not the root cause of your pains.

Best,
Bitsy

[ Become a Red Hat Certified Architect and boost your career. ]

This originally appeared on the Dear Bitsy blog on Medium and is republished with permission.