BA & SEE EXECUTIVE UPDATE VOL. 20, NO. 8
  

Agile management and delivery practices are becoming a mandatory component of organizations that want to survive the hypercompetitive world of digitally transformed business. Time is precious and so is the capability to handle a continuous stream of innovations and respond quickly to unexpected events.

This holds true especially for fast-value (product) innovation that addresses customer experience and business models. In traditional siloed, command-and-control organizations, these categories of change require complex end-to-end processes traversing organizational functions. Changes in value proposition and customer experience ultimately trigger changes in processes critical to the delivery of value, such as customer engagement, sales, fulfillment, customer operations, and partner relationships. Business model innovation may be even more challenging, affecting strategy and established modus operandi. The capability to systematically execute such changes in an efficient and effective way, at a predictable and sustainable tempo, is what defines true “business agility.”

In this Executive Update, we focus primarily on processes and practices that support business agility from the perspectives of value innovation and product portfolio management. Such agility cannot be achieved merely by announcing Scrum as a mandatory standard for doing any kind of project work. Even if this kind of “standardization” made sense, it would solve only part of the problem: fast delivery of product features.

The end-to-end innovation process starts with ideas that get translated into a backlog of product features and tested in the real market with real clients. Therefore, productivity of the innovation process depends on the quality of initial ideas as much as (or more than) on the proficiency in rushing the backlog through sprints using Scrum or another flavor of Agile.

An integrated approach to coping with these challenges should be maintained and synchronized to form an efficient and effective innovation process that provides three essential capabilities:

1. Delivery of quality ideas. Product teams should consolidate their understanding of the customer journey, personae, and market to systematically review product feature roadmaps and define experiments that test new, promising product concepts, business capabilities, and business models.
    
2. Experiment-based evaluation. Where possible, teams should evaluate new concepts using various kinds of prototyping. Apart from traditional prototyping techniques based on reviewing with user mockups and stripped-down versions of concept implementation, the abundance of data and the processing power that cloud platforms offer opens new experimentation techniques, simulations, or predictive analytics.
    
3. Agile delivery. A quality idea, evaluated through experiments, turns into a set of product features, a process, or a service design. Agile delivery serves the final act of the innovation process: implementation.
    

The Rubicons of Change

Julius Caesar was perceived as relatively harmless to the status quo of the Roman establishment while he was out roaming the provinces. There he proved his military skills as a successful commander respected by the troops. But this capacity, combined with his political aspirations, proved to be a deadly threat to the Republic. Once Caesar had crossed the famous river of Rubicon and made clear his intentions to become a first-league political figure, he forced decisions upon the key players, who had to choose sides and act upon their choices.

We believe the crossing of Rubicon is a useful metaphor in describing the challenge of rolling out an innovation that fundamentally changes the way an organization works. An important (and often fancy) transformational concept successfully tried on a small scale, in some kind of sandbox environment, is to be implemented through a large-scale change effort, engaging many new stakeholders. Achieving truly transform­ative changes means reevaluating skills as well as shifts in priorities, resources, and power. Such a moment uncovers agendas that have remained hidden while the change initiative has been contained and perceived as “one of those ideas” that come and go without much impact on the mainstream of organizational life.

In our Agile management and transformation support practice, we have observed the following “Rubicon decision” moments in the scaling/extension/rollout of Agile (see Figure 1):

• The decision to roll out an enterprise-wide Agile approach after a successful Agile project that has been limited in size and executed by a team of skilled enthusiasts (Scaling Out and Up)
   
• The decision to include external suppliers as partners in Agile delivery through optional scope contracts and transparent budgeting (Building an Agile Delivery Ecosystem)
   
• The decision to empower product owners to manage the backlogs and product features and create integrated business/IT units (Establishing Value Streams)
   
• The decision to change an established project budgeting practice to better reflect the nature of backlogs and value streams (Agile Budgeting, a critical component of Establishing Value Streams)
   

