What is agile product delivery?

According to Scaled Agile, agile product delivery is a “customer-centric approach to defining, building, and releasing a continuous flow of valuable products and services to customers and users”.

Agile product delivery forms a core part of agile project delivery. Each project is delivering a particular product and this is concerned about delivering innovative products and services with the right solutions at the right time.

The mechanics within each product delivery add up to determine the overall project outcome. Therefore, the design of agile product delivery practices is absolutely crucial in achieving overall project goals. Let’s now examine some of these practices in detail.

Customer centricity vs project centricity

In agile methodology the end customer is the number one focus. In various organisations ‘customer’ may be used for various internal stakeholder groups. Yes, often projects may be delivering solutions that are only benefiting internal employee groups. However, the end goal for agile is focused on the end external customer.

This means, whatever solutions or benefits that the project is bringing to the internal stakeholder group, ideally these would support the organisation’s work in benefiting the end customer. In all aspects of prioritisation and discussions of solution design, the focus must always be on the end customer.

The role of the change manager in customer-centricity is to plan out and execute on the change process according to what supports the end customer. If the change has a direct impact on the customer this means engaging the customer (as needed through marketing groups). And if the impact is more on internal stakeholders, thinking still needs to be applied to facilitate the engagement, readiness, and adoption of the change so as to benefit the end customer.

Even when you’re working on internal stakeholders, being customer-centric means:

Putting yourself into the customers’ shoes – Using customer insights and data to inform insights
Focusing on the whole product vs individual features – Taking a holistic view of what is in the interest of customers, the design of the overall change should take into account how customers interact with the overall service or product
Designing change to the customer lifetime value – Most organisations would have a mapping of the value delivered to the customer across different phases across time.

Develop on cadence in agile change management

Agile teams have ongoing, structured routines that help them develop solutions on a regular basis. Within each iteration (a standard, fixed timebox where the team delivers incremental value) the team aims to deliver according to plan.

The Change Manager needs to understand the broader plan and milestones of key outcomes delivered by the project, as well as when each iteration will occur. From this project plan, a clear change plan detailing the overall approach in engaging stakeholders based on what will be delivered and the frequency and nature of communication should be formed.

Careful attention needs to be placed on setting the expectation with stakeholders on the readiness of developed solutions. A lot of stakeholders may not be comfortable with how fast solutions may be iterated and that the solution outcome may not be known until, often, closer to the release date. Addressing the stakeholder expectations of release cadence is critical to ensure that there is no misalignment.

Program Increments (PIs) informed the larger timebox of what will be delivered, whilst each iteration delivers a smaller set of solutions. From a stakeholder engagement perspective, there needs to be a balance of painting a clear overall story of what will be delivered within the overall PI, balanced by particular details contained within each iteration.

Working in program increments

To add value as a change manager across a program increment it is critical that you examine the overall program as a whole system. Across the work of each agile team and each iteration, the overall program solution starts to take shape. Your job is to interpret what this means to stakeholders and decipher this into engagement and readiness activities.

Sequencing and planning

The schedule of agile releases is mainly determined based on agile team resourcing and delivery deadlines.

Throughout the iterations, how do the release timings impact stakeholders against their existing business-as-usual demands as well as potential releases from other projects? This is a key contribution of the Change Manager in ensuring that change impact release plans are optimised from the perspective of the receiving business. How frequently should communication updates be undertaken for various stakeholder groups given the pace of the releases? Again, the design of this forms a critical part of the overall change plan.

Change delivery also forms a central part of agile team delivery. Change deliverables are often dependent on other agile team members. For example, to deliver change impact assessment you need the finalised solution to be defined by the Business Analyst. In order to deliver the right level of communication briefing to business stakeholders, you need to set the expectation of the timing and minimum information required.

Program Increment planning from Scaled Agile

Overall vision and narrative

Is there a clear overall vision and narrative from which individual release communications can build on top of? It’s critical to paint a clear picture of what the end state looks like without the nuances of the mechanics of the solution (as these will not be known at the beginning of the program).

Release on demand

Release on demand is a practice and a process whereby new functionality is deployed as needed based on stakeholder needs. Depending on the change impact of the feature the change manager needs to be ready to send communications and updates as needed, sometimes within a short notice period.

Note that not all releases necessarily require communications for users. And depending on the type of change being released different formats of communication may be leveraged. For example, system changes may benefit from within-app notifications versus emails or other forms of update.

Communications and engagement may also be bundled as necessary to provide a packet of updates to stakeholder groups versus constant and continuous updates. The change manager needs to examine the nature of change impacts and stakeholder needs to determine the right tactic to be used.

Release design

Change impact sizing and design is a critical role taken by the change manager. From change impact assessment, the change manager needs to consider the impact of the overall size of the change impact from a business stakeholder perspective. Where possible, a packet of change may need to be de-scoped to be broken into smaller pieces of change if this is going to be easier for adoption in consultation with stakeholders. On the other hand, many changes may also be bundled together into a larger change release, again based on optimal stakeholder adoption considerations. This form a critical part of lean flow design.

Bugs in agile change management

The change manager has a role to play in setting expectations with stakeholders that with agile system releases that go fast and constant, that there should be an expectation that bugs are probably unavoidable. Ensure that users are clear in terms of how to highlight bugs and how they will be kept in the loop as each bug is addressed.

On the other hand, bugs may be so disruptive that an effective roll-back approach must be in place in case the change did not land well. Effective communication content and processes need to be in place to manage this risk. This is a critical part of ongoing agile change management.

BAU integration

With frequent releases, care needs to be given to how the change will be adopted and embedded within the impacted business as a part of business-as-usual. For smaller changes, this may not be critical but for larger change impacts the change manager needs to weave each change into a coherent, overall change approach that includes post-release adoption strategies. This includes embedding roles and responsibilities, tracking, and reporting mechanisms.

Automation in agile change management

A part of agile is about delivering fast as frequently as possible. To support this automation of any part of the development process is encouraged where possible. For the change manager, various digital tools should be leveraged to support the continuous deployment. This includes scheduled digital communication, tracking of audience responses, knowledge article views, and digital versions of the single view of change.

Dashboard example from The Change Compass

Measurement in agile change management

Measurement is a critical part of agile change management. Without the right metrics to indicate how the change is progressing it is difficult to know if the trajectory is heading in the right direction towards the end state. A clear set of measurements needs to be in place to measure constant, and continuous change releases.

To read more on measuring change visit our Ultimate Guide to Measuring Change.

To read more on agile change management visit The Ultimate Guide to Agile for Change Managers.

Chat to us to find out more