Building Trust via Trustworthiness

I walked into the conference room to meet with the VP of enterprise Agile Transformation. It’s been three weeks since I joined a team of highly experienced Agile coaches. As the newest person on the ground, I was looking forward to getting to know the ‘Boss’ better so I could, along with the team, deliver the outcomes we were committed to delivering. 

“Good morning,” the VP said in a brisk tone. As someone who had coached people for a living, I immediately sensed something was amiss. Without the usual smile and small talk, the VP began “This isn’t about you. But…”

Needless to say, it was about me. The VP stated the Agile teams were in ‘chaos’ since being taught the concept of Lean Agile portfolios. “Please do not talk to the director of the Investment team, people will get more confused.”

I was taken aback briefly. Surely, they could see I was addressing the problems necessary to stand up Agile portfolios – wasn’t this the job I was hired to do? And then my brain focused on ‘the teams were in chaos.’ Was I addressing the wrong problem? What could have caused such confusion? What was I missing? 

I remembered that I would always follow Dr. Stephen Covey’s habit of “Seek first to understand, then to be understood.” So I needed to make sure that I was solving the right problem – not the problem I thought they had, but the problem that the VP thought they had. 

I spent the rest of that morning researching and gathering evidence of teams being in chaos. In the next few days, I quickly learned that the application lifecycle management system – Jira in this case – was changed to support Agile portfolios. The teams were totally confused by the new workflow schema and complaints went up the management chain. I shared my findings with our coaching team.

Bingo! Once we found the root cause of the problem, we were able to quickly craft a solution to calm the teams and stabilize the environment. To our surprise, that one fix started a chain reaction that turned around the VP’s view of the Agile coaches—me included—and the value we were providing. Instead of firing us, six months after I walked into that conference room, the VP hired 5 additional coaches to stand up more Agile portfolios! 

What I learned that day was invaluable. And it served as a constant reminder that trust is built upon trustworthiness, the foundation of which are stable teams in enterprise Agile Transformations.

Trust vs Trustworthy 

What is trust? According to the dictionary, it is assured reliance on the character, ability, strength, or truth of someone or something. It means to place confidence in. Trust brings out the very best in people. But it takes time, and it doesn’t preclude the need to train and develop people so that their competency can rise to the level of that trust.

What is trustworthiness? At its core, to earn and deserve the trust requested, it’s the ability to make and meet commitments. It is the ability to communicate what you can do, by when, and actually do it. 

For an Agile team, being trustworthy is about having a stable and predictable capacity; for a Scrum team, that’s a stable velocity, for a Kanban team, that’s stable throughput. 

For the business, trustworthiness is about creating an ecosystem that enables the Agile team to be successful. The business clearly communicates needs to the team and gives the team room to define a solution. The team is able to make a delivery commitment and not get pushed to “deliver more.” The teams can count on the business to remove roadblocks that get in the way.

What Makes a Team Trustworthy? 

For a team to be trusted and therefore trustworthy, it must be operating in a trusted ecosystem. Agile frameworks and tools are helpful. Agile culture is helpful. But without an Agile or trusting ecosystem, the team will never stabilize its velocity (or throughput) and become trustworthy.  

We will use one of our favorite topics–dependencies. Dependencies are the biggest problem in Agile and prevent teams from being trustworthy. Let’s say Agile Team A has some full-time and some part-time team members. The part-time team members are on Team A and also on Team B. So, Team A is not fully trustworthy in and of itself. It is dependent on Team B. It can’t make and meet commitments as predictably as if all Team A members were full-time.  

Some other factors that keep teams from being trustworthy are:

• Teams are not cross-functional; they don’t include everything and everyone necessary to deliver results tied to strategy
• Team member roles and responsibilities are unclear
• Team members don’t know how to effectively progressively elaborate the work or know when work is “Ready” for the next team to take the lead
• Teams don’t keep a regular cadence of collaboration and review
• The Product Owner doesn’t provide sufficient clarity in the backlog
• Teams don’t know how to, or have permission to, remove dependencies

What Makes the Business Trustworthy? 

For the business to be trusted and therefore trustworthy, it must also be operating in a trusted ecosystem. Say the company launches an Agile transformation which includes a vertical slice of the organization. The Portfolio and Product Teams are struggling to effectively elaborate the work that will constitute the first release. The Business grows tired of the process and simply sets a date and freezes the scope. The Business has violated a basic tenet of Agile development and has created an untenable ecosystem. The Business is therefore not trustworthy. 

Some other factors that keep the Business from being trustworthy are:

• Improperly staffed teams
• Unclear business objectives
• Not investing in needed agile skills training
• Lumping work on the team that exceeds its capacity, creating an impossible situation
• Not partnering with the Portfolio, Product or Delivery teams to effectively elaborate or enable the teams to solution the requests.

Chicken or Egg? 

On the journey to earn trust, who goes first, the Agile team or the Business? It’s sort of the chicken and the egg problem. Does a team earn trust first by predictably delivering value? Or does the Business earn trust first by creating a safe ecosystem in which the Agile team can deliver? 

Our strong point of view is that the Business should go first, thereby blazing a path forward in which the Agile teams can proceed.  

The business has to create the conditions for the teams to succeed which, in turn, provides the conditions to build trustworthy teams and the ability to make and meet commitments so the Agile team has the potential to deliver value at a sustainable pace. This predictable delivery will then provide value the organization can trust to achieve business outcomes. 

In the next segment of this two-part blog, we’ll delve into how to enable the business to create the right conditions to begin the trust-influence loop, which is a virtuous cycle that builds trust continuously.