How to Govern Agile Development

How do you do this for the agile development of digital products? Do you fear that doing so will stifle your digital innovation?

You may be surprised to know there is a phase-gate method that does not interfere with the benefits and objectives of the agile approach.

The most important thing you must do to succeed with phase-gate is to use it to make decisions (governance) and manage and reduce risk, not to manage a project. Use it to ensure that relevant parts of your company (stakeholders, business leaders, and functions such as marketing, sales, distribution, operations, and manufacturing) are aligned regarding assumptions and expectations. 

Use it to establish the rationale to invest, increase stakeholder communication, and prevent surprises.

Do not use it to run your project.

A Gated Approach to Governance

To make gated governance successful for digital innovation, remember that the essential part of phase-gate is the gate, not the phase. Phases describe and elicit deliverables that are necessary to make business decisions. Gates are events where a select group of (often cross- functional) people make business decisions. The word deliverable represents something delivered to the gate (specifically to the decision makers, known as gatekeepers) rather than work to be done.

Let’s look at a process model that uses phase-gate to enhance and add value to the development of digital products. The model contains phases that do not interfere with or control the work of the digital teams. The gates are designed to add value to the digital teams.

The model consists of these gates:

• Decision to fund development
• MVP review and reconfirmation
• Decision to launch
• Product review and strategic adjustment

Note that the word gate is not used. The term “gate” can work against adoption if it connotates (as it often does) friction for the agile culture. In the phase-gate definition, gates are the points where decisions are made. If the word goes against your organization’s culture, call them decision points and review points (the model has both).

For each of the gates in the model, consider its purpose, who needs to be involved, what needs to be understood, what inputs are required, and what outcomes will be achieved. The inputs are the deliverables to the gate, and they should be clearly labeled as to their intent. They should have structures and templates behind them that bring value (not friction) to the teams who need to create them, thereby reducing time and churn in preparation. There should not be too many of them.

Decision to Fund Development

Product development begins with a decision to invest. No company commissions a team to start working without understanding and evaluating the strategic fit, the objectives to be accomplished, the (phased) investment required, the timing expected, and the value expected with the projected outcome. The investment decision is made by a group of leaders who approve the initiative and allocate the resources. This decision point is fundamentally a gate review and decision.

Components of this gate:

• Purpose
  • Commit resources to developing the MVP
• Who
  • Technology (CTO, head of software engineering)
  •  Finance
  • Resource owners
  • Sales (if the product is sold with a sales organization)
  • Marketing
  • Customer Success
• Need to understand
  • Personas, Product Strategy, North Star
  • Strategic fit
  • Objectives
  • Investment required
  • Value expected
  • Cross-functional needs and expectations
• Inputs (deliverables)
  • Product vision, concept, definition, validation, rationale
  • Product Strategy Canvas
  • Market and competitive positioning
  • Proposed success metrics
  • Resource plan (how many teams, how big)
  • Risks
• Outcomes
  • Decision: Go, Recycle, Kill, Hold
  • Resources (funds, people)
  • Timing of MVP review and reconfirmation meetings

To decide to invest, the vision and objectives for the product must be defined, discussed, and agreed upon. Market needs, including how the product will be brought to market, need to be understood. The amount and cost of resources required must be defined, understood, and approved. Risks must be understood.

Make these deliverables brief.

The definition of the Minimal Viable (MVP) must be understood and agreed upon, along with understanding what happens after the MVP is created and in the market. Use a canvas for product and persona definition rather than an extensive product definition document for this purpose. Focus on your North Star. Emphasize the why as opposed to the features and functions.

If your company has a sales organization, they should be included in the discussion even if they will not generate revenue for the product. If a PLG (product-led growth) approach is to be used for the new product and the company has traditionally had an SLG (sales-led growth) business model, the sales organization will need to understand this. If the model is SLG, sales must agree to the expectations that will be put on them.

Critical in this first funding gate is a clear understanding of the MVP and a recognition that its definition might (likely will) change as the agile work proceeds, for this is what agile is all about. This can be a change for companies historically using phase-gate, which must be understood. Remind your gatekeepers that change is normal, especially for those new to agile development.

MVP Review and Reconfirmation

Things change. The point of an MVP is to test and validate assumptions about customer desirability, technical feasibility, and business viability. As such, its definition will likely change during creation. It is not uncommon to complete the MVP only to have those who approved the investment be completely surprised at what has been developed and, perhaps, disagree with the resulting MVP that has been created. Preventing such surprises and disagreements is a significant benefit of product review and reconfirmation gates. These gates prevent “this is not what I agreed when I committed the funds/resources” types of reactions.

Components of this gate (meeting):

• Purpose
  • Communicate status and change
• Who
  • Major stakeholders, same as for the previous gate
• Need to understand
  • What’s changed!
  • Product
  • Market
  • Target
• Inputs (deliverables)
  • Updated Product vision, concept, definition, validation, rationale
  • Product demo
• Outcomes
  • Understanding

