How to Use the Agile Principles of Customer Satisfaction in Your Project
Agile approaches focus on customer satisfaction, which makes sense. After all, the customer is the reason for developing the product in the first place.
While all 12 principles support the goal of satisfying customers, principles 1, 2, 3, and 4 stand out for us:
(1) Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
(2) Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
(3) Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
(4) Business people and developers must work together daily throughout the project.
You may define the customer on a project in a number of ways:
- In project management terms, the customer is the person or group paying for the project.
- In some organizations, the customer may be a client, external to the organization.
- In other organizations, the customer may be a project stakeholder or stakeholders in the organization.
- The person who ends up using the product is also a customer.
How do you enact these principles? Simply do the following:
- Agile project teams include a product owner, a person who is responsible for ensuring translation of what the customer wants into product requirements.
- The product owner prioritizes product features in order of business value or risk and communicates priorities to the development team. The development team delivers the most valuable features on the list in short cycles of development, known as iterations or sprints.
- The product owner has deep and ongoing involvement throughout each day to clarify priorities and requirements, make decisions, provide feedback, and quickly answer the many questions that pop up during a project.
- Frequent delivery of working functionality allows the product owner and the customer to have a full sense of how the product is developing.
- As the development team continues to deliver complete, working, potentially shippable functionality every four to eight weeks or less, the value of the total product grows incrementally, as do its functional capabilities.
- The customer accumulates value for his or her investment regularly by receiving new, ready-to-use functionality throughout the project, rather than waiting until the end of what might be a long project for the first, and maybe only, delivery of releasable product features.
This table shows some customer satisfaction issues that commonly arise on projects. Use the table and gather some examples of customer dissatisfaction that you’ve encountered. Do you think agile project management would make a difference? Why or why not?
|Examples of Customer Dissatisfaction with Projects||How Agile Approaches Can Increase Customer Satisfaction|
|The product requirements were misunderstood by the development team.||Product owners work closely with the customer to define and refine product requirements and provide clarity to the development team.
Agile project teams demonstrate and deliver working functionality at regular intervals. If a product doesn’t work the way the customer thinks it should work, the customer is able to provide feedback at the end of the sprint, not before it’s too late at the end of the project.
|The product wasn’t delivered when the customer needed it.||Working in sprints allows agile project teams to deliver high-priority functionality early and often.|
|The customer can’t request changes without additional cost and time.||Agile processes are built for change. Development teams can accommodate new requirements, requirement updates, and shifting priorities with each sprint, offsetting the cost of these changes by removing the lowest-priority requirements — functionality that likely will never or rarely get used.|
Check here for a blank template of this agile form.
Agile strategies for customer satisfaction include the following:
- Producing, in each iteration, the highest-priority features first
- Ideally, locating the product owner and the other members of the project team in the same place to eliminate communication barriers
- Breaking requirements into groups of features that can be delivered in four to eight weeks or less
- Keeping written requirements sparse, forcing more robust and effective face-to-face communication
- Getting the product owner’s approval as functionality is completed
- Revisiting the feature list regularly to ensure that the most valuable requirements continue to have the highest priority