Random Acts of Agile
Moving Agile Up to Enterprise Scale
One of the biggest challenges for an IT leader in a company of any size is managing the interdependencies of multiple agile squads that are required to deliver a component of an End-to-End business capability.
Gone are the days where we marveled at a small squad of 6 people who used Agile methods to deploy a website that contained only static web content or at best had read-only syndication from multiple data sources but collected no data from visitors, processed no transactions and was integrated with no systems of record across the company’s enterprise architecture. Today we would look at such a project much the way we would look upon a child doing a “cannon ball” off the side of the pool while we are being asked to do a triple back flip with a twist off the high dive with a 50-pound pack strapped to our backs.
In today’s real world, most business capabilities require the careful coordination of multiple squads who must deliver items off their backlogs in order to fully enable the needed business capability. Take for example the simple concept of allowing customers more granularity in their communication preferences. All of the registration systems (e.g. Cookie Preferences, Communication Preference Center) must be enhanced to collect the information, the integration layer (e.g. API’s, ESB’s, ETL jobs) must be able to process and communicate the new information to the systems of record (e.g. Master Data Management, CDP, DMP) and then all of the systems of engagement (e.g. AdTech, MarTech, CRM, Customer Service) must now honor the customer’s new and more granular permissions. This simple business concept easily just broke down into work for at least 10 squads.
Like Many Things In Life, It All Comes Down To Effective Communication
There are many ways to ensure all of the squads are working towards a common goal but they all require additional planning and most of all good communication. Whether you choose to employ SAFe, Spotify or simply a Scrum of Scrums approach, the goal is the same and that is to ensure all the squads are deploying in a coordinated fashion and you avoid the dreaded “Random Acts of Agile”.
These Random Acts of Agile can be fairly benign where the end users are surprised by new features they weren’t expecting nor were they trained/enabled to use. This can lead to what I call “Enhancement Fatigue” where the end user communities become overwhelmed by the constant change in their user experience and they actually ask the engineering team to slow down or at least batch up the changes for formal releases that are accompanied by training and enablement.
However, these Random Acts of Agile can also be profoundly serious where they cause breakage in the end-to-end architecture because some of the squads had not delivered needed capabilities to handle the changes in up-stream or down-stream systems. The good news is that there are ways to allow squads to deliver at their own pace but not enable the new code until everyone is ready.
At the end of the day it all comes down to effective communication across the engineering teams and the end-user community.
Management Tactics
A decision point up front depends on whether or not the squads are using a common code base or separate ones. Having multiple squads working on a common code base complicates things and requires that the coordination amongst the squads moves down to the developer level. It will be important that common Continuous Integration (CI) / Continuous Deployment (CD) tools are used and careful management is in place with the various branches in the code stream, whether that is managed in Git or another source code control system.
Feature flags are a very effective method of allowing the teams to deploy production ready code at their own pace without the code becoming active until all the pieces are in place. A quick google search can provide plenty of details on how they work.
Feature releases are also something to consider to avoid the “Enhancement Fatigue” I mentioned earlier. This approach allows time to create enablement materials for the end user community, creating training videos, or even more formal training sessions.
Enterprise Architecture & Release Trains
While some agile purists will tell you that squads will establish self-forming guilds where cross squad architecture items can be discussed and coordinated, but I’m not a fan of this approach. I strongly believe that you need people with enterprise and/or integration architecture experience proactively involved to ensure that the components delivered by the various squads all come together to support a properly functioning solution.
In addition, you will need someone who manages the interdependencies across the squads to ensure all of the components are delivered as needed for a full release of functionality. SAFe calls these “Release Trains” which are managed by “Release Train Engineers”. However, there are other methodologies with similar concepts such as Spotify, LeSS or Nexus. The specific methodology is less important than the focus on the roles and the need for these things to be proactively managed versus assuming they will happen organically because Agile is magic.
To Sum Up
In today’s high-pressure IT leadership positions, one of the biggest challenges in a company of any size is managing the interdependencies of multiple agile squads that are required to deliver a part business capability. There are scaled Agile methodologies that can help but there must be strong support from the management team to focus on an End-To-End view of what needs to be delivered to fully enable a new business capability.
