CUTTER BUSINESS TECHNOLOGY JOURNAL  VOL. 31, NO. 7
 

The only sustainable advantage you can have over others is agility; that’s it. Because nothing else is sustainable, everything you create, somebody else will replicate.

— Jeff Bezos, Amazon founder

In this article, we share six recommendations for those work­ing in established organizations who have received a call from the CEO or upper management requesting something like, “Please make us agile.”

The title of this article hints at our initial assumptions:

• Agilifying. Agility is not a specific goal. Each organi­zation will have its own flavor of agility, depending on its history, legacy, “shareholder” goals, market and ecosystems, changing conditions, culture, and the like. Agility is a muscle that can be trained and enhanced. Our focus in this article is on the actions that will enhance overall organizational agility.

• Your. Any organizational endeavor needs an owner. Becoming agile means initiating, leading, and coordinating diverse efforts within the organization as well as solving conflicts that stem from these actions. The recommendations we include in this article are directed at the leader.

• Digital. We use the generic term “digital” to denote the unique place of information systems and other digital technologies in enabling agile. Today’s orga­nizations are structured around digital processes. Digital is the nervous system that allows the organization to plan, implement, and evaluate its endeavors, such as enhancing the customer experience and/or promoting new, innovative business models.

• Organization. Being agile is for every organization: small, medium, and large — whether you are a five-person startup or a 50,000-person conglomerate; local or global; private or public; for profit, nonprofit, or government. You can even build agility into your department, your team, and yourself. While the language of this article talks about the organization, the recommendations are relevant, mutatis mutandis, to all levels.

Gone are the days that an organization could plan for sustainable competitive advantage and build a five-year (or even three-year) strategic plan. The business environment has become ever-more chaotic, dynamic, and disruptive. Enter agility, as the new capability to develop transient competitive advantage with shorter planning and execution cycles. Welcome to the age of “agilification.”

Step 1: Appreciate the Mental Challenge of Agility as “Building Flexible Buildings”

There is a giant universal mental challenge when it comes to agilifying. Think about standard buildings and the process of creating them. Thousands of years of experiences, images, mental models, tools (digital and otherwise), sample contracts, professional backgrounds, past knowledge, and people’s expectations — all stem from the assumption that you architect and build in a linear way. You analyze the need, you make the plans, you build the building, and even though you may add just a few more things in the future, the building is a fixed entity. Any attempt to design a building for change — let alone many changes — will not be appreciated, to say the least.

Yet the goal of the modern organization is to rebuild itself all the time. To arrive at various and different structures, processes, and business models. To match the needs of the market. Let’s envision our organizational building à la photographer Victor Enrich, who used Adobe Photoshop to demonstrate various future possibilities, including those shown in Figure 1.

The common response to the idea of flexible buildings is lukewarm, ranging from “you are crazy,” to “nice idea but not practical,” or, at best, “nice idea, now let’s talk about something else.” As an agilification leader, you will receive similar responses inside established orga­nizations. The responses may not be as blunt, but the innate mental challenge is a formidable barrier. Years and years of organizational culture are geared to fixed systems, not agile ones.

Step 2: Develop and Share Visions of What to Expect from Agility

A good way to combat the innate mental objection to agility is to start from what can and should be done with agility, and how the organization will look and feel when it is agile.

Agility can mean different things to different people, and it should. Still, it is important to vividly understand its various meanings and to allow the organization to be aware of these meanings and then prioritize them. For example, an agile organization will be able to do the following:

• Release features faster (from once a year to once a quarter, then every month, then every day).

• Digest new product lines faster (e.g., as a result of M&As).

• Divest a product, department, or region (including all relevant IT abilities).

• Integrate a new small-to-medium-sized firm (through M&A), keeping the good DNA of both organizations.

• Divest a current small-to-medium-sized department.

• Change business processes fast and replicate them quickly to the entire global organization.

• Introduce new and innovative business models.

• Make decisions based on data, including decisions around experiments, insights, and corrective courses.

• Retire and replace old legacy systems (with minimal effect on end clients).

• Replace key suppliers.

• Add languages and other localization measures to products and services.

• Experiment for certain groups with new features, services, pricing models, and so on.

• Capture and/or spin “giant” opportunities (e.g., Amazon’s entry into cloud computing or Slack’s turning an internal tool into its product).

• Leverage human resources flexibly anytime, anywhere (e.g., hire people part time, have a work-from-home policy, allow new fathers to work just three days a week for two years).

Keeping such a visions list — updating it and reminding ourselves of it — is a good cultural measure that the agilification leaders should manage.

Step 3: Build Abilities That Allow for Visions

