Agile 2 Is About Business Agility—It’s Not Just an IT Thing

The team that developed Agile 2 was—intentionally—composed of people who collectively had experience in business, sales, program management and other leadership roles, in addition to product design and a range of engineering disciplines, as well as the obligatory “Agile” and “DevOps” experience.

It had been decided that since agility only made sense in the context of an organization as a whole, agility could not really be treated as just an aspect of a particular job function, such as programming.

The one dimension of agility that was not considered to be in scope was financial agility: that is, the liquidity of an organization’s assets and the duration of its commitments. Financial considerations were seen as sufficiently separable that there was no need to bring them into the discussions. That decision was made even though I personally had written a lengthy analytical book about tech project investment analysis, applying real options theory and simulation. (The book did not do well, because—buoyed by having had a prior bestseller—it was my first and only foray into self-publishing. Sigh.)

But every aspect of agility besides financial agility was in the scope of Agile 2. And so, except for financial agility, Agile 2 is entirely and squarely about business agility as a whole.

Also, let me please say this with great emphasis: agility cannot be achieved by having certain parts of your organization adopt new processes. That is not how it works. Agility can only be achieved by getting everyone to think and do things differently; and that applies at all levels, from the executive level down through the individual contributor level. That is why it is a transformation in the deepest sense, and that is why it is hard.

Let me explain why. Today’s knowledge workers do not merely perform processes in which they make the same decisions again and again. Instead, they are continually making decisions about new things—decisions they have never made before. That is because they are creating. They are creating new products, new services, and new approaches. And they are continuously learning, which requires them to apply new knowledge, in ever-changing situations.

Today's knowledge work is therefore not repeatable and cannot be codified as a process. There are process aspects to it, but there is always a lot of judgment and uniqueness and change.

If you were to define a process for today’s knowledge work, the process would have to be all-inclusive, to cover every possible contingency. It would have to be big and bloated. For example, suppose there is a new product feature being considered. Does the feature reach consumers, or only internal users? Those two situations might have ramifications for how the product is test marketed and built.

Imagine having to anticipate all such decision branch points ahead of time. A process that tries to do that would be very elaborate and bureaucratic: one can imagine having to submit the product concept to a product committee that would spend weeks (or months) analyzing it, applying the decision tree, and perhaps updating the decision tree, finally to announce the exact process to be used for the new product idea. By that time, the window of opportunity will have been lost.

Agility requires that people make judgments largely on the fly, with consultation of others, and test the judgments by making small forays to see what happens.

That is a lot faster, and it catches the market opportunity, in exchange for the chance of making an early containable mistake. And if you think about it, the old bureaucratic approach did not even catch most mistakes anyway.

This applies at all levels of an organization. This is because today, a large percent of issues cut across organizational boundaries. For example, suppose a product is part of a larger product. In fact, suppose it is part of three other products. That sounds unusual, but it is not: it happens all the time today with so-called microservices, which are internal products that are embedded in many other customer-facing products. Now imagine that a change is needed to a product which requires changing one of those embedded internal products: the change will potentially impact all the other products that use it, and those products might each be owned by a different line of business.

The old approach is to bubble that issue up to a strategic product planning level, and deal with it in an annual planning and product design cycle. But today that is way too slow. Today the affected managers need to meet as soon as the issue arises, talk it through and reach a collective decision that optimizes the outcomes for the organization as a whole.

Good luck with that happening on its own!—thus, leadership from above is needed to rapidly detect that there is an issue that is not being dealt with, and to orchestrate discussions and shepherd toward a good decision, possibly arbitrating the final decision.

That’s why today’s most successful leaders stay actively involved with everything that is going on. This is not to interfere or micromanage: it is to listen, and detect when there is an issue that is not being resolved and do what is needed to make the right discussions happen and reach a high quality decision.

That’s agility, and it operates at the most senior levels, supported by flexibility at the lower levels in that people at lower levels are accustomed to things changing and also to making local decisions wherever they can so that not every issue has to bubble up: the lower a decision can be made the better.

Agility only happens when everyone is part of it. Issues are continuously arising at every level, and leaders at every level need to be observing and listening and stepping in, and operating in a constructive manner to leverage their people’s expertise and drive rapidly toward high quality decisions. That is an ecosystem problem—not a process problem—assuming that you want to keep pace with today’s opportunities.

Photo Credit: Jo Zimny Photos, https://www.flickr.com/photos/joeyz51/