CHAPTER 2: INTEGRATED CUSTOMER
ENGAGEMENT

Aim of this chapter: To raise questions about your Customers: who are they, what their needs and goals are, and how can you work together? We will look at collaboration techniques to deliver their needs efficiently, with minimal waste, and to everyone’s satisfaction. Moreover, we will examine the need to invest in building trust and communication, in order to improve outcomes for both parties.

To be Agile is to adapt when circumstances change, and nothing changes more than your Customers’ needs. The second domain of Agile Business Management is the regular, and ongoing, fulfilment of Customer needs, through a collaborative and Incremental approach. You can achieve this close collaboration by integrating your Customer directly within the work process, granting them co-ownership, as well as co-responsibility, for delivery. Under this collaborative Agile approach, your Customer’s responsibilities include defining, and ordering, the major Requirements, working with the Teams to ensure appropriate outcomes, and undertaking quality control, including final User Acceptance Testing.

Your Customer needs to dedicate time to work with the Team. However, there is no ‘right’ amount of time; it is dependent on the complexity of the Requirements, how close the Requirement is to completion, and the Team’s specific needs at that time. At a minimum, during each Iteration, or for each Requirement, the Customer must be available at the start (to help with planning), the end (to review and sign-off), and as required by the Team. Regularly scheduled weekly, or twice-weekly, timeboxed meetings, encourage a close, collaborative relationship between your Customer and your Team.

There are some drawbacks to this model, including the imposition of additional time from your Customer. If they are not willing to engage with you in an Agile way, either through a lack of interest or availability, it will be difficult for you to maximise your ability to respond to change. Poor communication, lack of subject matter experts, and mismanaged expectations, are all symptoms of a poorly engaged, or inappropriate, Customer.

While some Customers have legitimate reasons, such as regulatory requirements, for wanting traditional engagements models, others reject the Agile engagement model because they don’t understand the overall benefits. Training your Customers in their new role and responsibilities will significantly improve the take-up and effectiveness of Agile processes. If this still fails, there is significant benefit from applying the other Agile Business Management processes, while using traditional Customer engagement strategies.

Customer engagement in an Agile model requires trust, which can be defined across five distinct levels.

1  Team: The highest level of trust where the Customer and organisation share the same goals and outcomes.

2  Identification: Where the Customer has a personal relationship with specific Teams or individuals.

3  Knowledge: Where the Customer bases their trust on personal knowledge and experience with the organisation.

4  Contract: Where the Customer uses legally binding contracts as the mechanism to trust the organisation.

5  Reference: Where third party references form the basis of trust.

Customers who base their trust on references or contracts will initially find Agile difficult to accept. It is easier to be Agile with Customers who have personal experience, and personal trust, with your organisation.

What is a Customer?

How you define your Customer is context specific, but is generally any person, group or organisation that requests, and usually funds, one or more Teams within your company, to deliver a set of Requirements. There are two types of Customers; external and internal.

Directly connected to your organisation, an internal Customer can include senior management, employees, shareholders, external regulators, etc. The Customers for product oriented businesses are generally internal (e.g. a product or design manager), as the customers (little c) of these products are considered consumers, not Customers (big c). Exceptions are for organisations that are engaged directly to develop bespoke products, such as construction or software companies. Services delivered to internal Customers often relate to the operation of business, such as HR or IT support services.

External Customers are not directly related to your organisation, and usually engage your organisation to deliver specific outcomes. In general, service oriented businesses are engaged by external Customers, usually B2B, to deliver on specific Requirements.

The Customer Representative

A Customer can delegate their responsibilities to an individual called the ‘Customer Representative’. Common situations where this occurs are:

•  The Customer is unavailable to fulfil their role.

•  The Customer is a senior executive.

•  There are multiple Customers.

The Customer Representative is an individual who has the authority to represent the Customer, and the Customer’s Requirements, to your Team. From the Team’s perspective, the Customer, and the Customer’s Representative, are synonymous in both authority and responsibility.

For those familiar with Scrum, the Customer Representative is equivalent to the Product Owner.

Requirements and the Requirements Backlog

Now that you know who your Customer, or Customer Representative, is, it is time to start engaging with them on their Requirements. The first step, before the Customer creates any specific Requirements, is to define the vision, or goal, of the end state. This vision shouldn’t be very complex, and can be as simple as a single sentence. For long projects or highly complex Requirements, you can create a simple, low detail, business case, to define the outcomes, non-functional requirements, and value of investing in the work. Because this is Agile, the vision will change as your Customer Requirements change, and it is important to keep the vision up to date, so all Team Members understand what they are working towards.