The purpose of this “gate” (meeting) is to understand change. It is not a gate in the traditional sense because it does not have a decision. It is a review meeting to understand product changes and to ask questions.

Your development team sets this meeting’s timings, which should have been proposed, discussed, and agreed upon in the “decision to fund development” gate meeting. You should have at least one. Additional product review and confirmation gates may also be set, especially for high-risk efforts (e.g., complex systems with hardware and software). These should be discussed and confirmed in the “decision to fund development” gate meeting.

Your development team must be able to change the timing of, add additional, or remove extra previously planned review and reconfirmation meetings as they learn more. Don’t just have a review and reconfirmation meeting because you thought you would need one when creating your MVP. Things change.

Deliverables to this gate include an update of the MVP definition, a review/reconfirmation of the market and target personas, a review/reconfirmation of the expected market value, an updated assessment of risks, and a restatement of cross-function and assumptions and expectations. Fundamentally, this gate is used to reset expectations and to seek alignment for continued development. Understanding what has changed based on iterative learning cycles and customer feedback, and why it has changed, is essential and core to the cross-functional discussion in this meeting.

This event is not a go/no-go gate. The decision should be to continue (document that as a “go” if you like). Some might also be tempted to include decisions such as increasing investment, decreasing investment, pivoting to something else, or killing or putting the initiative on hold. Do not do this. Because things are still in the MVP phase, it is very likely too early to make these decisions.

Decision to Launch

A major mistake many companies make is to over-focus on the product and under-focus on everything else that needs to be in place to launch the product. A good governance process ensures that everything beyond the MVP is in place and understood before launch.

Deliverables to this gate enable gatekeepers to be confident that pricing, training, sales enablement, and customer success plans are in place. These deliverables require effort to create and cause organizational churn if they are not considered beforehand. A good approach here, alongside product engineering activity, streamlines organizational performance.

Components of this gate:

• Purpose
  • Commit resources to launch
  • Commit resources to continue product development
• Who
  • Major stakeholders, same as for the previous gates
• Need to understand
  • Pricing
  • Customer success plan
  • Internal training requirements
  • Sales Enablement approach (if needed)
  • Revenue expectations
  • Cross-functional assumptions
  • Go forward resource needs
• Inputs (deliverables)
  • Marketing plan
  • Training plan
  • Release plan
  • Staffing plan
  • Product measurement KPIs
• Outcomes
  • Decision: Go, Recycle, Hold
  • Future product development approach and resources committed
  • Timing of Product Review and Strategic Adjustment (continuous delivery) gates
  • Lessons learned and process adjustments to make the process better

This gate should review and establish deliverables and metrics that define what is needed post- MVP launch. How much resource is required, and for how long? How often will future releases be made? What are the essential product KPIs that are to be monitored? How will the organization assess success, and how will it be reported? Who are the stakeholders from this point onward, and what communication will be delivered to them (and how)? Make sure you answer these questions in this gate meeting.

Product Review and Strategic Adjustment Gates

Once an MVP is launched, the work does not stop. It’s only the MVP or first release. It is hopefully only the beginning of the life of the product. Continued product governance is essential to understand product success, guide future product direction, and marshal the company around the product. You should create recurring meetings on a cadence to review the product and set future investments. Gate decisions here include continue, pivot, end of life, reduce investment, and increase investment.

Components of this gate:

• Purpose
  • Understand product performance
  • Guide product direction and future investment
• Who
  • Customer success
  • Technology (CTO, head of software engineering)
  • Product stakeholders
  • Resource owners
  • Marketing
• Need to understand
  • Product KPIs
  • Market / competitive changes
  • Resource plan
• Inputs (deliverables)
  • Product health and KPI report
  • Updated Market and competitive positioning
  • Proposed success metrics
  • Updated Resource plan
• Outcomes
  • Decision: Continue, Increase Investment, Decrease Investment, Pivot, Exit
  • Next meeting date

Deliverables to the gate include a review of market and competitive changes, an update on product KPIs and market performance, and a recommendation for continued funding and changes to any KPIs.

Multiple “product review and strategic adjustment” gates support a continuous delivery business model. These gates could be on a fixed schedule (e.g., every three months), an event schedule (based on key market events), or an ad-hoc schedule. Agree on the cadence of these gates during the previous “decision to launch” gate.

Do not treat these as gates to be “passed,” as with a traditional phase-gate approach. Instead, use them to solicit discussion around product performance and fit with company strategy and to make decisions such as continuing with the product, increasing or decreasing investment, pivoting, exiting, or creating something else as appropriate.

Does your company have high confidence in and have given high authority and autonomy to your agile project team leaders? If so, consider moving these gates away from executive cross- functional leaders and instead putting them in the project team. In this approach, move executive-level governance that focuses on the merit of continuing a product into your portfolio management activity.

Whether the product is released in fixed increments (e.g., once per quarter) or continual integration with no formal releases, continuous delivery gates should be implemented. If desired, these can match the timing for fixed increments, but this is not advised. The purpose of the “Product Review and Strategic Adjustment” gate is to review product performance, not to approve a product’s incremental release.