Customer

From Business Agility Library
Jump to: navigation, search
Customer Dimension
The heart of business agility is no less than the very reason we exist - our Customer.

Customer is a very broad term. Depending on the organisational context it could mean; a paying client for a private organisation, a citizen for a public sector organisation, or an abstraction (like “the environment” or “the community”) for a NPO (NonProfit Organization). In some contexts, your customer may be a separate division within your organisation. Although in this case you should always consider the total value stream and end customer, instead of just delivering to a division because of the way the reporting lines currently work. Regardless of who your customer is they all have one thing in common.They provide us with our purpose.

Too many organisations have forgotten that we aren't in business to make money - we make a profit to continue to achieve our true purpose - to serve our customer. Think of your local doctor - most people don't become doctors to make money. They become doctors to save lives. They make money in order to continue saving lives. 

“Profit is like the air we breathe. We need air to live, but we don't live to breathe.” - Frederic Laloux

We have placed the Customer at the center of the model, not only because they are the reason we do what we do, but also because they have been invisible for so long. Look at your current org-chart. Where is the customer? Organisations have said for years that customer is their most important asset and yet they are nowhere to be seen.[1]

Having the Customer at the center doesn’t mean that the customer is always right or that employees or shareholders aren’t important. And it’s always remains important that we make a profit. It means that almost everything that we do revolves around them. It means that they are the top of our organisation charts. It means that the work that we do, and the way that we work, is primarily for them.

Trust[edit | edit source]

There is a fundamental element that distinguishes between successful and unsuccessful agile engagements; trust. Because software development is fundamentally unpredictable, bordering on chaotic (as per the complexity theory definition), customers (whether internal or external with an Agile Contract) traditionally try to bring control through contracts and fixed scope. Agile, on the other hand, is successful because it leverages (rather than controls) this unpredictability.  

However, if we are trying to "be" agile and leverage this unpredictability, we come up against the natural concerns and fears our customers hold. Can they trust us to act in their best interest? Can they trust us to fail fast? If we can't guarantee exactly what they'll get, can they trust us to deliver something of value? The less trust our customers have in us, the less agile we can be.

A quick aside: This does not mean that contracts are unnecessary. Trust is not blind, nor is it stupid.

Trust Pyramid

The form and flexibility of both the relationship, and associated contract, between parties depends on the level of trust that exists between them. I define this across four distinct levels.

  1. Reference: This is the lowest form of trust and exists where trust between the parties is based on the reference of a mutually trusted third party.
  2. Contract: This is the most common level of trust, and the majority of relationships do not extend beyond this. This exists where parties create legally binding contracts (potentially with penalty clauses) as the core mechanism to enable trust between them.
  3. Identification: This level of trust is created over time and exists where parties have the opportunity to work together and build trust based on personal experiences. This is where we can really start to "be" agile.
  4. Partnership: This is the highest level of trust and exists when both parties share the same goals and outcomes. This may take the form of a strategic partnership or similar structure.

How do you build trust? Being trustworthy is a good start - acting with fairness & integrity, sharing knowledge, being transparent and of course performing competently. Within teams, leaders who delegate outcomes (rather than actions), explain why, seek & value opinions, celebrate success, and give everyone opportunities to contribute (but still consider group, rather than individual, interests) build trust with their teams. It's also worth mentioning that trust is based on perception, rather than reality. In an ideal world they should be the same, but acting with confidence and displaying concern or empathy are good ways of building trust at the start of a relationship.

References[edit | edit source]