Similar decision points often mark an organization’s evolution from a traditional command-and-control structure running isolated “Agile experiments” at the “provinces” of the enterprise to a consistently Agile business.

From Grassroots Initiatives to Agile Launch Pad

Almost every organization has some room for grassroots Agile initiatives; projects for which no mandatory process has been defined or organizational units where managers are less interested in how their teams work than in whether they deliver expected results.

Launching an experiment with an Agile delivery process is therefore relatively simple. It takes a project, a team motivated to try (or demonstrate) how an Agile approach works, and a project sponsor willing either to play the role of product owner or to appoint one. Such a project does not really challenge the status quo; its results are uncertain, so even naysayers tolerate it.

Turning grassroots initiatives into an Agile launchpad is often the first conscious step, albeit a relatively simple one, in implementing business agility. The (usually informal) leaders of grassroots initiatives need to be persuaded to turn their group effort into a controlled experiment and to agree with group mem­bers on the scope and goals to be used as proof of process viability (e.g., performance, quality, or user acceptance). For grassroots teams, such an invitation — if made with respect — is appreciated as an acknowledgement of their contribution to the organization’s success.

Challenges

1. What’s in it for me. Grassroots teams do “their thing” for their own reasons — usually related to a spirit of professionalism, self-improvement, and sense of ownership of the process. While institutionalization of a grassroots initiative gives its members visibility and potentially also recognition, it takes away some of the ownership.
    
2. Conflicting goals. The experimental project has two sets of goals and two scopes. One relates to the product being delivered, the other to the process being used. These goals must be carefully aligned.
    

Crossing Safely

The experiment may be a totally “grassroots” initiative, owned only by the project team, yet to become a useful launching pad for subsequent rollout it needs to become a “controlled experiment” owned by some part of the organization (e.g., IT or a business unit) with the intention to evaluate its results and take further action upon them.

Scaling Out and Up

The first moment of truth revealing an organization’s commitment to agility relates to the decision to roll out an Agile approach after a “successful trial”: a real-life project, usually limited in size, that has been executed by a team of skilled enthusiasts.

Challenges

1. Too small to fly. Some Agile initiatives may seem to have it all — a committed business product owner, a skilled team, a successful conclusion — but their goals and scope do not convince people of their worth. These projects are perceived as too meaningless to treat them as a reference for change in mainstream project work.
    
2. Splendid isolation. Grassroots initiatives start in IT and do not involve “real” product owners from business units. Instead, one can find various “product owner proxies” (e.g., a business domain expert from IT who plays the role of product owner). Such isolation eliminates the need to negotiate difficult management issues such as the business’s responsibility for and commitment to the project value delivered. The price organizations often pay is a focus on the delivery of features instead of on fulfilling the most important of Agile promises: optimized business value of sprints.
    
3. Clash of the titans. Sometimes grassroots initiatives expand (mostly in the IT world) even when nobody is willing to take ownership for the “up-scaling” decision. Such a situation is relatively rare but may happen in large organizations that employ large development teams. We’ve seen recent movement to recreate software development capabilities in banks, telecoms, and even public institutions. People hired to work for or manage such internal software houses often bring with them an Agile culture. This leads to culture clashes, which may result in scaling Agile practices so that business units embrace them (this usually requires a strong business — preferably C-level — champion of Agile).
    

Crossing Safely

The first important step is to embrace any grassroots activities and turn them into a controlled experiment that demonstrates the viability of key Agile promises: delivering more business value faster and eliminating project work not focused on delivering this value as an unnecessary complication and waste of resources. At the same time, it is important to transparently monitor and address the risks often brought forward by “naysayers,” such as lack of design, maintainability issues related to scarce documentation, or unreliable performance estimates.

The basic engine of Agile transformation is the systematic introduction and ongoing improvement of practices, such as those related to Scrum, at the project team level. This type of transformation, however, must be supported by management involvement in challenging the barriers that organizations discover when attempting the implementation of such concepts as empowerment, business responsibility for project success, transparency, self-organization, a no-blame culture, or experimentation.

