Agility[1]
noun
the power of moving quickly and easily; nimbleness: exercises demanding agility.
the ability to think and draw conclusions quickly; intellectual acuity.
This is good as far as it goes, but it doesn’t address goals and outcomes. Agility itself isn’t your company’s goal; it is a critical ability without which you are unlikely to achieve it.
Agile, agile, Agility, Business Agility and Digital Agility
I have done a lot of writing recently about these many referents and the Agile 2 Academy, with whom I am currently working. I’ve stressed the importance of attaining what I have been calling Business Agility and observed the many ways in which Agile and agile as they are currently practiced don’t necessarily contribute to it.
- Big-A Agile (the myriad commercial frameworks, such as Scrum, SAFe, LeSS, XP, Kanban and others) subverts real agility by layering process and ceremonies on development teams, often with little benefit for its costs.
- Small-a agile is the goal for digital product development, but the OKRs associated with many efforts are not realized. Why that might be is something worth exploring.
- Agility is a goal, but it is an intermediate one. Companies’ goals are to produce products and services that flourish in their markets. Rapid development and deployment of competitive products and services is the true end goal; agility is a characteristic that successful companies must have to achieve it.
- Business and Digital Agility are two sides of one coin. True agility is characterized by rapid recognition of opportunities and threats, formulation of responses and execution at speed. This cannot happen unless a company’s ability and willingness to transform its Business and Operating Models correlate with the speed at which it can build solutions and products.
Linkages
In my previous article, I discussed the simplified EA model I employ and how it applies to the structure of Business Models, Operating Models and Operational architecture. Important elements of the models include Capabilities and Enablers. I believe that Enterprise Agility is directly predicated on the interplay between Business Models, Operating Models and the Capabilities and Enablers that are directly related to digital development.
A suboptimal approach to digital product evolution involves WaterScrumFall, which invariably results from applying traditional project management approaches to what is supposed to be agile development. Creating a scope, schedule and cost envelope for a project, hinders pivoting development efforts when issues, new information or other circumstances create the need to. Resistance to changing course is a mechanism that constrains agility. Insisting on detailed project planning in order to obtain funding, which is largely seen as a means of ensuring predictability, contributes mightily to this. It has been viewed as an important tool to manage risk, but it just as often constrains upside risk (producing a better outcome than originally envisioned) as it does downside risk (compromised outcomes, incomplete scope or cost or schedule overruns.) Funding a ‘project’, throwing it over the fence to developers and monitoring its burn rate vs. notional percentage of completion is a pretty sure path to a mediocre result, at best. Earned Value Management (EVM) is commonly applied for this purpose.
I believe that there are two places enterprises should look for agility constraining factors:
- The first is the enterprise’s approach to managing investments in product development and evolution. If business owners require product owners to provide a fully-articulated definition and path to an eventual solution or product to get approval and funding, then they leave them little or no room for agility.
- The second is the interface between ‘the Business’ and the development teams. If the collaboration between these two groups is not intimate and constructive, then outcomes dependent on Enterprise Agility are unlikely, if not impossible, to achieve.
Enterprise Agility: The One Agility to Rule Them All
Given the confusion about the definitions of what people might mean when they use the term ‘agile,’ I have decided to define a new one: Enterprise Agility. Companies that demonstrate Enterprise Agility:
- Follow lean product development and evolution approaches. They maintain portfolios of developmental product and service ideas and fund experimentation to identify the highest-potential candidates to invest in. They cut losses on experiments that reveal that an idea isn’t ready or won’t work as structured and redeploy capital when it makes sense to.
- Don’t assume the nature of the product or solution at the outset of an initiative. Rather, they begin the process of developing a product with the assumption and expectation that they will evolve its definition along the way, as what they learn is applied to influence it. This doesn’t mean that you should start intending to build a car and end up with a dump truck, but it does mean that you should be open to start with the intent to build a coupe and end up with an SUV.
- Are committed to the process from the C-levels down. Their senior executives, product owners and managers all collaborate closely with their development teams to ensure that issues and new information that develops during their experiments are evaluated and acted upon as rapidly as possible.
- Are unafraid to change course when circumstances indicate a need to.
- Avoid traditional project-oriented funding and management approaches. Among other things, these usually involve Big Design Up Front (BDUF,) which can create inertia and induce resistance to change, often when it is highly justified.
- Demonstrate a constructive and supportive culture, effective leadership and top-notch technical knowledge, skills and experience. These are consistent with Agile 2 culture, behaviors and knowledge.
- Address the full scope of transformation required to make the products and services they develop or evolve successful. That is, they are willing to remake elements of their EA, Business and Operating Models as required.
- Develop and hone their ability to transform, which will make future transformation more efficient. An important element of this is culture. Change is inherently stressful and reflexively avoided by most employees. The agile enterprise adopts a culture and policies that encourage the willingness to accept, participate in and facilitate change.
Conclusion
Earlier, we talked about supposedly agile development efforts failing to achieve the OKRs intended for them. There are, in my opinion, two flavors of this. Companies that employ traditional project funding and management techniques to initiatives employing Big-A agile development approaches create WaterScrumFall, which constrains their agility and diminishes the competitiveness of their products. Companies that fail to employ experimental product evolution approaches and create tight integration between their management structure and development teams often suffer an impedance mismatch. This is a communication and synchronization problem in which product managers’ ability to identify a need to revise a product under development and communicate it to the development team and the development team’s ability to change course are disconnected as a result of a communication gap or a fixed, time-boxed process mandate.
If product managers are not observing evolving products closely enough or if meaningful iterations of the product are not produced frequently enough, they may not see something heading in the wrong direction until it needs to be undone and rebuilt. If a dev team is inflexibly obligated to meet sprint goals instead of reacting to such realizations, it will contribute to the product’s progress down the wrong path. If management is focused on output, the amount of work done, rather than the outcome the work is intended to enable, then there can be perverse incentives to continue in the wrong direction until it becomes painfully obvious and undeniable. If product owners are not staying in touch with how well the product is progressing with respect to the business or market viability that should be essential to meeting OKRs, then a product may well not meet its intended goals. If executive management is not overseeing the Enterprise Architecture, Business Models and Operating Models into which the product is being inserted, then various forms of enterprise, technical and other forms of debt may be created, impairing Enterprise Agility downstream.
An Agile Enterprise must be mindful of and constantly focused on these issues, or it will suffer from impaired agility.
