Get certified - Transform your world of work today


Trust and Commitment

Building Trust and Commitment in a Customer/Supplier Relationship

3 March 2014

Dinesh Sharma
Agile Gurukul

Trust in a customer/supplier relationship is the most critical factor in an Agile project's success or failure. Lack of trust (referred to as risk mitigation in contractual language) often results in lengthy, rigid, SLA-driven contracts, and both sides may fight by taking the "oath of the contract" when something goes wrong. This usually leads to lose-lose situations, and more often than not it's the customers who lose the ultimate battle; if the product/project is delayed, that is often a much higher loss compared to the supplier fee (which is probably too little in comparison to the actual value of the product being built). So from the customer's point of view, why do we start any project with a lack of trust (hence focusing on rigid contracts), and how can we build trust with a new supplier, or with an existing supplier in whom we have little trust?

We all know the importance of trust in a relationship with friends, a spouse, partners, etc. We don't write up a contract with our friends or with our spouses, do we? But there is a catch: We don't make everyone our friends. We choose friends based on compatibility or being comfortable with them because we share principles and values. But how do we know that we are compatible or are following the same principles and values? We take some time to build trust by spending time, energy, and commitment with these others. We observe them regularly and openly share our emotional capital (beliefs, feelings, principles, perceptions, and values). We take time to understand each other and decide whether we can be friends and have a lasting relationship.

So why can't (or don't) we do this with our suppliers? Why don't we invest in similar emotional capital with our suppliers and see if we can build a long-term relationship based on mutual principles, beliefs, and values? I guess there is a one big problem -- money. Money (often lots of it) is involved in a commercial relationship, and each side wants to protect their commercial interests, so mitigating financial risk takes precedence over trust.

That's where an Agile way of working helps, as you don't have to spend big before deciding whether there is an issue of trust or not. Invest emotional capital in the early stage of the relationship (the project) by understanding the supplier's maturity, experience, and organizational structure and its challenges, and discuss all of this openly with the supplier. This creates an environment of openness and also sets expectationd at an early stage of the project that influence the behavior of both sides at all levels -- both management and development teams. Send your Agile coaches and/or development manager and your product manager/owners to spend time with the supplier and be involved in building initial teams in interviewing, training, and creating desk plans and even understanding individuals' career objectives, so you can understand their level of motivation. While selecting a team, focus on both the aptitude and the attitude of individual team members, and explore how open they are to working in an Agile environment where teamwork is more valued than individual performance. Once you have initial teams (maximum one to three), bring them onsite (if you have teams onsite) and colocate them with your onsite team. Lots of teams in an offshore environment are not exposed to a mature Agile environment, so although they are listening to you initially, at heart they are still not convinced that they will be in an environment in which individuals and interactions are valued over processes and tools. Once they experience this environment, their enthusiasm, energy, and commitment levels all increase.

If you don't have any onsite team, ask your Agile coaches to spend two to three months initially in enforcing Agile principles and values, and invest in coaching the team on practices, be they Kanban, Scrum, or whatever other framework/process you want to follow. After the initial two to three months, make sure individuals at both ends visit each other regularly to sustain the momentum. Once you are happy with your initial teams, you can gradually scale and let existing offshore teams become involved in the process. Existing team members are your best brand ambassadors; they will spread the excitement of working on your projects. They will convince "best" talent within their own organizations and help bring them onto your team. They will also help create the right environment among new teams by sharing their experiences and correcting unwanted behavior (helping new employees "unlearn"). You will suddenly see that you have lots of mentors around new teams to help them settle into the new environment.

The initial commitment to build trust goes a long way and is much cheaper than fighting over contract SLA issues later. Also, please keep in mind that the value is in the product that's being built, not in contract negotiations or in penalizing each other. So focusing on building trust early pays you continuously throughout the project/product life span.

One more thing: Don't confuse "trust" with "blind faith." Have a contract, but one with flexible SLAs, e.g., Definition of Done for stories, sprint, and release. This helps ensure that the contract takes care of quality and makes your policies explicit, setting the right expectations at all levels.

Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.

Article Rating

Current rating: 3.3 (3 ratings)


Be the first to add a comment...

You must Login or Signup to comment.

The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.


Newsletter Sign-Up