Trust--the key for successful delivery using agile methods

Abstract

Trust between the deliverer and receiver is a necessity when delivering projects using agile project management. Referring to the Manifesto for Agile Software Development, people interaction, collaboration and, willingness to change, are fundamental in agile project management. But is this possible if an assignment, agreement, or firm contract is not written on the basis of trust?

Two cases are presented in which the same consulting company delivered software to different customers, with two completely different outcomes, even though the projects were led by the same project manager and scrum master. The biggest differences shown in both projects are the project initiation and customer interaction.

The conclusion is that the trust built in one of the projects made it a huge success, whereas the other project, running in a more traditional process, was rated barely average.

The trust in the successful project created greater customer collaboration, with opportunities for changes, resulting in outstanding results.

Trust between the deliverer and receiver is a necessity when delivering projects using agile project management.

Introduction

Why did the same team produce fundamentally different results in two similar projects, with just a few months’ time difference?

• The team comes from an organization that has worked with agile methods for years and knows both the theory and practices well
• Both projects were very advanced with customers who didn't really know what they wanted—perfect for an agile approach in which late decisions can be made
• Both customers were located in a city other than the project team's
• None of the customers knew anything about software development
• Both projects had about the same time frame and budget
• Both projects were strategically important to the customer

Yet, the project results differed dramatically:

Project A

• Delivered at 200% over budget
• Was 200% delayed
• Only 30% of the code was used

Project B

• Delivered on time
• Delivered on budget
• 100% of the code was used

What happened?

There are several questions that can be and should be posited in the organization of delivering such projects. The first question is: What happened? This initial question launches a retrospective and review of the results. More importantly, it is necessary to understand the behavior between the organizations that led to these different results.

The basic dysfunction to be studied is trust. Trust is a fundamental pillar when working with agile project management.

Theory

Trust

There are many definitions of trust and much research has been done on the topic. Because this is a paper from the IT world, let's use the definition from Wikipedia (Wikipedia, Trust, 2012, February 17. ¶1):

In a social context, trust has several connotations. Definitions of trust typically refer to a situation characterized by the following aspects: One party (trustor) is willing to rely on the actions of another party (trustee); the situation is directed to the future. In addition, the trustor (voluntarily or forcedly) abandons control over the actions performed by the trustee. As a consequence, the trustor is uncertain about the outcome of the other's actions; he can only develop and evaluate expectations. The uncertainty involves the risk of failure or harm to the trustor if the trustee will not behave as desired.

Trust has to do with relationships between people. It has also been demonstrated that human beings have a natural disposition of trust from biology. (Wikipedia, Trust, 2012, February 17, ¶2) Trust is usually viewed as something built and shared between two individuals over time and includes risk taking as seen in the definition.

Every human being has experienced trust and the difficulties and ease of trusting. Books and dissertations have been written about this. To make it simple, trust is about giving of yourself and taking risks.

Agile

In February 2001, representatives and thought leaders of various agile software development methods gathered in a ski resort in Utah, USA. The outcome of this meeting was what we today call the Agile Manifesto (Cunningham, 2001, ¶1).

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

All these statements include a large proportion of trust. The Agile Manifesto is accompanied by twelve principles listed in Appendix 1 at the end of this paper.

Individuals and interactions over processes and tools

With the use of firm processes and supporting tools, the project manager is given strong control. Equally, agile methods are about empowering individuals and the team. Empowering is not governed by a rigid process but by trusting your team members.

Working software over comprehensive documentation

This is one of the most misunderstood and misused statements from the Agile Manifesto, because “over” doesn't imply “instead of.” Documentation is imperative, although the extent of it is dictated by scope. Can you trust your Software development team to decide this? Or, even better, with sprint retrospectives are you able to trust your team to improve the documentation process to fit the right needs?

Customer collaboration over contract negotiation

Here, things get more complex. Even if you have built trust within your group, company, and team, in order for the process to be successful, it is also essential to build trust between you and the customer, whether they are internal or external. Customers start by specifying what they want, and the full benefit of using agile methods is to start working before all specifics of the requested delivery are known. In order to start at this stage, both parties need to trust one another. With this in place, agreements no longer have to be as comprehensive. They can be simple, stating the framework and limits of the project to be delivered within. Both parties agree on a common goal; ideally, the customer is included in the team.

Responding to change over following a plan

This is the strongest statement of the four principles because it encapsulates the essence of agile. This principle embraces a changing business environment. It welcomes knowledge and promotes changing shifts in design that give the customer of software a competitive advantage. Embracing change and welcoming knowledge require good communication and collaboration between customer and supplier. These are the same truths that define trust.