To cope with these very real — and often very difficult — challenges, we encourage readers to use practices borrowed from the ADAPT framework defined by Mike Cohn in his excellent book Succeeding with Agile. ADAPT promotes relatively straightforward initiatives, which may create a holistic effect supporting the effective large-scale adoption of Agile:

• Build awareness about the value proposition of Agile and its relevance to key business goals and challenges. This can be achieved through workshops, small group briefings, and seminars.
   
• Motivate key leaders and teams to use Agile as a tool to solve specific problems that have become built into the status quo. These include such problems as uncompetitive time to market or low business satisfaction with project results. A true desire to change the status quo is an important ingredient of leadership.
   
• Build the “ability to execute,” which goes beyond elite teams and champions and requires a blend of methods and techniques. Formal training is important but must be complemented by coaching and mentoring by experienced practitioners and communities of practice.
   
• Promote results by implementing and improving Agile practices. This will help build a critical mass of people who support the adoption of Agile in new projects and business areas.
   
• Transfer skills and practices. This does not mean that successful teams should be dismantled and used as “seed knowledge capital” in new projects. On the contrary, as Cutter Consortium Fellow and Peopleware coauthor Tom DeMarco has often noted, a “jelled team” is a precious asset, capable of record productivity. But the members of such champion teams are very likely willing to coach and mentor colleagues either through short time involvement (e.g., participating in some sprints) or by systematic knowledge sharing through guilds and similar horizontal structures. This helps to transfer proven practices and, over time, to turn these practices into de facto standards.
   

Finally, the Agile transformation of a command-and-control organization is in itself a complex effort, so it makes complete sense to adopt Agile principles for this very effort. At a minimum, this should mean a shared vision of the organization (a “better us”); an iterative, roadmap-driven approach to change; and conscious, controlled experimentation with new practices. This approach helps an organization learn and allows its own “Agile way of life” to emerge from experiment after experiment.

Agile Delivery Ecosystem

For decades, the commercial relationships between companies that provided software development services and their clients have been shaped by either fixed-price/fixed-scope or time-and-materials types of contracts. The former emphasizes the contractor’s responsibility to deliver the agreed-upon solution within the agreed time and budget. The second type is a vehicle for acquiring skills and manpower where it is the buyer’s responsibility to employ them efficiently and effectively. The drawbacks of both approaches have long been evident, but, nevertheless, both sides have learned to use them to protect their own interests.

Companies often use both schemes as legal vehicles to experiment with Agile processes. Fixed-price/fixed-scope contracts require a creative approach to contract management so that scope changes are not misused as painful and expensive change-request opportunities, and the service provider is not penalized for any unrealized backlog. On the other hand, time-and-materials contracts require trust that the vendor will transparently and adequately perform its effort calculation for backlog items and will not use the backlog as an opportunity to increase its margins. This kind of trust and mutual understanding can exist with select trusted suppliers (and, equally, with trusted customers), but building an Agile ecosystem is a different story. An Agile ecosystem requires the creation of a systemic setup that works with the market, not just selected vendors. This is why we believe it is a Rubicon decision point.

Challenges

1. Supplier shakedown. Not every vendor has the capabilities to provide services using Agile processes. And it is not just the process skills. The economics of fixed-price contracts are often used by competent vendors to generate margins through economies of scale and cost management on the delivery side. As long as the price/quality remain competitive and delivery does not suffer, there is nothing ethically wrong with the arrangement; in fact, this capability is often based on good organizational, domain experience, and/or mature reuse practices. More frequently used are optional scope agreements — attributed to Cutter Consortium Senior Consultant Kent Beck, and widely accepted as a model for Agile project contracts — which imply a lot of transparency related to estimations and team composition. The vendor cannot use its structural capital and knowledge and is often forced to compete on the basis of a team “blended rate.” This type of contract benefits small shops or outsourcing companies and puts companies with developed structural capital at a disadvantage, eventually leading to a rapid, radical change in the supplier portfolio. This may or may not be a benefit for the organization, so this effect should be carefully managed.
    
