In a turbulent and uncertain world, it is no longer adequate to deliver value; an organization must deliver a continuous flow of value, in ever-shortening cycles. Companies must figure out how to take advantage of the continuous flow of opportunities that pass by. Some opportunities linger for years, while others come and go quickly. Adaptive organizations possess the abilities to both sort good opportunities from bad and-this is a critical piece-get the timing right. Organizations need the processes, practices, culture, and leadership to sort through hundreds, if not thousands, of opportunities and turn those potential ventures into specific ambitious missions. These missions are achieved by executing on the right opportunities at the right time. Doing this over and over again, opportunity after opportunity, creates a continuous flow of value for organizations.
Every phase of the business must operate iteratively in short cycles-from the initial identification of new opportunities, to the discovery of product requirements and business models, to the actual product development, to deployment. Companies must hone their product delivery and technology infrastructure capabilities to deliver value time after time after time. No longer will a focus on just the short term or just the long term be adequate. Instead, a simultaneous focus on multiple time horizons, a balancing of short-term solutions with quality, will enable future solutions to be continuously delivered.
The IBM study mentioned in Chapter 1 pointed out that CEOs expect technology, and the changes brought about by technology, to be a critical issue for the next 3 to 5 years. It is somewhat vexing that today many of the opportunities arise from technology, as do many of the solutions to those opportunities. Technology both disrupts and enables. We need to be better at anticipating the former and encouraging the latter. Further, technology today-from mobile devices to implanted medical devices-is driven by software. While the iPhone is a brilliant piece of hardware and its manufacturing process is highly refined, without iOS (the operating system) and applications the iPhone would be just a pretty paperweight. Thus this section on delivering a continuous stream of value focuses on software delivery processes and practices, especially those processes and practices that managers need to understand. In today’s world, executives and managers, no matter which department they are in, need to understand the critical software delivery levers.
While the activities of an adaptive leader might seem endless, four critical actions contribute directly to continuous value delivery: improving speed-to-value, having a passion for quality, doing less, and building the necessary capabilities. This chapter addresses these critical actions.
Speed-to-Value
For our purposes, speed and value both merit further explanation. However, the first order of business is to examine our long-held beliefs about what constitutes performance in both business and projects. If our business objectives are to be responsive and agile, then we should start by examining how we measure success.
Flickr deploys software changes multiple times per day-and advertises this fact on its website. A medical software company deploys versions of its application software more than 75 times per year. Salesforce.com has gained a competitive advantage through its highly automated continuous integration, testing, and deployment of new software features. All of these companies, and a rapidly growing cadre of others, are reaping the benefits of speeding value to their customers.
Achieving speed-to-value reaches far beyond the early agile focus on development speed. In the early 1990s, I worked on a project at a large New York City bank. We managed to build a new application in 6 weeks (using 1-week iterations). The customer was ecstatic, IT operations not so much. After much negotiation, ops agreed to deploy our new application-one the client really wanted quickly-in 6 months.
Speed-to-value embodies two key concepts: speed and value. “Value” means that we are constantly evaluating-at a portfolio, project, capability (epic), feature, and story level-the value we are delivering to customers. It incorporates everything from calculating the ROI of projects to determining the relative (or monetary) value of features. Then on a release, milestone, and iteration level, we constantly prioritize and adjust scope based on value and cost.
The agile mantra has always been to deliver value early and often, but we have not always pushed that point to the limits of actual deployment and customer solutions. The reasons are more organizational than technical (although there have been significant enabling technical advancements).
The organizational issues are both product life cycle and business customer oriented. Although delivery teams have become agile, marketing, product management, or internal business departments have sometimes been reluctant to change their traditional modes of operation. Some product organizations have completely changed their perspective, however-from demanding commitment to features a year in advance to accepting the flexibility that agile development allows-and have profited handsomely from that responsiveness to customers.
Similarly, at the back end of the life cycle, development and operations may work closely on smooth transitions from development complete to deployment complete. Value is realized only when features are actually deployed, not when they are ready for deployment. Speed-to-value should be measured across the entire life cycle, from placement on a portfolio backlog to actual deployment.
An even more difficult change may be getting business departments to think through how they can use frequent deployments to their advantage and then change their business processes to accommodate them. They will also need to decide how to articulate the benefits of these frequent deployments to their customers. For some business departments, daily deployments of new features may have significant consequences; for others, it may not. Finding the right schedule of deployments for different groups means business departments will need to become more agile themselves.
These organizational agile transformations are often much more difficult than implementation of agile practices and principles in the engineering department, but their benefits can be extraordinary. As enterprises learn to be more adaptive, agile, flexible, or dexterous, the potential for competitive advantage multiplies rapidly.
Beyond Scope, Schedule, and Cost: The Agile Triangle
It’s better to have fuzzy numbers for things that are important rather than precise numbers for things that aren’t.
Many agile teams are faced with the paradox of being asked by management or customers to be “adaptive, flexible, or agile,” while at the same time being asked to “conform to plan,” where the “plan” is a traditional Iron Triangle plan based on scope, schedule, and cost. We ask teams to be expansive, to work closely with customers and respond to them, and to seek value-but then we penalize them for being 10% over budget.
The Agile Triangle, shown in Figure 3.1 and introduced in Agile Project Management (Highsmith, 2010), addresses the real goals of projects-producing value that delights customers, building in quality that speeds the development process and creates a viable platform for future enhancements, and delivering within constraints (i.e., scope, schedule, and cost). The Agile Triangle alters how we view success.
First, let’s look at value. A number of studies have shown that 50% or more of functionality delivered in software is rarely or never used. Even if some of that functionality is necessary (e.g., the functionality for a year-end accounting close), there is still a huge percentage of unused functionality in most software systems. This leads the conclusion that scope is a very poor project control mechanism-we should be using value. Furthermore, rather than asking, “Did we implement all the requirements?” the question should be “Can we release this product now?” I’ve known projects that were deemed releasable with just 20-30% of the originally anticipated functionality-and the customers were delighted. They got their fundamental needs met-very fast!
The Agile Triangle also elevates the critical role of quality, a dimension we have given lip service to for far too long. If we are serious about quality, then it deserves a primary place in any measurement program. Quality comes in two flavors-today and tomorrow. “Today” quality addresses the current iteration or release of a product. It measures the reliability of the product: “Does it operate correctly?” If a product operates reliably, it delivers value to the customer in the form of implemented features. Products that are unreliable, ones that give incorrect answers or periodically fail completely, will fail to deliver current value.
The second quality dimension is future quality: “Can the product continue to deliver value in the future?” The ability to deliver in the future tests an application’s ability to respond to business changes, both anticipated and unanticipated. While we can often use flexible designs for anticipated changes (e.g., allowing for tax table changes), the strategy to deal with unanticipated changes is different. Responding to the unanticipated future requires adaptability, and the key to adaptability is keeping technical debt low.
The final piece of the Agile Triangle is constraints-scope, schedule, and cost. It’s not that these elements are unimportant, but simply they are not the goals of a project. Constraints are critical to the delivery process; they establish clear boundaries within which the team must operate. However, only one of the three elements can be paramount, and on agile projects this is normally schedule.
The Agile Triangle gives us a different way of looking at success, a way that helps resolve the paradox of adaptability versus conformance to plan.
Constraints Drive Innovation
On a recent vacation, I visited the Mingei International Museum in San Diego. During a tour by the museum director, we were looking at a mid-1930s Santo Domingo Pueblo (New Mexico) necklace. “Interesting about this necklace,” the director said, “are the ‘nots’-not coral, not obsidian, but old melted phonograph records for the black element. During the Depression the Native American artists were constrained by the lack of materials. Everyone thinks that creativity and innovation are driven by freedom. In the art world, they are often driven instead by the constraints.”
His comment got me thinking about the constraint point on the Agile Triangle (Figure 3.1). While the most frequent discussions are about value and quality, we can’t forget the role of constraints and the way in which they often drive innovation and design. Teams at Ideo, the highly recognized design firm, are often driven by time constraints. While they have great freedom and a highly collaborative environment, they operate under very tight time constraints-and they usually deliver.
There are two key points here:
- Constraints are critical to innovation and creativity.
- Constraints should be carefully constructed.
The second point here is one that often eludes us. Constraints are often arbitrarily set, with little thought to their impact on product development. For example, as Exploration Factors get higher (greater risk and uncertainty), setting aggressive time constraints may be very useful. However, setting aggressive scope requirements at the same time is usually counterproductive.
In the Agile Triangle, schedule, cost, and scope are identified as the main constraints. How we set these constraints has a significant impact on the development effort. Do we set constraints for one of these elements or all of them? Do we set aggressive targets or looser ones? If we want the team to be innovative and creative, setting too many or too aggressive constraints can undermine our goals. One technique I’ve found effective is to create a tradeoff matrix that places scope, schedule, and cost along one axis, and fixed, flexible, and accept characteristics along the other axis. Each constraint can then have one and only one value. For example, “fixed scope, flexible schedule, accept cost” would indicate that scope was the most important constraint with limited leeway, schedule would be somewhat flexible (wider tolerances), and cost would be the least important with greater tolerances (but still within acceptable limits). This tradeoff matrix is negotiated between development and product management, and it gives the entire team a good idea about relative importance of the constraints. It helps “steer” innovation and design.
Another type of scope constraint is one that often occurs when replacing an existing system. The requirements are often given as “duplicate the existing functionality.” While this may not be the most useful constraint in some circumstances (much functionality may not be used, so it should really be deleted), it is frequently encountered in these projects. Another version of this scope constraint arises when building a product that has direct competition: the constraint may be to duplicate most of the competitor’s functionality before releasing the product.
The bottom line is that constraints provide the delivery team with critical information that helps them be innovative and effective. As such, constraints should be carefully considered because they can guide the team to an effective solution-or when done wrong, to one that is awful. Don’t forget to think carefully about this third point on the Agile Triangle.
