(Re-)Building Trust When It Has been Squandered

Attendees:

PaulBoos (topic facilitator)
CraigMcCrary
KariDay
KatieMcCroskey
SaleemSiddiqui
ManojVadakkan

Background:

Paul provided some context of why he wated to discuss this topic; he recently joined a group that due to failure to deliver had lost trust with the business stakeholders, particularly senior management. While he recognizes that ultimately delivering will solve this issue, some business stakeholders/users are a bit unwilling/reluctant to work with IT/development as a result, which of course jeopardizes delivery. Thus, he was interested in exploring ways to build back trust so that good working relationships could be established and allow his folks to deliver.

Paul's thiniking in delving into this at Agile Coach Camp was two-fold:

• Agile Coqches often themselves have skeptics and have to quickly build trust with those skeptics
• Agile Coaches probably help groups that also have lost trust and are attempting to implement Agile practices with at least one goal to re-build that trust

Explorations:

The team at the session explored two primary topics, but not necessarily in this order:

• Reasons for that loss of trust
• Techniques/actions that could be used to build trust

Reasons for Loss of Trust:

• Lack of Information or Visibility
• Work Prioritization is Wrong
• Unexpected Event
• Non-Delivery

Techniques or Actions One Can Take for Building Trust:

"Coach Up"; coach management and users on how they need to work together

Prioritization on Projects; establish a list of what the business wants and draw a line as to what gets funded so it is clear as to what they are getting. This shoudl be done preferably before funding, but could be done afterwards.

For the above two, we specifially mentioned dot-coting, so the business sets and sees priorities of the organization.

Establish an Open Forum with the business to review the priorities IT/Development has on its plate.

Physically distribute the development teams to the business areas when projects are being performed; i.e. co-locate the development team to the business users.

Create "safety" for the team, in particular the product owner, so that he/they wil be willing to take ownership; it is important ot have this conversation with the business rep.

Articulate the value of a project, so that IT/Development is not simply viewed as a cost center.

Create a working agreement for how work goes into and out of IT/Development, but avoid making this a contract -it shoudl be closer to the working agreements one might see in a retrospective with an input/output focus.

A specific side issue Paul has that has led to not meeting customer expectations is fixed price contracts; all development has been performed under firm fixed price. While he would like to change that, it isn't going to occur quickly; the fixed price contracts then establish a boundary that the hired contractors are always trying to prevent changes to priorities to meet the business needs. A couple of items that were discussed that woudl help specific to this problem:

• Creating master roadmap or list of things ot be done and show what got funded and not funded
• Articulating a plan for how non-funded items woudl be pursued for funding based on the value proposition

NOTE: One item Paul thought of after the meeting is creating a Customer Service Manifesto using the Agile Manifesto as a guide. As long as this Manifeston didn't go at odds ot the Agile Manifesto, it should be able to use these as the working agreements mentioned above.