Once the vision is complete, the key artefact that your Customer is responsible for developing and maintaining, through the life of the work, is the Requirements Backlog. The Requirements Backlog is the ordered list of Requirements needed by the Customer. Given the collaborative nature of Agile, your Customer and Teams should create the Requirements Backlog together.

To minimise later rework, the initial Requirements Backlog should be created in low detail, and describe only the current and best-understood Requirements. The highest priority Requirements, those you will deliver next, are then expanded, with additional detail. Large Requirements that need more than a single Iteration to deliver, can be added to the Requirements Backlog, and later decomposed into smaller, self-contained Requirements. This ensures that the outcomes at the end of an Iteration are always usable, and deliver value to your Customer.

Each Requirement should meet the INVEST characteristics, as defined by Bill Wake¹.

•  Independent: Each Requirement should be as self-contained as possible, with minimal dependencies on any other Requirement. This allows for easy reordering or removal, as Customer Requirement’s change.

•  Negotiable: The Customer can change a Requirement at any time, up to the point it enters the Iteration Backlog (see Chapter 4: Work, the Agile Way).

•  Valuable: Each Requirement should deliver a tangible, and measurable, benefit to the Customer.

•  Estimatable: The definition of each Requirement is such that the Team can estimate it.

•  Small: The estimate, and delivery, of a Requirement, should be within a few days, or a single Iteration.

•  Testable: Each Requirement should have appropriate quality control and quality assurance metrics, so the Customer can validate their Deliverables against the original Requirement.

The Requirements Backlog is the master document that defines the scope and high-level description of each Requirement. As work progresses, and your Customer’s needs evolve, the Customer needs to keep the Requirements Backlog up to date. They can create, remove, change or reorder Requirements at will. Once all the Requirements are Done, and the Requirements Backlog is empty, the Backlog itself should remain, to cater for further changes as required by the Customer.

At a minimum, each Requirement within the Requirements Backlog should contain a User Story, in the following format.

As a [role]

I want a [goal/desire]

So that [benefit]

The [role] is the expected end-user of the Requirement, who is usually different from the Customer. The [goal/desire] of each User Story describes what should be delivered, and the [benefit] provides the context, or the Why.

In addition to the User Story, each high priority Requirement within the Requirements Backlog should contain the following information:

•  Order: How soon should the Team deliver this Requirement? Risk, value and necessity to the Customer all drive the order.

•  Dependencies: Are there any other Requirements that the Team need to deliver first?

•  Additional stakeholders: Does the Team need to engage anyone else during the planning or development phases?

•  Quality control requirements: What are the quality control steps to verify that the Requirement is Done?

•  Effort estimation: What is the Estimate of the effort to develop the Requirement (see section: Effort estimation)? This is the only part of the Requirements Backlog developed by the Team, not the Customer.

Requirements should not require additional information, until they are at the top of the Backlog, and the Team is ready to work on them. If a Requirement is highly complex, and you feel it needs more information, consider splitting it into multiple, smaller Requirements. In addition, only the Team should define specific technical and implementation criteria, and only in the planning phase of delivery (see section: Phases of delivery).

If multiple Teams are working together towards the same outcome, for the same Customer, the Customer should only create, and maintain, one Requirements Backlog. You can dynamically group Requirements using whatever mechanism you need, such as related Requirements, skills, or Deliverables for each Team.

On a regular basis, or between each Iteration, your Customer must keep the Requirements Backlog up to date with their latest Requirements. This ensures that your Teams can meet the Customer’s current needs, and that the next Requirement to be delivered is the most appropriate and useful. As they are Done, or deemed unnecessary, each Requirement should be removed from the Requirements Backlog, to ensure clarity, and reduce the risk of confusion.

By building the Requirements Backlog, Teams will:

•  Reduce uncertainty within the Team when designing Tasks, which in turn reduces the risk to the Customer.

•  Promote regular communication between the Customer and Team, which can also speed up decision making.

•  Ensure that the Requirements integrate with current short-term and long-term goals.

•  Identify required Team Members, which in turn will improve overall financial planning across the lifecycle of the Customer’s Requirements.

•  Ensure that the Team has a comprehensive understanding of the Customer’s Requirements, without getting into too much detail.

For Incremental Delivery, at the beginning of each Iteration, your Team groups the top Requirements from the Requirements Backlog into a new, high-detail, Iteration Backlog. Your Team then decomposes this Iteration Backlog into individual Tasks, and roughly estimates them, to ensure that delivery can occur within the Iteration timeframe. You can find more information on the Iteration Backlog in Chapter 4: Work, the Agile Way.

1 INVEST in Good Stories, and SMART Tasks, Wake, n.d.