Three Dimensions of Trust

In theory and research there are several models of trust. This paper sheds light on the model that categorizes trust into three areas: individual, organizational, and institutional trust (Vestlinder & Olofsdotter. 2011, pp 21–22). See Exhibit 1.

Exhibit 1 – The three dimensions of trust

The individual dimension

This is the dimension that initially comes to mind when discussing trust and is the one defined in Wikipedia. The person-to-person trust is well known and studied. In this dimension, we also have the team trust, which is of great importance in agile. It covers interactions within teams, between a team and the project manager or product owner, and between the team and scrum master in the scrum project. By nature, an agile project implements trust through processes and definitions (e.g., self-organization, daily stand-ups, retrospectives, etc).

In his book, Managing Agile Projects, Sanjiv Augustine writes that trust is imperative in all professional relationships and project trust is something that develops. In an informal agile environment trust must be conveyed from the start. Consequently, agile project management demands a “trust first” attitude that reposes trust in people until proven otherwise. (Augustine, 2005, p, 38)

Trust is at the core of any functioning agile team. Trust is the foundation needed for any team to function. In his book, Five Dysfunctions of a Team, Patrick Lencioni creates a model in which trust is the basis for all other constructive team behaviors. (Lencioni, 2002) Just like physiological needs, food, water, warmth, and rest are the foundation for Maslow's Hierarchy of Needs. (Maslow's Hierarchy of Needs, 2012, February 21, ¶1). Without trust we cannot build creative conflict, be committed, exercise accountability, and strive for common goals (Exhibit 2).

Exhibit 2 – The five functions of a team that are all based on trust.

Lencioni describes the opposites as dysfunctions and how these are overcome. (2002)

The organizational dimension

To implement trust interpersonally and within a team, agile methods cannot simply be imposed. (Vestlinder & Olofsdotter, 2011, pp 21–22). See Exhibit 1; It is here we observe the organizational dimension.

When teams led by “old school managers” are denied the option of implementing agile methods, they often go “stealth mode” and pretend to obey corporate project processes. The project manager attends management meetings and presents classic status reports. Meanwhile, the team develops according to an agile approach. This is not an example of a situation that demonstrates much trust from anyone. The team does not trust the manager in his or her ability to embrace change, and management doesn't trust the team that is interested in working with new methodologies and processes.

Applying agile project management in an organization includes acceptance from the organization, including C-level management. Management, procurement, as well as project management and development departments need to learn to trust each other. The whole organization needs to have a strong sense of self-confidence.

Trust needs to exist inter-organizationally as well. Sales and procurement on the customer side need to open up to each other and understand and appreciate one another's needs. Both organizations need to have confidence. Here, interpersonal and individual trust is important. (Vestlinder, & Olofsdotter, 2011, pp 21–22)

When trust is established within all these different levels, the chances of success are exponential.

The institutional dimension

In the institutional dimension (see Exhibit 1) new possibilities for trust exist through new expertise, trends, and debates. Jurisdictions and best practices would be included in this dimension as well. The legitimacy given between parties is given through these surrounding factors. There are laws (SOX) requiring all companies listed on NASDAQ to report their projects with earned value numbers. Such jurisdictions can sometimes help and sometimes be orthogonal to trust. Therefore, it takes time for new trends and expertise to become best practices and be included in standard rules and regulations. Still, it is difficult to find a model for agile contracting that everyone will agree on.

Agile project management may still be categorized with new trends and expertise. Although it has been over 10 years since the Agile Manifesto was formulated, it takes time for these practices to also become “comme il faut” (quite proper) in the software development industry. Both management and procurement are used to control using reports and firm agreements. Most likely, it will take a significant amount of time to convince all of an organization's layers that agile is an acceptable form of project management.

Five Words Leading to Trust

Let's take a look at a simple model by Cantone (Cantone, 2010), which uses five words that can lead to trust.

Truth

Truth is the refusal to pledge promises you cannot keep. It is the act of being transparent and always allowing the truth to guide discussions with your team and customer. Implicitly, truth includes a measure of uncertainty, and breaking the truth can severely damage the relationship.

Perseverance

In order to build trust, there need to be perseverance and commitment fueling your actions. By working hard and overcoming difficulties in order to deliver the points of an agreement, trust will grow.

Integrity

Integrity is to work with honesty and to act fairly, with character, morals, and a continuous high standard of ethics. Refer to the PMI Code of Ethics and Professional Conduct. (PMI, 2012, 1¶)

Reputation

Reputation and credibility are granted by others. This is part of organizational trust. When good work happens, others will speak about it and building such a reputation takes time and persistence.

Satisfaction

