No one – in their right mind – will ever say “No!” to Better, Faster and Cheaper. However, the critical questions are: “How does it happen?”, “What does it take to make it happen?” and “Is it real or an illusion?” This talk addresses these three questions.

This is a presentation about the economics and dynamics of Enterprise Agility as a fundamental management philosophy in contrast with traditional management, particularly project management. It is not about IT Agility or agile methods. It is about organizational behaviors and their consequences – and that there are better alternatives. Some of the topics covered are: What does “Agility” mean for the Enterprise? What can you say that’s new about the only things that I really care about: Risk and Value? Why, when we speed up Processes in a Value Stream, does It Never seem to get any Faster? Where did my Time-to-Market go? Why are most of our projects Watermelons (i.e. Green on the Outside, and Red on the Inside)? And, why, when we have incentives for innovation and productivity, do we still rarely get either?

This talk was originally crafted for a C-level+1 executive audience. It has been delivered to such executive audiences in 5 major companies. More broadly, it has been presented in 13 countries on 5 continents to mixed Business and Technology audiences of more than 2500 people, including to the international Agile2016 conference.

The Biblical story of the Tower of Babel teaches us that, as we seek to achieve great and complex things, we often lose our ability to communicate and collaborate with one another. This dyscommunication is commonplace and undermines the very goals that we set out to achieve. What results is a chasm of Biblical proportions separating business strategy, as expressed in slide decks, and IT execution, expressed in stories and tasks in team backlogs. Agile Enterprise, Portfolio and Product Management must effectively span this chasm.

This talk recounts real-world experience in translating Business Strategy into Action for large, complex organizations. It gives practical guidelines and cautions for developing and maintaining a discipline of portfolio and product management within an Enterprise Agile ecosystem. We will discuss: what is a "strategy"; how much hierarchy do you need in a backlog; who is responsible for the different levels of backlog management, and their organization into a flow-oriented rather than authority-oriented structure; how funding and capitalization models intersect with backlog structure and execution cadence; what "KPIs" and other "measurables" are and their role in the eco-system.

Like the weather, everyone talks about Vision but no one seems to do anything about it. Being an effective visionholder is one of the key responsibilities of Product Owners, one they are rarely trained to perform. We think that developing a vision is easy: we show them a simple structured vision template or Product Box and say, “Fill that in!” We don’t usually show them the process, principles and artifacts that help to form that vision, in the first place, and to keep it alive and vital, in the second place.

Vision is rarely simple; it is never simple when it really matters. This talk is about the practicalities of forming, communicating and maintaining Visions for large and complex products and portfolios. The techniques described have been developed to help large agile programs to (a) evaluate the status quo and identify needs against business objectives, (b) conceive and differentiate a Future which satisfies these needs, (c) map the steps necessary to move from the Present to the Future, (d) express and prioritize these steps as epics, features and stories, and (e) establish a rhythm of keeping the vision current and of using it to guide agile planning. This talk is a fast survey of a deep subject. Together, we will explore that strange ground that lies between Today and Tomorrow and find that there are practical ways to find a path from one to the other … and to keep from getting lost.

The Cycle of Portfolio and Product Strategy is: set a Direction; develop Objectives; execute Actions; measure Results; rinse and repeat. It is an experimental process. Metrics and quantitative evaluation are fundamental and essential elements of this Strategic Cycle. And yet, the state-of-the-practice in portfolio and product metrics is very primitive when it comes how to define, measure and properly use metrics to express and validate portfolio and product strategy.

In this talk, we explore the state-of-the-art in portfolio and product metrics for the Strategic Cycle. We explore the concept of Decision-Oriented Teams (DOTs), the Agile Balanced Scorecard model, its relationship to the Strategic Cycle and to the Agile backlog elements that express a strategy. From these models, we develop practical insights which show how we can significantly advance the state-of-the-practice in portfolio and product strategy.

When people think of “Digital”, especially with the capital “D”, they think of smart phones and distracted drivers & diners. When I think of “Digital”, I think of toothpaste.

“Digital!” is today’s “New & Improved!”. Like toothpaste 50 years ago: many people think that “Digital” is just the latest in a series of new flavors … but that it’s still just toothpaste. Oh, but it is not.

Many in Business miss a vital point – and an important opportunity – when they think that Digital Business is just Business using a new technology, i.e. just the same old toothpaste. On the contrary, Digital Business is an essential and vital paradigm shift! What we have learned by working on the front-lines of Digital, Innovation and Lean-Agility with several of the World’s most innovative Digital Banks is: Digital Business is a fundamental reversal of business relationships and work styles. In this talk, we explore this insight and draw some important conclusions.

When we use a benchmark, we are comparing the performance of a thing to some standard. Often, we do this so that we can compare different products. However, when we are benchmarking a team or organization, it is not for comparison’s sake but, instead, to plot a course for their improvement. This is a critical difference.

Any framework for Agile assessment of readiness, maturity or performance must provide diagnostic insight. Insight that can be actioned for improvement of the team or organization. This is a tricky business. An Agile benchmark must both assess practice compliance and orthodoxy, and it must explore values and attitudes that are the source of non-compliance and unorthodoxy.

We have developed several such benchmarks – both simple and sophisticated – and now offer Agile readiness, maturity and performance benchmarking as a service. We can describe and explore several approaches and their pros and their cons.

Agilists are very familiar with Acceptance Criteria, i.e. those statements that specify what “Correct” means and that form the basis for Functional Testing. But then, what are Success Criteria?

Although they are often confused, Acceptance and Success Criteria are quite different. One is developed from the Bottom-Up; the other from the Top-Down. One defines Correctness and Progress; the other defines Good-Enough and Achievement. One is for judging Quality; the other for judging Value.

