So… your organization is on their “Agile journey” for maybe a year or two or five? A lot has been done already in terms of new practices, quite a bit of money spent and a lot of conversations about new stuff. But deep inside you know perfectly well that something is fundamentally wrong with this “journey” and despite all the financial and other resources thrown at the transformation, the enterprise itself has hardly changed at all. This is not uncommon to large enterprises. There are indeed fundamental reasons that prevent the organization from becoming Agile. Let’s talk about those:
- Rigid enterprise planning process. It’s delusional to think that there’s any room for agility when the master plans are carved in stone (often in excessive detail) for a year or more in advance. You begin to notice how soon the iterative and incremental process at the team level starts to contradict with the established enterprise planning routine. Moreover, rigid planning removes any need for hypotheses, experimentation and innovation. The call for “innovation” never gets beyond the enterprise wall posters and memos for the exact same reason. Due to the exceeding pressure from the leadership to follow the master plan, if Jonathan, a developer or an architect, wants to experiment with a new promising idea, he’s got to bend the rules to do so at his own risk. How about that…?
- Over-constrained funding model. The “over-constraining” part relates primarily to the following two aspects the funding happens to constrain: a) scope of work and b) effort allocation. Indeed, most of the organizations funding attaches directly to the scope of the initiatives being funded and in that way also contributes to the reason #1 above, leading to rigid plans. On the opposite dimension of the matrix, funds allocated to specific people, unfortunately serve as an impediment to cross-team (department or unit) collaboration.
- Fragmented, inflexible org structure. The problem often lies in the lack of cross-functional and cross-discipline orientation of the organizational units. On the other hand, there’s no such thing as a perfect long-term structure. That means that organizational units by design must be supportive of cross-unit collaboration. What we see instead in most instances is strong “ownership” over individuals and teams on behalf of the leaders and a strong preference for their own pre-palled work over cross-cutting emergent dependencies.
- Lack of critical feedback loops. Customer is almost never directly involved in the process. No, I don’t mean Marsha, a stakeholder from the Claims Department who allocates the money for the next set of software initiatives and therefore is a “customer”. I’m referring to Larry, who got into an accident on the icy road and is filing an insurance claim. I’m referring to Dana, the damage assessor, the bodyshop on the 3rd AVE that will fulfill the order… What we have instead is bunch of inside “proxies” that perfect their ability to speculate what the real customer actually needs. As a result, organizations spend tens of millions of dollars building a complete poo-poo. And what’s worse, they don’t have the ability to understand that for the same reason they built it in the first place.
- Misguiding metrics. With metrics there are two possibilities, as practice shows: a) a metric gets fully ignored or b) it doesn’t and therefore it produces a certain kind of motivation. There’s nothing bad with that, per se, if not one tricky problem: organizations tend to measure what’s easy as opposed to what needs to be measured. It is very easy to measure cycle time or throughput, but is a lot harder to do so for things like fitness for purpose, customer enablement, etc. As a result, the organization and teams get completely misguided by a biased set of metrics that eventually encourage local optimization. Also, importantly enough, some critical aspects of agility (such as the ability to respond to change, simplicity, collaboration, etc.) are fundamentally hard to measure and require additional means to raising the organizational attention to those and providing the necessary enablement.
- Leadership behavior that contradicts with Agile values. If you are an organizational leader, it’s not enough that you sign a check for training your teams in Agile, buy an Agile ALM tool and a couple more things to be fully happy. In fact, none of those will get you closer to organizational agility unless you start to fundamentally change your way of thinking and your actual way of operating. “How can we be Agile if despite the demos where we regularly produce executable increments, the leadership comes every Monday asking people for task progress in order to fill in their red-yellow-green status reports?” That was a real question I received from a Scrum Master on one of my visits to a large enterprise that was also “on their journey” for quite a while. If people continue to be micro-managed and held accountable to detailed scope planned for them by the “gods” that never even touch the ground, if people who follow the plans and the rules get promoted and those who break them to innovate and create more value, get reprimanded, the organization will never be able to instill the right culture.
Go over the list and see which ones of the six check for your enterprise. Altogether, it will give you a fairly good idea about the impediments you have to deal with on your path to organizational agility. But please be warned: there’s no way your organization can become Agile if these problems continue to loom over its fate. It is far more important that you start addressing the issues above than, for example, teaching teams how to use story points or bringing in a new method for running retrospectives. It’s like doing plastic surgery on a patient with heart failure.
By Alex Yakyma, Org Mindset.