From the COO's perspective, the corporate IT department has hit rock bottom and they keep digging. Very little gets deployed, and the software that does make it live is embarrassingly bad.
IT is not exactly a clean canvas. ERP, CRM, document management and other key systems started life as COTS products but have been configured beyond recognition to a point where they can't be upgraded, and they're so ancient they've been disavowed by their vendors. Adding insult to injury, we're sitting on decades worth of data, but can't point to a single insight we've ever gleaned from it. The COO is not going to be jockeying to get IT reporting up to him any time soon.
The CEO has all but lost patience. She can't understand why she gets the same dead-end answer of "legacy systems" when she asks the CIO "why do we have to spend so much on IT?", "why are our systems not in the cloud?", and "why aren't we mining our data?" The board is asking her these questions, and she's got to have answers, not the same excuse.
IT knows it has a lot of problems. More than a few believe that the way it works is a big part of reason why. Every delivery team is blocked for reasons of access, authorization, and answers it needs from armies of people spread across a myriad of IT functions. Organizationally, there are silos within silos and shared services within shared services. If teams could work more independently toward a goal they would get a lot more done.
Somebody gets the idea that maybe we can solve this through better process. If we were to adopt Agile we'd have control and predictability and quality and speed-to-market. If we reorganize into cross-functional product teams, we'd get better solutions and some real insights.
A pilot or two here, a consultant or two there, a few slide decks and a site visit to a respected technology firm, and it's decided: we have seen the future, and it works. We're going to change.
We’re a large enterprise, so we need to roll out change at scale, and in a controlled manner. And so we get the enterprise Agile change program...
Over the years I’ve had the opportunity to examine several enterprise Agile change programs that are well under way. Those that were not living up to their initial fanfare (and quite a few of them were not) share a few common characteristics.
All organizational communication flows still go on one direction. The new "product operating model" bears striking resemblance to the old "program operating model": it moves from analysis to specification to development to deployment, all in a sequence of straight lines going left to right. There are no feedback loops anywhere in this cycle. As a result, there is no tolerance for team-level discovery let alone empowerment to act of its own accord on what it has discovered. Every team is free to build the product they were told to build. People are still bound to the plan, just like always.
Labor is assumed to be interchangeable. The Agile team model assumes there are no silos within a team: once a developer pair is free they take the next highest priority Story. But enterprise IT is loaded with specialist labor: this person only does front-end development, this person Java, this person Tibco, this person ABAP. Creating "cross-functional" teams doesn't cut it: the work distribution will be asymmetric and the team will lurch from blocker to blocker. It doesn't help that enterprise IT is also primarily staffed by contract labor. Contracting firms and their employees have incentives that favor labor specialization. The Agile operating model needs poly-skilled people, but enterprise IT doesn't have many people like that today and there are institutional headwinds against there being more of them tomorrow.
Process is the primary problem we face. No matter how collaborative and encompassing, a different mechanical process will not overcome the rot that plagues enterprise IT organizations: messy and multiple point-to-point integrations, a shortage of systemic knowledge, overloaded data structures, and poor data quality are not problems solved by a change in how work gets done. These problems are much larger than any one delivery team can possibly solve. Worse still, a process that requires a low-friction working environment to be successful doesn't stand much of a chance of taking root when the friction is very high.
As a result, enterprise Agile change programs don't make sense through an Agile lens, but they do make sense through a Waterfall lens. The change is largely cosmetic: Agile has just introduced surrogate terminology for how we’ve always done things. “Intake” and “portfolio management” are new words for “big up front design” and “detailed project plans” and rob the teams of functional discovery. Architecture activity that surfaces technical design before development robs the teams of technical discovery. Cross functional and even co-located teams can’t solve the big problems mentioned above in data, dependencies and system knowledge. Our new process might make us a little better on the margins, but in the main we still have the same integration hell, the same usability shortfalls, the same systemic brittleness and the same quality problems that we always did. The result, as others have written, is Agile in name only.
All right, so top-down change risks getting neither the mechanics nor the values of Agile. Wouldn't a bottom-up change program be more values-centric? A couple of months ago I wrote that bottom-up change - that is, linear scaling of team-level phenomenon - is inadequate for enterprise needs because there are enterprise dynamics and challenges that do not exist at the team level. This means there are classes of need that a focus on team-level process misses entirely.
The answer is not simply "do both top-down and bottom-up at the same time". To change an enterprise requires a change in leadership, not process.
Top-down change must not be charged with trying to answer the questions that enterprise IT has always mistakenly thought it had to solve: those of predictability and control. The only valuable top-down change is cultural. Cultural change is a leadership problem, not a process problem.
If we care about feedback, then by definition we value learning over being right all the time. If we value learning, than our operating model needs to be a picture of knowledge acquisition and application, not a picture of output control. There need to be at least as many (if not more) arrows depicting communication flows going backwards as forwards in the process. More importantly, it must be clear how that feedback is internalized and acted upon in the operating model. In the absence of that, learning is at best an accidental curiosity.
But even cultural change is not enough. Devolving authority and creating a means for genuinely incorporating feedback to team level execution is useless unless people are able to do these things in an unencumbered fashion. That means acknowledging the ground truths of the state of our technology and staff, and taking deliberate action on them. This is not easy to do. Long-tenured people in the organization likely made decisions that contributed to the current state of affairs. It's humiliating for somebody to admit that "past them" contributed to the reality of "present dysfunction."
As hard as that is, acknowledgement only goes so far. As Lisa Simpson pointed out to Homer as he came face to face with the fact that he is a rageoholic, acknowledging the problem is the first step. Dispiriting for Homer, it is not the last step. Acknowledgement has to lead to action that reforms. Without definitive action and lasting commitment to that action, the learned helplessness that plagues organizations with these conditions will erode the will to change.
It's all well and good to champion process, and by looking at process we can understand how ineffective we are and what we can aspire to be. But process will not overcome years of bad choices that have infected our people, assets and data. Process change that ignores these problems or denies they are encumbrances will at best be rendered inert, at worst will result in giving people responsibility without authority.
Leadership is not asking one group of people to make good on another's bad choices. Leadership creates the conditions where the rank and file have a fighting chance. Process is part of that, but in enterprise IT with large legacy estates, process is rarely the primary solution.