The main value of being increasingly agile is to allow the organization to realize its potential visions more quickly, with less investment, and with greater chances of success. To realize those visions, one must have abilities — both non-digital and digital (see Figure 2). Non-digital abilities (which are not the focus of this article) include generic abilities like brand, financial resources and stability, long-term planning, market share, and industry-specific abilities like core technol­ogies, expertise, processes, business models, partner networks, and so on.

Digital abilities are information systems–enabling abil­ities that allow for agility. Let’s define digital abilities through a partial list of key abilities in the form of technologies, attitudes, and approaches we should adopt to become agile:

• Cloud-ness — key to both experimentation and scaling. Beyond the many advantages of cloud computing, cloud-ness has direct value for agility, including the ability to experiment, to share your applications globally, and to scale.

• Online-ness — moving to more online and event-driven approaches and less “batch” work (e.g., a data warehouse, or a system that stores data for analysis, can be replaced with all data being online, all the time).

• Data-ness — capturing, storing, harmonizing, analyzing, and gaining business value from data. Data is the new oil of the modern organization.

• DevOps-ness — merging development with operations to allow faster changes.

• User-ness — knowing your employees, virtual employees, suppliers, customers, future customers, and others by name and ID to allow data to be connected to them and to help data analysis resolve their challenges.

• Experimentation-ness — allowing for A/B testing of new features.

• Automatic testing–ness — seeking the ability to test your systems quickly to allow for high quality with rapid changes and deployments.

• Responsive-ness — developing once for multiple interfaces (i.e., Web, phone, watch, TV, voice).

• Measure-ness — measuring how people use your systems and remembering to balance measurement with analysis and action (we often see a lot of measurement but very little analysis, with the business taking very little action as a result of those measurements).

• Stack-ness — decoupling layers in your systems (e.g., base systems, data buses, and client systems).

• Lifecycle-ness — designing the lifecycles of new systems and planning for the end of life of new systems (including obsolescence).

• Open-ness — looking for external technologies and tools that can help accomplish tasks. Work that used to cost thousands of dollars to accomplish can today be done almost for free with advanced tools, plug-ins, open software, cloud, and so forth. The use of open source, microservices, containers, APIs/Web services, and an event-driven architecture allows faster development, greater flexibility, and speedier and reusable deployment.

Step 4: Initiate Actions That Build Abilities That Allow for Visions

Digital abilities such as those presented in Step 3 (and Figure 2) should be groomed using specific actions. Such actions — in the form of projects, initiatives, and directives — build systems, processes, and skills as well as provide visibility into what you can expect from the ability.

Actions are specific endeavors that both create business value and build long-term abilities. Let’s consider a few examples:

• Harmonize analytics of your websites. Ensure all your websites have analytics (e.g., Google-based), and you have a process to gain business value from analytics. This is a great start to building data ability and deriving insights into your customer experiences.

• Move systems X,Y,Z into the cloud. Select a few internal systems and a few external client systems to move to the cloud. This can start with a survey of systems and looking for solutions that are software-as-a-service (SaaS)-based. This is a good venture into understanding the pros and cons of cloud computing.

• Train a few teams in Agile methods (e.g., Scrum, continuous integration, continuous deployment). This is a helpful path toward building the “people” side of agile.

• Initiate one or two projects that connect business and IT, both of which work on the project(s) in the same physical/virtual space and experiment with rapid prototyping and development sprints.

• Train a few teams in design thinking to create and introduce innovative products and services.

• Review your systems (and their owners). This is a great start to mapping the current architecture and designing an updated one.

• Undertake globalization or localization of some systems. This is a good way to create a standard infrastructure.

Step 5: Master the Interplay Among Leadership, Culture, Business Architecture, and Digital Architecture

We have found that building agility calls for mastering the interplay among four forces (see Figure 3):

1. Leadership. Agility must be driven from the top, mainly because it will call for ongoing culture adaptation and conflict resolution (mainly in the form of who is in charge of what). The leader must fully understand the agilification journey. The leader’s decisions must demonstrate the right balance between the organization’s current state and the future to-be state, and between small and large, slow and fast, and value and risk. As Step 1 suggests, the forces against agility will be strong, and only clear and assertive leadership can build the needed momentum.

2. Culture. Culture is the way in which the organization acts, the principles that ultimately lie behind the ability of individuals and teams to create value. In a sense, agility is a facet of culture — as we want every part, every individual, every effort to be agile. It is up to the leader and his or her lieutenants to set the culture — often called “enculturation” — by explaining, demonstrating, giving direct feedback, encouraging experimentation, promoting minimal viable products (MVPs), and appreciating and building enculturation opportunities.

3. Business architecture. This force defines the current, near-term and long-term futures of the business. It captures the short-term opportunities; plans for next products, business models, or markets; and ponders further long-term value. Business architecture must coordinate efforts to prioritize, plan, and push for implementation of the needed visions (see Step 2).

