Business Agility: What Got Us Here …

During the last months, I have run into several situations where folks outside of R&D considered this concept of agile a nice little toy for the propeller-heads in software, rather than something that is in service of the company. In many cases, these people are stuck in a waterfall mindset and feel that it’s perfectly fine to release products once per year, if that often, and to keep selling what they’ve always been selling. The basic perception seems to be that the slow, planning-economy based approach has worked well so far and there really is no reason to change. All this talk about agile, speed, data and disruption is just noise and it’s best to ignore it and carry on.

At these occasions, I explain that the main reason why we care about agile in software is because it is an enabler for business agility. Business agility is concerned with the ability of the company to rapidly respond to changes in its business environment. This means rapidly stopping to do something that we’ve been doing for a long time when it becomes clear that it’s the wrong thing to do going forward. And it means rapidly starting to do something when an opportunity presents itself. Being able to constantly direct the resources of a company to the highest priority and most valuable activity at a moments notice is critical in an increasingly competitive world.

Traditional companies use plans as a tool to align the different functions in the organization. In the yearly planning cycles, the various functions prepare their plans based on the company strategy and then spend lots of time in alignment meetings to make sure that the plans of the different functions result in a successful execution of the overall company plan. Once the plans are approved and budgets allocated, everyone is focused on executing their respective plans. Incentives and rewards are provided based on the ability of everyone to deliver on their respective plan.

Each plan is based on a best guess of the state of the outside world at the point when the plan was created. However, the world is a dynamic entity and the guess might not have been very good to begin with. To paraphrase my favorite definition of “theory”, a plan is a beautiful thing killed by a gang of ugly facts. The reaction by those in favors of plans is the quote from Benjamin Franklin: failing to plan is planning to fail. But here’s the thing: I am totally in favor of planning. It is the blind, static execution of plans without constant adaption to the reality that I care about. No plan survives first contact with the enemy, as the military like to say. To quote one of the product managers in one of the Software Center companies said: I love agile because it allows me to change my mind every three weeks (the length of their sprint).

Imagine the organizational ability to redirect resources every couple of weeks. Assuming you have the right instrumentation to decide what to adjust the resource allocation to, everyone in the organization would always work on the most important goal. The challenge in traditional, hierarchical companies is that to enable this level of responsiveness in the organization requires empowering the rank-and-file in your organization. It means that individual teams can decide what to work on next based the information that they have collected during the previous sprint. In principle without any manager approval, which of course dis-empowers many managers in the organization and, in fact, makes their roles superfluous.

In addition, as most work requires competencies from different functions, we need to organize in cross-functional teams. Within the team we can adjust the direction on a continuous basis. Between several teams, adjustment can still be achieved quickly. Between different functions in large organizations, responsiveness is all but impossible. The only times where it has worked to some extent is where the leaders of the different functions have a very good relationship and have asked their staff to operate in informal, de-facto cross-functional teams.

Concluding, although in many organizations, the adoption of agile practices starts in software R&D, the principles apply to every part of the organization. The goal is to achieve business agility and for this we need cross-functional teams that are empowered to constantly adjust their activities based on their interpretation of the data coming from the market, customers, technology developments, competitors, partners and others. As the saying goes: what got us here, won’t get us there. It’s true for business agility too.

To get more insights earlier, sign up for my mailing list at jan@janbosch.com or follow me onjanbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).