2. Legal affairs. The framework contracts and standards for services/solution procurement are most likely aligned with the fixed-price/fixed-scope or time-and-materials approaches. They are also most likely driven by risk aversion as far as scope management is concerned, which will inhibit the adoption of optional scope agreements for contracting services based on an Agile approach.
    
3. Unfixing the scope. A challenge for decision makers is to avoid a deeply rooted, fixed-scope mentality. It resurfaces often in situations where a decision maker, even an Agile-friendly one, who has not been involved in the project on a daily basis, faces a situation where the results of an Agile project diverge from the original vision. The real question is whether this departure from the original scope has been conscious and well managed by an empowered product owner. If so, then most likely the expectations at the inception of the project were unrealistic or simply wrong, and the Agile process has helped the team discover the wrong expectations and adjust them. But some decision makers tend to perceive such a situation as a failure to “keep a project on track” and thus develop a lack of trust toward the supposedly empowered product owner, undermining his or her authority.
    

Crossing Safely

Developing an effective Agile development ecosystem may be much easier if you get the understanding and support of procurement managers and company lawyers. So if you think that the legal and procure­ment departments are the least likely allies for an Agile evolution, now is the time to rethink this stereotype. Optional scope contract schemes, the most advantageous for Agile projects, should create room for flexi­bility and experimentation. This purpose is rarely served well by 100-page framework agreements that focus parties on avoiding risks instead of on delivering value and experimenting. If there is no room for trust and a bona fide approach to vendors (and vice versa), there is probably very little room for Agile cooperation. Legal departments are instrumental in determining what the right legal tools are for the job and must share responsibility for achieving the goals of transformation.

Optional scope as often practiced today defines the general terms for work performed in short increments (ranging from a single sprint to three months). The terms usually include team composition, quality criteria, and agreed procedures for team, budget, and backlog management. This allows for reasonable scope flexibility within each increment.

An Agile-friendly legal setup balances the risks on the client side (the client can have clear expectations related to near-term project results) and on the supplier side (the supplier has clear near-term obligations but does not take the risk of estimating a budget for an unclear scope). An additional risk for both sides is that the supplier may not be contracted for the following increments, but it seems that mitigation of this risk is relatively simple. The client should build a portfolio of suppliers for specific domains (a master supplier and a challenger seem to be the minimum) and treat suppliers in a fair way. Suppliers are likewise motivated to treat clients fairly because those who seek long-term engagements (which are usually more profitable due to lower sales and transaction costs) have good reasons to provide customers with rational estimates, reliable delivery of valuable results, and better-than-average productivity.

We note here that fixed-price contract practices may also be used effectively in Agile projects. These are a suboptimal solution, but they might work if the scope change management procedures are not overly complicated (e.g., do not require rewriting the contracts). A reasonably simple, transparent, and reliable practice of measuring the size and effort of scope changes is a valuable tool, as are risk budgets that can be used to embrace more substantial changes without contract renegotiation.

A similar condition applies to time-and-materials contracts. They can be used quite easily as a legal solution for Agile projects with the acknowledgment that, as the client faces all the scope management risks, time-and-materials contracts should be used primarily with known, trusted suppliers. In such cases, the flexibility afforded to build truly interdisciplinary teams by mixing just the right pool of skills and talents from both the suppliers’ and the client’s sides may be unparalleled.

Value Streams

Value streams are business architecture patterns essential for business agility. They require a governance model that radically departs from that common in command-and-control organizations and moves toward a model with decentralized yet efficiently coordinated business units integrating decision and operational processes. In addition, this governance model should integrate product innovation with business develop­­ment and operations and effectively dismantle organizational silos. The rationale is that, in hypercompetitive markets, the efficiency of horizontal processes (e.g., turning a new product idea into a well-performing marketable product) has more impact on overall business performance than does the functional efficiency of silos. (We discuss Agile budgeting, a critical component of a mature value stream architecture, below.)

