Agile Zone is brought to you in partnership with:

Jim Highsmith is an executive consultant at ThoughtWorks, Inc. He has 30-plus years experience as an IT manager, product manager, project manager, consultant, and software developer. Jim is the author of Agile Project Management: Creating Innovative Products, Addis Wesley 2004; Adaptive Software Development: A Collaborative Approach to Managing Complex Systems, Dorset House 2000 and winner of the prestigious Jolt Award, and Agile Software Development Ecosystems, Addison Wesley 2002. Jim is also the recipient of the 2005 international Stevens Award. Jim is a DZone MVB and is not an employee of DZone and has posted 30 posts at DZone. You can read more from them at their website. View Full User Profile

How Agile Do You Need to Be?

12.22.2012
| 2521 views |
  • submit to reddit

In The Upside of Turbulence Donald Sull makes an insightful statement, “companies do not pass through life cycles, opportunities do.” Turbulence causes opportunities and companies learn to take advantage of them, or they wither. Managing this flow of opportunities, which are increasingly disruptive, requires organizations to think seriously about their agility; as Sull defines it “the capacity to identify and capture opportunities more quickly than rivals do.” The question then becomes, “How agile or responsive do we need to be?” This question is one that organizations rarely ask themselves; at least they don’t ask it in enough depth. This article points out some ways in which the needed depth of analysis can be accomplished. Since every organization is different, each would need to adapt this analysis accordingly.

There is a caveat here. There are two capabilities (at least) needed to be an agile organization—the ability to anticipate areas of needed responsiveness, and the ability to adapt to unforeseen changes. This blog addresses only the first of these; however, by thinking about how to respond to anticipated changes, the organization contributes to the second capability also.

The first area for analysis is organizational units. For starters, some organizations are conglomerates of multiple companies. Companies then may be organized along business units that may be product category oriented with a separate shared services business unit. Other layers of organization may be functional areas (marketing, sales, manufacturing, and product development). The answer to the “How responsive do we need to be question,” should be asked at every unit level. One product may be more mature or market dominate than another. Marketing may need to be more nimble than finance. Product A may be in a more volatile market than Product B. Each organizational unit may have a different answer to the question of how agile to be.

A second area for analysis is the type of change anticipated—incremental, differentiating, or disruptive. Incremental change includes small new items added to an existing product, practice, or process. They are the small “ah ha’s” that improve products. Differentiating changes involve a significant product, practice or process enhancement that creates a clear differentiation from the competition and that keeps us ahead of the competition for some short-to-medium time frame. Disruptive change requires innovating to create an entirely new market or business model. Clearly the words disruptive and anticipating are in conflict, but disruptive doesn’t imply complete surprise. After all, the disruptive technology—digital cameras—was invented by Kodak. This disruption wasn’t a surprise, but there was a failure to take advantage of the anticipated opportunity. Facing reality is a big part of agility.

Based on the type of changes anticipated, the capabilities required to respond are different as identified by Donald Sull:

  • Strategic: consists of spotting and seizing game-changing opportunities.
  • Portfolio: the capacity to shift resources—including cash, talent, and managerial attention—quickly and effectively out of less promising business areas and into more attractive ones.
  • Operational: exploiting opportunities within a specific business model.

A third area for analysis is deciding how to manage the flow of opportunities. Opportunities go through four stages—identification (how do you scan for possibilities?), start up (getting the opportunity off the ground in various ways depending on the type), scaling (ramping up to volume), and maturing (managing the maturing and decline). For example, Lean Startup concepts and practices might be very useful for a new product or a new business opportunity. Regularly scanning the technology space (see for example the ThoughtWorks technology radar) could alert an organization to an opportunity for experimentation).

A forth area for analysis, and related to the type of change anticipated, is the type of response—the product, product features, customers, technology, or business model. A disruptive change might create a strategic opportunity that introduces a new product line or require an organization to re-allocate money and talent from one product line to another. A differentiating change might involve a creative new capability, or drastic price change, for an existing product. A competitor’s incremental product change might require a quick response to match their new features.

A fifth area for analysis would be to identify an organizations impediments and enablers—technology, practices and processes, capabilities, and culture. Following up on the last example, introducing a new product quickly might require a significant change in technology and continuous delivery capabilities. Rapid re-allocation of assets might require a change in portfolio management practices and a cultural and political change. Building a capability to deploy new features quickly (continuous delivery) might require changes in functional unit processes.

A final area for analysis might be to identify the “continuous flow” requirements for organizational units or products. Both lead time and deployment frequency should be identified. Lead time (time for a feature to move from backlog release to deployment) and deployment frequency (monthly, weekly, daily, or multiple times per day) requirements help an organization determine what capabilities they need in this area.

This list of responsiveness analysis areas should be viewed as representative, not comprehensive. The key point is that organizations should spend some time on this type of analysis to better understand their need for responsiveness so they can then better understand how to build their capabilities and culture to respond.

 

Published at DZone with permission of Jim Highsmith, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags: