If you are running a business today using Agile methods, it’s likely that you are not getting the productivity boost from it that you should, and your time to market for new features is probably not what it could be either.

Is that the end of the world?  By and large, yes!  The problem is that your impaired delivery capabilities have a substantial impact on your business agility.  How is that?  Your digital development process is at the center of your product management capability and if you can’t iterate quickly enough it will limit the opportunities for your product managers to redirect the evolution of your products while they’re in development.  When you are in a hurry to get new or updated products to market, they will be less evolved, less marketable and less competitive.

The Strategy-Execution Cycle diagram, below, illustrates the process, interconnections and decision points among the various activities that take place from the time the enterprise identifies an opportunity it would like to pursue (or a threat to which it feels a need to respond) and the time a product makes it into the market.

A common approach to Enterprise Strategy is “where to play/how to win.”  This defines to whom the company will sell its products and services and what those products and services will be.  What is represented in the diagram as the Product Strategy, which may be defined at the level of individual product or a related set of offerings.

The Product Design is defined and iterated on jointly by the Product Management (PM), Product Strategy and Development teams.  It is an embodiment of the Product Strategy that constitutes a starting point from which the product will ultimately emerge after cycles of experimentation and revision, informed by feedback from a number of sources.

The Development team implements each iteration through the Internal Design / Development / Evaluation Loop, contributing ideas to the Product Design along the way.  In this process, the product is built, reviewed, revised and updated iteratively, guided by the PM team.  The Usability Testing bubble in the diagram represents prospective product users (or selected proxies representing their interests) evaluating the evolving product, which informs the path that it will take from that point.

Having been tested in iteration, the evolving product can take one of four paths, three of which are shown in the diagram:

• It can be cycled back into further development,
• It can be released for External User Trials; that is, be exposed to a selected set of external users as a trial or ‘beta’ version,
• It can be sent to Product Release; that is, released for general use. At this point, it may be a Minimum Viable Product (MVP), which is missing key capabilities but is complete enough to allow the company to provide tangible value and gauge customer interest.
• Or, development of the product can be terminated if it is determined that it does not possess sufficient commercial potential.

In each of the first three cases above, information and feedback is provided to the PM team and upper management, which influences the ongoing evolution of the product.  It’s worth emphasizing that the product’s evolution is never done, even after it is released into the marketplace.  Today’s products exist in a dynamic environment in which others are constantly competing for your market share, and so improvement of your product is never-ending. A product is therefore best thought of as a living thing that must continue to grow and mature—or die.

The green arrows in the diagram indicate where feedback flows into decision-making processes relating to the product:

• Information from Usability Testing flows back to product design,
• Information from External User Trials and general users flows back to product strategy and product design and
• Commercial Performance data flows back to the PM team and everyone else responsible for determining the direction of the product.

Ultimately, your Business Agility depends on how rapidly you can deliver new or updated products into your selected markets. An excessively long development process can constrain your ability to execute your company’s strategic and tactical plans.  The severity of the impact this may have depends on what lines of business you are in and how dynamic your markets are.  Regardless, impairing your business agility will impair your sustainability.  Companies today are living shorter lives than ever, and you need to do whatever you can to survive and thrive.

But why aren’t Agile and DevOps, as most companies have implemented them, creating the acceleration they’re supposed to?   Cliff Berg, Founding Partner of the Agile 2 Academy points out that

“Product development involves People, Processes and Technology.  Common Agile frameworks focus almost entirely on Processes. They ignore the important role of Technology, and while they specify teams and roles, they gloss over or ignore complexities associated with People, how they should collaborate and what kinds of leadership are needed.”

So, cookie-cutter Agile and DevOps adoptions and coaching aren’t going to cut it.  The standardized frameworks and tools they are built on are actually solving the wrong problem and will not help you to achieve the productivity and velocity you need to truly compete in today’s markets.  This is because they provide canned processes to follow, but agility arises in the course of people defining their own process. A canned process defined by someone else will never make your organization agile. This is why Agile 2 was created: to get back to what works, which is to focus on leadership styles and guidance for how to define our own agile processes.

Standard “old” Agile approaches also fail to account for things like data architecture and product design, which the Agile movement unintentionally sidelined.  In all, commercial Agile frameworks are too rigid for today’s requirements and focus on the wrong things.  They can easily lead to a lot of spending on activity of low value and other ills that Agile 2 approaches could help avoid.

In the following article, we will examine how you can address what most traditional Agile frameworks are missing and realize a number of corollary benefits at the same time.