agile > chapter 2 launch and planning > 2 customer-centric approach and the declaration of interdependence

The Customer-Centric Approach and the Declaration of Interdependence

Agile focuses on people and the business value we can deliver to them. The question we ask is therefore who is the product/service for rather than what do we do.

Being excellent at creating world-class services and products is pointless if there is no one who finds that service or product to be useful. Business value is therefore extrinsic instead of intrinsic. Value is derived from the customers who want our product/service.

We can use the 7 P's to prioritize what we look for when designing to be customer-centric:

Company culture and approach

Not all large successful companies take the same approach to being customer-centric. Apple caters for a very specific kind of customer - impulsive buyers who want to have a specific high profile social identity. As a result of this, Apple focuses on making a few products and having them work very well - their catalogue is mainly high-end phones, tablets and personal computers. They can have very high prices for their items because of the brand image and the quality of product. Customers may complain about these prices but the high profit that Apple makes is testament that buyers are still willing to sacrifice to remain loyal to the brand.

Logitech, on the other hand, produces a wider variety of products ranging from trackballs, mouses and keyboards to backpacks, controllers and software products. Their products are compatible with many operating systems and the price ranges allow for customers across all economic backgrounds to be able to buy. The result is that Logitech reaches a wider market and still makes large profit.

Declaration of interdependence

This is a declaration that was created in 2005 by the agile leaders' network. It gives us the reasons for the agile approach being superior to the traditional approach.


  1. Increase return on investment by making continuous flow of value [is] our focus - This directly corresponds to lean production: we look to produce small, complete features with high quality before moving on to the next. Phased approaches such as waterfall certainly go against this principle, as do purely iterative approaches that do not insist on useful incremental deliveries.

  2. Deliver reliable results by engaging customers in frequent interactions and shared ownership - On far too many projects, the customer coughs up some needs, and then the development team disappears, reappearing much later with some completed or partially completed product. The customer has no ownership of the process or even of the priorities for feature development. There is no definition of "frequent" for this principle, but if you are following along with the first principle--continuous flow of small bits of value--frequent would seem to be almost as often as each new feature was introduced to the development team. Specifically: at least once per iteration, and hopefully more often.

  3. Expect uncertainty and manage for it through iterations, anticipation and adaptation - There is a balance between planning (anticipating) and reacting (adapting). This principle absolutely suggests that we would never want to plan an entire project at the outset of a project, and then set that plan in stone. But it also suggests that we should look to continually anticipate upcoming events. With this principle, the declaration authors felt it was important to tell the agile community to heed information about anticipated events, i.e. not to always wait and react.

  4. Unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference - Many in upper management already think they do this, but ask any developer to honestly assess the way they feel about how they are treated. How many of you developers on agile teams have had management tell you that you weren't allowed to write tests, or refactor the code, because those were just things that were keeping us from shipping the software?

How many times have you heard someone in management say: "And finally, we'll make sure we have fun on this project!" Period. Their idea of creating a fun environment is to declare that people "vill haff fun!"

  1. Boost performance through group accountability for results and shared responsibility for team effectiveness - Even for many teams trying to be agile, the typical implementation is silo-mode development. BAs hand off requirements to developers, who hand off product to QA. Each one of these can think they did a good job, and be rewarded by managers for such, yet we still end up failing miserably. I've blogged numerous times about how it all leads back to principle #1: delivering a quality story at a time as a team before moving on to the next.

  2. Improve effectiveness and reliability through situationally specific strategies, processes and practices - Pragmatism and adaptability. Sticking with pairing, for example, when the culture or physical environment has already proven to not support it.

Credits: Agile In A Flash


Agile operations become a hindrance to the work when agile leaders fail to stick to these principles outlined in the declaration of interdependence. Agile is not meant to be a rigid framework for project management. Its focus on business value and the people involved are its strengths and the declaration teaches us to value these above other aspects of project management.