PM Articles > Alan S. Koch > Customer Focus

Customer Focus

The Essence of Agility
What makes a project "Agile"?
Part 2 of 4

by Alan S. Koch, PMP

Is the team "Agile," as they claim, or are they using that term as a cloak for a lack of discipline? One way to know is to observe what drives their activity: do they do what is cool, or do they do what the customer values? In this article, we will continue to explore the types of discipline that are the essence of being Agile. This time, we will focus on how the team relates to their customer.

Agility and Discipline

In my last column, I discussed the importance of discipline to Agility. Kent Beck, co-author of Extreme Programming Explained, put it well in his foreword to my book: "Agility in software requires iron discipline." (If you did not see that installment, you may want to read it before you continue with this one.)

Differentiating true Agility from undisciplined behavior is a matter of observing the team to see if they exhibit the behaviors that are essential to Agility:

  • Learning and adaptation
  • Collaboration
  • Customer focus
  • Small self-directed teams
  • Lean principles
  • Progressive requirements elaboration
  • Incremental delivery
  • Iterative planning and adaptation

In this second article of a four-part series, we will discuss the third of those behaviors, Customer focus. As we discuss this, it will be useful to refer to the Agile Lifecycle.

Customer Focus

It is all about our customer. All! An Agile team will do everything in their power to maintain continuous (or at least regular) contact with their customer, because that contact is essential to their ability to produce what the customer needs. An Agile team doesn't trust a Requirements Specification to tell the whole story. They know that if such a document was written, it contains errors, interpretations, and key omissions. They also know that even if it accurately represents what the customer thought they needed when they signed off, things are likely to change before the product is complete.

In order to ensure that they deliver what the customer really needs (and needs today), the team includes the customer in team activities as often as possible. The customer's input is important in each phase of the Agile lifecycle (as pictured above).

Initiate Project – Of course the customer's participation is needed during this phase. But the Agile team will also be involved with them. It is not enough for the Customer to say, "This is what I want, and that is when I need it." Of equal importance is the team's understanding of why each feature is important to the customer, and the customer's understanding of which parts of the project are difficult, time-consuming or technically risky.

Ultimately, defining a project that will best meet the customer's needs requires collaborative planning, with critical input from both the developers and their customer.

Plan Iteration &ndash Although planning the details of the work the team will do in a short iteration is their own job to do (see Small Self-Directed Teams, in the next installment of this series), the team needs critical input from their customer to do it well. What is the goal we are trying to achieve in this iteration? Which features and functions are tied to that goal? And what are their relative priorities? The team's customer must play a central role in these parts of the plan.

But even more important is that the detailed Iteration planning may reveal that the team will be unable to do as much as had originally been thought. The customer must be part of the discussion about how to adjust the scope of the iteration to make it an aggressive, yet achievable plan that will bring real value to the customer.

Develop Product Increment – The customer's role during development cannot be over-emphasized. Regardless of how well requirements have been defined and in what form they have been documented (we will discuss Requirements in Part 4 of this series), the team will have many questions as they actually do the work. Instead of guessing about the best way to implement each feature, an Agile team asks lots of questions of their customer. "If I do it this way, it will have this impact on the end user; but that way will result in such-and-such a limitation. Which way should I do it?" "What precisely were you expecting when you said that you need the system to do this?" "Take a look at this. Will it do what you need?"

An Agile team will not just forge ahead; they will seek feedback from their customer whenever they have a question. Obviously, if their customer is not available to interact with them in this way, the team's ability to be Agile will be hampered. But that will not keep them from asking!

Review Iteration – The point behind the Iteration Review is to get the customer's feedback on what was built during the iteration—either acceptance or specific guidance on what needs to change. This feedback is central to the Agile approach; it is why the product is built incrementally.

After each step in the project, the team will demonstrate what was just built to their customer and actively seek the customer's feedback. If their customer is willing and able to do full Acceptance Testing, that is even better! And putting the product into production is best, because this will result in the richest and most important feedback the team could get!

The more feedback the team members can get from their customer during development (as just discussed in the prior point), the fewer surprises there will be in the Iteration Review. Nevertheless, even with excellent access to their customer during development, the Iteration Review establishes an important milestone that the Agile team cannot continue without.

Adapt to Change – In the first part of this series, I discussed the importance of learning and adaptation to an Agile team. This phase of the Agile lifecycle is when much of the adaptation takes place. Based on all that has been learned as we went through the iterations so far, what should change about the project?

Because the project is all about the customer, these deliberations cannot take place without the customer's participation. The team can articulate the impacts of any changes (cost of that new requirement, impact of a risk realized, expense of changing an already-implemented feature). But only the customer can decide how the project's progression and deliverables should be adjusted to account for all of this.

An Agile team will not simply soldier forward in the face of unachievable expectations. Neither will they make these key decisions themselves. They will present the facts of the project to their customer (and management and any other stakeholders who must be involved), and look to them to make the hard decisions.

Becoming More Agile

We will discuss the last five behaviors of the Essence of Agility (small self-directed teams, lean principles, progressive requirements elaboration, incremental delivery, and iterative planning and adaptation) in parts three and four of this series. But becoming truly Agile can begin today.

We can involve our customer in the workings of the project regularly and continuously. We can articulate the costs, limitations and risks in the project, but leave it to our customer to decide the best use of the project's limited resources. And we can get feedback from our customer as often as we possibly can.

To make this happen, we must engage our customer to a degree that they have probably not been engaged in our projects before. This is a significant time commitment on their part, so we must make it clear that they (and not the project team) are the main beneficiaries of any additional investment of their own time in the project. This investment is insurance that the project will delivery the highest possible business value to them in the face of constraints, changes and all of the surprises that will come up.

This will help us to become a bit more agile. But these behaviors will be difficult to achieve without the other parts of the Essence of Agility. So stay tuned!

Not all comments are posted. Posted comments are subject to editing for clarity and length.


This is superb please keep on providing such helpful and practical material

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.