4. Digital architecture. The counterpart to the busi­ness architecture force is the digital architecture force, which is entrusted with setting the appropriate evolving technical architecture of the firm. This evolution of the classic discipline of IT architecture manages relations among all current systems, their level of maturity and their place in the lifecycle, and their future.

The key term is interplay. To enhance agility, you must understand the nature of these forces. Harmonized interplay will push the organization forward, while harmful interplay will drag the organization down and turn the agility efforts into a battleground. As the leader of the agilification journey, you need to carefully balance these four forces in accordance with your organization’s level of maturity and style.

Step 6: Shift to Deadline-Driven Smaller Projects

If there is one measure that can drive an organization toward agility, it is the shift to deadline-driven smaller projects (see Figure 4). Simply put, we recommend defining smaller projects (that can relate to each other to build a bigger project) and focusing on the deadline — not just on the results. This is part of the skill of project management with a drive to flexibility. The key idea: it is better to have 90% ready this month, on time, than 100% ready next month, which is too late. Naturally, one must select the MVP and adhere to the critical path (e.g., FDA regulations, critical features, or connectivity).

Many organizations are already using quarterly and yearly planning cycles. Being focused on deadlines has known advantages. Deadlines can be yearly, quarterly, monthly, weekly, or even daily. Setting deadlines encourages direct planning, risk analysis, and resource allocation. In this approach, deadline-driven means that:

• Large projects are broken down into smaller parts. Short-term parts should be defined; longer-term items can be defined later.

• You focus on deadlines, not just results (“prefer partial results on time”).

• You make sure you have the needed resources.

• You define your goals in concrete terms.

• The task of planning, which takes resources, has a deadline.

• Testing, feedback time, migrations, and so on, can all have deadlines.

• You promise less and try to do more.

• You accept the possibility of missing the deadline, and when you know you are not progressing to schedule, announce the failed deadline early.

• You set review, test, and share meetings in advance (e.g., for the entire quarter).

• You manage risks.

• You use a “cyber-by-design” approach (in which security, privacy, and similar considerations are part of the initial design) to be cyber compliant from the beginning and not just at the end of the development process.

• You start with the “difficult” things. For example, if you are to develop an algorithm and a user interface, begin with the algorithm (assuming there is a risk that you may not have the right solution). Choose to do first the tasks at which you may fail.

The value of deadlines, and especially of smaller chunks of work (as seen in the “release often” philosophy of MVPs), is shown in:

• Observable results

• Ability to adjust to obstacles and changes much more quickly

• Clients/customers being able to see the value being produced on an incremental basis, which allows them to adjust their desires/expectations (if they like one aspect, they can state it; if they feel that something is really wrong, they can say so)

• Building the system for change (e.g., reuse of code, component replacement, auto testing)

Deadline-driven does not mean the abandonment of ambitious goals. When we are deadline-driven, we are simply choosing to have 75% of the desired results delivered on time, rather than 99% delivered late (there is usually a small percentage that is not delivered). Seventy-five percent of the results is usually 90% of what is needed, and if the other 25% is really needed, we set a new deadline.

In the long run, for smaller chunks of work, learning is the best benefit of being deadline-driven. Such shorter cycles allow for more wins, as well as more fails — encouraging (if there’s enough time allocated) learning, which is critical for building and evolving an agile culture.

Conclusion

Being agile is among the key core qualities of the modern organization. If your organization is not yet agile and you are in an industry adjacent to an already agile industry, you have an even greater challenge: how to become agile fast and not become disrupted. Frankly, in some cases, this may be impossible (think Kodak in the age of digital cameras).

The pressure to be agile stems both from the fear of being disrupted and the great opportunities that the digital world enables. Bear in mind that the pace of M&A is likely to rise due to (1) the digital investments that call for larger organizations and, conversely, (2) the ability of tiny players to act big (and thus disrupt established players) because of cloud computing.

The six steps presented in this article are designed to help guide agilification leaders, especially as they take their initial steps in the agilification process:

1. Appreciate the mental challenge of agility as “building flexible buildings

2. Develop and share visions of what to expect from agility

3. Build abilities that allow for visions

4. Initiate actions that build abilities that allow for visions

5. Master the interplay among leadership, culture, business architecture, and digital architecture

6. Shift to deadline-driven smaller projects

The imperative of the agile organization is directly linked to the digital force. On the one hand, we must be agile because of the external market and customer expectations of digital transformation; on the other hand, we can be agile because of internal digital technologies. Finally, despite difficulties, we need to remember that agilification has its benefits, too: it makes work very interesting — and very different. Enjoy the journey.