The innovation process is best executed in teams that share responsibility for business results and innovation efficiency. “Value stream–oriented” governance is often typical for “pure digital” companies (businesses that have digital product offerings and fully digitized key business processes). Value streams integrate business domain and technology specialists and are granted autonomy and the responsibility for a part of the company product portfolio.¹

As we see it, the value stream Rubicon is the most important one to be crossed in the Agile transformation journey. It is also the step that potentially delivers the most business value.

Challenges

1. Tear down the walls. IT is far from the only silo in the organization. Integrating functions such as sales, marketing, and customer support into single units responsible for the business results of the product portfolio is even more difficult than integrating IT and non-IT functions.
    
2. Leadership deficit. Value streams can only be successful when managed by people with specific leadership qualities, such as those who build their authority through empowerment and collaborative practices. Such qualities are often hard to find in command-and-control organizations, especially those that have been internally very competitive. Internal competition is a killer of Agile culture.
    
3. Building the commons. Decentralization makes it much harder to share resources across value streams and create economies of scale even in relatively simple processes. In a way, value streams become “new silos” — only this time these silos are directly responsible for the organization’s market success.
    
4. Time for governance. The role of top executives changes; as the value streams become proficient in business development and operations, the executive jobs will become similar to those of the manage­ment of a holding company consisting of independent businesses. Top executives need to focus on governance, leadership development, and strategic issues (e.g., M&A strategy), and much less on command and control. This change in focus may represent a significant problem for some senior executives.
    

Crossing Safely

A good start is to expand project teams to include skills and perspectives other than the strictly technical or managerial (e.g., product marketing, business development, operations). Making such setups a habit is a good start toward value streams even in traditional siloed organizations.

Aggregate functional responsibilities at the board level so that senior executives take responsibility for business areas covering all the primary required functions, such as product marketing, sales, and customer support. An example might be the appointment of executives responsible for markets with distinctive client and/or product portfolios. This does not exclude responsibility for the broadest functions, such as strategic/brand marketing or financial management. But functions specific to product/client lifecycles can very well be assigned to single executives and in this process tailored to product/client specifics.

It is important to complement value streams with “horizontal” structures that deal with processes and assets that perform better when shared across value streams. We find a growing number of initiatives implementing such a business architecture in digital media, banking, and telecommunications. Such horizontal structures include:

• Collaborative business planning and review rituals supported by management information benchmarks (internal and external) and reporting platforms
   
• Practices that enable voluntary remixing of existing teams so that people learn new skills and discover and institutionalize important tacit knowledge and new practices (e.g., “squadification” — the practice of getting work done through small, self-organizing, multidisciplinary teams)
   
• Informal horizontal structures covering common issues, such as brand management, common digital platforms and components, skills development, recruitment
   

Agile Budgeting in Value Streams

Agile budgeting contributes to the successful implementation of a value stream–based architecture. The established project budgeting practice is founded on two cornerstones: investment accounting and portfolio management. Investment accounting takes care of CAPEX allocations so that capital is efficiently allocated to projects that offer the best mix of return indicators. Portfolio management takes care of priorities, strategic alignment, and risk management of the company resources (beyond capital). As portfolios are managed by high-level executives, the projects within them tend to be rather complex and long.

From this perspective, a project is born when the plan and associated performance indicators are accepted, and finishes when the final product is delivered, at which point the depreciation of invested assets starts and the project dissolves into the OPEX component. Poor project performance is mostly recognized only through the delays and scope changes that affect cash flows. Product performance is usually disconnected from project performance.