Manage expectations. When fulfilling expectations you build trust. Make your customers and environment satisfied. Selnes writes, “In a study of institutional buyers of a food producer we find that satisfaction and trust are complementary in the sense that trust is a key variable when decisions are related to enhancement in scope of the relationship, whereas satisfaction is a key variable when the issue is relationship continuity.” (Selnes, 1998, p. 305)

The Projects

Let's take a look at how the theory of trust and the four statements about agile apply to the two projects initially described.

Project A

Background

The supplier is asked to create an e-book for children. It is supposed to be based on a well-known children's book. The deadline is clear. A book fair is scheduled in a couple of months, and this e-book will be displayed at the fair. The customer has no digital strategy, and this is the first project of this kind. The customer is very impressed by the knowledge and vision provided by the account manager. The account manager builds expectations and the customer feels mutual trust with the account manager. This is a high-priority project for the customer and it is an important project for the supplier's organization, even though the budget is lower than average.

Project start

The development team is eager to get started. A fairly loose specification is given and the scrum master and team must create the stories. They think this will be a great project and say, “A children's book, how fun!” They have creative ideas and feel the account manager is allowing them much freedom to use their creativity.

After two iterations, 90% of the functionality and specifications are implemented, and only 70% of the budget is consumed. At the first iteration, the team received no feedback or comments from the customer. At the time of the second iteration, with a nearly finished product, the customer's first reactions arrived. These reactions were quite the opposite from what the team had expected.

The customer had, for the first time, looked into what was delivered. During the time of the two iterations, the customer had written a specification about how they wanted this children's book to be digitalized. The definition of “loose specifications” was interpreted by the customer as implying the ability to redefine the final product. The fixed price, however, remained fixed.

At the second iteration and after customer feedback, the delivery organization realized they had done 30% of what the customer thought they wanted and had already used a majority of the budget. The project team is downsized to minimum to only do the changes in the product that are absolutely necessary.

Project continues

The customer had become accustomed to fast delivery; they interpret that by using agile methods, the supplier implies infinite changes without additional cost. But, at this stage in the project, the responses to the change requests are not as prompt and direct as the initial deliveries, because the project team had been reduced to a scrum master and a part-time developer.

Irritation and mistrust begin to bloom. Because the customer and development team seldom meet in person, and all meetings are conducted over the phone, requests drop in, and top priority changes are implemented. The customer scraps 90% of the creative implementations the development team had originally created in the two first iterations.

Project team motivation falls to a minimum. Customer satisfaction plunges to a minimum.

Project closing

A new project manager is introduced by the supplier. The project manager initiates several face-to-face meetings to get the customer's version of the project and agreement. A clean-up team is formed at the supplier. The project is finished after two more iterations, at 200% above budget and way over schedule, with only 30% of the total functionality ultimately created.

Project B

Background

The supplying organization is asked to make the corporate intranet a mobile app for two different mobile phone platforms. It is especially important that the live sales displays are functioning. The deadline is clear. The manager in charge must spend his budget by the end of the year, and the project launches mid-November. The customer has no idea how this is to be implemented, and this is the first project of this kind. The customer is very impressed by the knowledge and visions provided by the account manager. The account manager builds expectations and the customer feels mutual trust with the account manager. This is a high-priority project for the customer and it is an important project for the supplier organization, even though the budget is lower than average.

Project start

The development team is eager to get started. A fairly loose specification is given and the scrum master and team must create the stories. A project manager is appointed from the start. The customer appoints a dedicated project manager. The team thinks this will be a great, but scary, project, because the scope is substantial and the deadline firm. They have creative ideas and feel the account manager and project manager are giving them lots of freedom.

The scrum master and the team create stories for all the specifications; they create a kanban board, estimate how much needs to be done in each iteration, and four separate iterations are created.

The project starts. The project manager informs the customer about the process. At the end of each iteration, there will be a functionality that the customer can implement. The customer is asked to be present when iteration 2 (50%) is delivered. Daily phone calls are held between the two organizations. Several face-to-face meetings are held throughout the project.

With the frequent meetings scheduled, change requests are immediately registered and discussed, and compromises are agreed on.

Project continues

Iteration 2 delivery is held with the customer present. The customer is impressed and satisfied that 50% of the agreed-on functionality has been implemented.

The trust is growing between the organizations. A major change request is received from the customer. It is possible to implement this by swapping out less important functionalities.

Project team motivation is at a maximum. Customer satisfaction is at a maximum.

Project closing

The project is delivered on time with agreed-on scope and within budget.

Next year, the supplying organization receives orders from the customer that are worth ten times the value of the first project.

What happened?

How can two projects with such similar prerequisites have such different results?

