You can put sneakers on a brontosaurus, but that doesn’t make him agile. Most enterprise agile transformations are sneaker-clad dinosaurs.
Good luck with that execution thing!
There are many agilistas who dutifully report that Step 1 of any agile transformation is to get the CEO to rearrange the organizational structure of the entire company. After that, it’ll be a piece of cake! Well, yeah. But what if the company’s not restructured? Can a large enterprise still get agile?
Agile in the wild
Fortune 500 projects that cut across reporting lines, budgets, and systems are vexing. Large global firms are almost always arranged to accommodate financial reporting, with teams aligned to general ledger items- Region A, Region B, System C, System D, Sales Channel E, Sales Channel F, etc. But accounting line items are never how we deliver awesome software.
Let’s say that a company wants to implement a six-sigma initiative, in order to eliminate duplicate systems and “lean out” the remaining ones. An executive sponsor is appointed to drive the initiative (an “initiative” is a Really Big Project). It may encompass an infrastructure team located in Latin America, a security team in the USA, a manufacturing team in China, and a sales channel reporting team in Europe. The Agile Guru they hired steps in and says, “Well, the first thing you need to do is co-locate all these teams.” So, he’s fired… and the company limps along.
Because of intensive market scrutiny of quarterly financial results, managers at large organization tend to focus on Pareto’s 80/20 orthodoxy that 80% of gains are realized from just 20% of the decisions. This leads them to over-manage the 20%, which largely include simplistic directional choices like shorter (not longer) delivery time, fewer staff (not more), and more projects per person- greater resource utilization (not less). We might call this Pareto’s Paradox, because, in practice, enduring success for most companies comes from better management of the 80% of more mundane efforts. When major projects fail, is it because a single requirement on a single team fell 3 months behind schedule? Rarely. It’s likely because of many 1-day delays across several requirements, including inter-team dependencies. The 20% of high-impact initiatives consist of many smaller projects being driven under an umbrella program or portfolio. When those initiatives go off the rails, it’s because one or more of the smaller projects, one of the 80%, falls behind schedule, and creates knock-on effects for the rest of the program.
Waterfall Agile Transformations
Likewise, when CIOs decide that a huge IT department needs to convert to, or improve upon, agile practices, they usually want it done quickly, so that the company can realize the benefits as soon as possible (preferably in current quarter)- a totally understandable goal. Their subordinates dutifully create a big up-front design, with a logical roll-out plan, attainment milestone matrices, and, of course, vision statements. They tell the CIO when they’ll be “done” (usually 3-6 months, because how hard could this be, really?). And then they deploy a throng of trainers/coaches. After six months, most people have heard of agile, a few are agile-ish, but the company is neither a fleet-footed mammal, nor even a fast dinosaur, like a velociraptor, but still a lumbering brontosaurus, albeit now with a Nike ‘swoosh’ on it’s shoes.
What is a Delivery Smart Pattern?
Delivery Smart patterns are micro-solutions that help leaders at all levels better manage the 80%. They can be applied discretely, or in multiples to effect greater change, and even to help improve results on the high-impact 20% work. Delivery Smart patterns help companies transform their IT delivery and product development by letting them evolve a little at a time, at a “pull” pace that makes sense for each team and each org. The Delivery Smart approach does not require massive overhaul of every process for every person in every department. That is a “big-bang” waterfall approach to transformation. Delivery Smart transformations can be fast, much faster than waterfall agile, as a matter of fact, but they are deep transforms, not lip-service by executives and grudging compliance from front-line staff. Cultural change requires deep transforms, otherwise corporate gravity will pull employees back into their old ways of working. Leaders can apply Delivery Smart patterns at the individual, team, domain, organization, business unit, or company level, either alone or in tandem, to produce rapid, deep transforms with surgical precision.
Delivery Smart in the wild
There are many, many ways to drive a successful agile transformation. What make enterprise agile hard is the hundreds of exception cases that many agile gurus never encounter in smaller firms. In one case, we divided the client’s team along the lines of legacy and new systems. Legacy teams continued to work in the old way, with projects and tasks driven largely by run-the-business imperatives, while teams building the new systems took an agile approach, rotating through the key mission-critical systems. With a thoughtful object model driving architectural decisions, we targeted high-visibility, high customer-value (and revenue-generating) systems first, leaving “architectural stubs” which would hook into the other integrated systems. Next we targeted high value (to the company) systems, which allowed massive risk and operational expense reductions. At times, the teams worked on overlapping parts of the model and systems, and those were the points at which we aligned their agile patterns, practices, and timelines to each other. Doing so organically brought the sprint and delivery cadences for the entire organization into sync, rather than trying to force disparate teams into a single rhythm.
Other times, we’ve help clients drive very large distributed teams (hundreds of members) into a single cadence at the start of a fiscal year, so that we could create org-wide release schedules, and provide predictability and visibility to thousands of upstream and downstream teams who needed to know our plans as far in advance as possible. Even so, this was not a massive “big bang” approach. Because we were turning a tanker, we knew we could only turn it a few degrees at a time, so we focused on a series of small incremental changes across a broad swath of employees, the first of which was the sprint/release cadence, and culminating with some key quick-start practices. This allowed teams to learn together, share experiences, and suggest improvements to our approach. It also allowed management to report on progress across its entire organization at the same interval, so that after a few months, we could report on 4-5 sprints’ worth of data for 30 teams, rather than 4 sprints’ data for 2 teams, 3 sprints’ data for 4 teams, 2 sprints’ data for 7 teams, etc.
Leaders need an objective lens through which to view the options available to them. Trying merely to copy the approach used by a colleague, a competitor, or worse, an author who’s never working with your organization, is a recipe for disaster.
Success is built on a mountain of small pebbles. Large Fortune 500 dinosaurs rarely disappear from the face of the earth in mass extinction events. Rather, they spend too much time on their aging business models and technologies, while more nimble competitors nip at their heels, inflicting death by a thousand cuts. It does not have to be that way. Enterprises can evolve. GE, 3M, P&G, Merck, Emirates Airlines, Citibank, McKinsey, Microsoft, Apple, or IBM have all adapted and thrived, even as may of their contemporaries sank into the tar pits, tennis shoes and all.