We have been exploring the nature and use of Success Criteria to represent Business, Portfolio and Product strategies and to formally drive and evaluate these strategies in a Hypothesis-Driven Development (HDD) approach. This work advances the application and practice of Lean Startup’s experimental approach to Business and Product Innovation.

When Data Science analysis and sophisticated Analytics algorithms are mixed with Agile Product Development, there is often a clash of paradigms. Data Science is still more Art than Engineering. While both are inherent iterative, the length of a Data Science iteration often exceeds that of a typical sprint or even a PI. What can be done to “industrialize” Data Science and better mate it with Agile Product Management?

Data Science is, now, where UX and Product development were prior to their leaning and agilization. Data Science is a square peg searching for the right round hole to fit itself into, willing to make changes but not changes which destroy its integrity.

We have been working with a Data & Analytics group at a major international bank. The insights that we received and the adaptations of Agile Product Management and Backlog Management that we have made are fascinating. They shed a great deal of light on the deeper relationship between Traditional and Agile thinking.

When an organization buys fully into Enterprise Agility, they inevitably seek to reorganize along value stream lines. Predictably, they always wrestle with what to do with Shared Services.

Do they keep service provider groups, like Engineering, Marketing, User Experience Design, Data & Analytics and such like, organized as service bureaus, or do they integrate the staff of these groups into the value streams. The former solution threatens time-to-market by long queuing delays. The latter threatens skill development and value transparency when specialists are subordinated within value streams where their creativity and innovation may not be given a voice.

We have worked with several shared services organizations and had to confront this dichotomy. And, we have found a balanced middle ground by applying advanced portfolio management techniques.

The notion of Chapters and Guilds in the Spotify model have become very popular. But, beyond defining the terms, the model doesn’t address some of the fundamental issues of the concepts. For example, where does work of Chapters and Guilds come from? How can we be sure that this work remains relevant to the organization? How do you allocate and prioritize time for Chapter and Guild work versus Development work.

We believe strongly in an ecosystem model of Lean-Agile Portfolio Management. Such models are a well-mapped network of backlogs, functioning as queues. With known sources and sinks of work, we can apply Systems Theory to monitor and manage the flow of work. We have integrated Chapters and Guilds into such ecosystem models and found some interesting answers to the questions of sources, relevance and priority as well as other emergent concerns.

These days, there are fewer and fewer “green field” agile transformations. Most organizations have “done an agile transformation”, sometimes 4 or 5 of them. Ultimately, they either declared victory or defeat. Often, in either case, they do not achieve the benefits of Lean-Agility.

There is a number of well-recognized reasons for such a shortfall of reality versus expectations. For example, adopting practices but not values & principles, changing team practices but not the organizational environment, implementing bottom-up with no top-down buy-in and support, allowing opt-out, and many others.

The challenge that we face is not agile transformation but agile reformation, i.e. how do we restart a stalled agile transformation without falling prey to the same

Most lean-agile teams produce software or other tangible products. These are Product-Oriented Teams operating at the Team level. But, there are other teams operating at the Product/Program, Portfolio and Enterprise levels. These teams do, in fact, produce something valuable. They just don’t produce product directly. They produce decisions.

When we reorient to a Lean-Agile way-of-working Product Management, Portfolio Management, Enterprise Strategy, Compliance and other teams, then we must ask: What do they produce? What is its value? What is contained in the the backlog that they manage? And, what does Done mean? These are Decision-Oriented Teams. And, they are different in a number of ways from Product-Oriented Teams.

We work often at the Product, Portfolio and Enterprise levels. We adapt the teams that work at these levels to Lean-Agile ways-of-working. They often struggle with this discipline. We have come to understand why and to introduce practical techniques for making sense of Lean-Agility at these levels.

“Deep Visibility” is a term that we coined to mean “getting deep insight into a program, product or portfolio using 2nd- and 3rd-order metrics”. 1st-order metrics are simple counts of backlog item types. 2nd-order metrics are counts by state or other field values, simple ratios and trends. 3rd-order metrics are more complex functions on backlog data, often involving multivariable equations and statistical functions.

We find that it is remarkable how much information you can get from a lean-agile backlog with only a few simple changes in the backlog tool and the practices for using it. Examples of such insight are: quality and consistency of estimating behavior, quality and consistency of commitment, build and product quality from several perspectives, overall process efficiency, bottlenecks and other systemic impediments, effectiveness of retrospectives and more, all in addition to traditional lead time and cycle time. The challenge now is to train people on how to interpret and use this information.

For many 1st- and early 2nd-generation agilists, JIRA is perfect. For us 3rd- and 4th-generation agilists, though, JIRA is a crippling set of constraints. With only 2 levels of hierarchy in the basic tool, it is very difficult to real product and portfolio management with out-of-the-box JIRA. This is why the new cPrime adaptation of JIRA is so welcome.

But recently, I saw a configuration of JIRA that does allow complex products and portfolios to be expressed and managed. It is not without its faults, and it does some significant (and not wholly consistent) renaming of issue types and item types. But, it is elegant in its structure … once you understand what’s going on! Since JIRA is so popular, thinking more deeply about how to adapt it to “modern” Enterprise Lean-Agility is an interesting subject to ponder.

In many organizations governance – whether financial, project, risk, compliance, security or other – is the major threat to time-to-market. And, it is a threat that is often accepted as intractable. It is not.

There are agile ways to manage compliance that are better for both parties, the governors and the governed. Ways which transform traditional trailing-edge controls into leading edge and in-flight controls that give better effectiveness, efficiency, manageability and that makes governance a value-added service rather than a cost burden.

We have performed several such refactorings of governance groups. Though, they often have difficulty accepting the concepts and changes. Once they try them, they never go back to their old ways.