Both projects were created with approximately the same number of developers. Both projects had the same scrum master. The project manager, who arrived late during project A, was part of project B from the start.

The supplying organization is well versed in working with agile methods, including the customer in the projects. They are well experienced with agile methods and their benefits. There is consistent trust between account managers and project teams.

Project A

In Project A, individual trust was built between the account manager and the customer representative through expectations and a vision. The customer believed this was also the project team's vision and so an organizational trust was initialized. The customer's project manager and the supplier's scrum master met face-to-face a couple of times, and trust evolved. The development team was very dedicated and glad for the assignment. Unfortunately, the expectations and vision were never transferred from the account manager to the team. The trust then got dissolved when the customer did not respond on the fast deliveries. The development team totally lost its faith and trust in the customer, with the first feedback arriving not until the second iteration, when they thought they were finished.

In the second iteration, the customer receiving team had just been formed and they were happy to receive the iteration. However, because they had never had a product like this before, they couldn't appreciate the amount of work put into the product, which didn't conform with the expectations of the account manager. Technical platform issues that the supplier couldn't augment bothered the customer (e.g., the color difference between printed material and a digital book). Discussions were fixated on technical facts that were impossible for the supplier to act on. The customer expected that the supplier could change faults that were hardware and firmware dependent, which could not be remedied by a software application.

Trust and faith in the supplier from the customer dropped. The customer started to demand changes without realizing the corresponding amount of work.

None of the parties trusted each other anymore.

When the project manager came into the project, trust was the basic issue that needed to be rebuilt to finish the project. This was done by understanding the customer expectations and making it clear what was possible to solve and what wasn't; unfortunately, however, it was impossible to save any part of the project. This clearly shows that agile methods do not help when trust in the organizational dimension is dissolved. In this case, another type of agreement would have been beneficial for both parties; it would have helped resolve issues and could have, for example, stated the scope.

Looking into the five words used to build trust, the last one being satisfaction; managing expectations was completely missing from Project A's scenario. When the new project manager entered, effort was invested in honesty, truth, commitment, and integrity. It was very important to close the project without a bad reputation.

Project B

In Project B, organizational trust was built between the account manager and the customer's representative. The organizational trust was immediately taken over by both organizations’ project managers and nurtured by frequent communication with open and honest discussions. This transfer of organizational trust was performed by clearly managing the customer's expectations and making it visible for the customer that the delivery the team knew and understood their expectations.

The customer completely trusted the supplier. In addition, the project team had faith and trust in the customer, although the project scope was quite large. The importance and possibilities of the project's success were inspiring and, as the project evolved, motivation lifted even more.

With the first two dimensions of trust—individual and organizational—trust in the third dimension, institutional, grew. The customer's organization began to trust the agile methods and the new expertise the supplier was able to bring in.

All the five elements leading to trust: truth, perseverance, integrity, reputation, and satisfaction, were taken into account during the project.

Trust in all three dimensions was fundamental to a long-term business relationship.

Summary and Conclusions

The Three Dimensions of Trust

First dimension

Creating trust within your team and your interpersonal environment is essential and the most important start. Using scrum as a method is one way forward. The meetings stipulated in scrum naturally build trust. Using the tools by Derby and Larsen for the retrospective meetings also fosters trust within the team. (Derby & Larsen, 2006)

For management teams, the five dysfunctions of a team must be overcome: trust, creative conflict, commitment, accountability, and result focus must be implemented. With these in place, your team is ready.

Second dimension

Let the whole organization understand the Agile Manifesto and its twelve principles and how it impacts sales, and how the account managers handle procurement with the customer. Agile contracting must be invented at the supplying organization.

The organization needs to build self-esteem. The account managers need to sell the idea and confidence rather than delivered development hours.

Third dimension

Agile project management is a new expertise that needs to be adopted and will be adopted by the majority of software developing companies.

Meanwhile, to get there and build trust in these methods, certifications like the PMI Agile Certified Practitioner (PMI-ACP)^SM are very important. (PMI, 2012, ¶1) This shows that organizations, independent from methods, accept and value new ideas.

Conferences, articles, and blogs are also important.

Outlook

For agile methods to be successful for the society as a whole, all three dimensions are vital. This requires time. Trust can be nurtured within teams and organizations. If this is done together, along with a strong and driven agile community, the outlook for a society that is full of positive and trustful spirit infused with faith is possible.

Final Statement

Embracing agile methods of working means you embrace uncertainty. Instead of trying to control uncertainty, trust people.

© 2012, Mattias Georgson Petrén

Originally published as a part of 2012 PMI Global Congress Proceedings – Marseille, France