Agile budgeting in the value streams is different. It is about products, rather than projects, forming the value stream portfolio. A product can already exist and generate value or can be an innovative idea that may turn into a component of the value stream portfolio. In the first case, the product has some kind of revenue stream, operational costs, and (it is hoped) profit margins contributing to cash generation. The product (or portfolio of products) also has a backlog of changes that affect its market performance and operational efficiency. Such a backlog can include important activities, such as refactoring, that are often very difficult to justify in traditional budgeting practices. A value stream perspective offers much better judgment concerning the value of such backlog items.

If the product does not exist (e.g., an innovative idea), it will most likely be built as a “minimum viable product” by some part of the existing product team. It will then be included in the portfolio and developed through the process of validated learning, based on market feedback. Generally, instead of managing a large, long, complex project, the organization distributes the work into significantly smaller chunks (“epics” and “scrums”), delivering product-related backlogs.

Thus, it seems to make much more sense to replace project budgets with a product development budget, representing a portion of value stream operational expenditures and serving as financial capacity to be used to meet the business goals of the value stream. The job of senior management changes; instead of taking decisions on large, obscure projects represented mostly by high-level goals and financial indicators, they need to focus on managing value stream performance and empowering their leadership teams to manage product development budgets efficiently. The projects that remain are the ones that truly benefit from a C-level perspective: strategy management, company acquisitions, territorial expansions, creation of new value streams, and R&D investments.

Challenges

It is important to understand that OPEX/CAPEX-related indicators are an established way for investors to assess company performance. For example, infrastructure-based businesses, such as communications service providers, have better valuation when their OPEX ratios are low, and CAPEX levels demonstrate their ability to innovate and keep their infrastructure in line with growing demand and quality expectations. Agile budgeting tends to increase OPEX by allocating to OPEX a (potentially substantial) part of project costs, which would in other circumstances become CAPEX. In the long term, OPEX should normalize, as less capital will be depreciated in future. But initially the change in budgeting approach may create a hard bump in investor relations; one that represents another important Rubicon to be crossed.

Crossing Safely

Certainly the change in budgeting must be very well communicated to the stakeholders before it is executed. It may be a wise move to invest some additional effort to run double accounting for a limited time and to demonstrate the evolution of company performance using both the old and the new perspectives.

In no way should the product budget allocation be viewed as “money spent.” The actual allocation of resources should strictly follow the business results of the value stream, so rolling forecasts and fast access to performance information are important prerequisites.

The practice of Agile budgeting is rooted in the competences of the product owners. Developing their business management skills provides a good basis for the implementation of Agile budgeting practices in a way that minimizes risks for the organization.

An interesting example may be how northern European banks, such as DNB, implemented Beyond Budgeting practices — one of the first holistic concepts of an Agile business architecture. Apart from replacing formal hierarchies with distributed, networked, collaborative teams, the new approach advocated abandoning fixed annual budgets in favor of rolling, relative performance goals based on internal and external performance benchmarks, with resources allocated on demand. As a result, reporting practices depart significantly from the standards to which stakeholders are accustomed, so pioneering financial institutions had to invest significant time and effort in educating stakeholders about the goals and means until the long-term benefits could be appreciated firsthand.

Summary

Agile transformation often starts as a grassroots experiment of “doers” but cannot deliver the most valu­able results — increased business agility — without involving company management to face some bold deci­sions. We invite you to view the “Rubicon decisions” described in this Update as generic milestones on an Agile transformation roadmap. This roadmap is advanced by increasing the scale of Agile practices, experimenting with various aspects of Agile processes and the components of Agile’s cultural background, and refactoring the business architecture around successfully established Agile practices and business capabilities.

For sizable organizations with a long command-and-control tradition and well-optimized operations, this is no easy task. Some attempt it by greenfield initiatives — building the new organization in parallel with the existing one. Some embark on the road of internal change. There is no single proven recipe for success, but understanding the key Rubicon decisions supports an honest, risk-aware approach to the process. We believe that this kind of integrity is the cornerstone on which Agile transformation success becomes more probable. Integrity and “walking” the talk are essential in the process of transformational change.