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.

If there is one measure that can drive an organization toward agility, it is the shift to deadline-driven smaller projects (see Figure 1). 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 minimal viable product (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.

[For more from the authors on this topic, see “Agilifying Your Digital Organization: 6 Steps to Get You Started.”]

Architecture + Agile: The Yin & Yang of Organizational Agility 

This issue of Cutter Business Technology Journal explores how architecture can be the gateway to a future of continuous adaptation, innovation, and success for your organization. Order now with Code AA20 to Save 20%!