Trustworthiness… Then Trust
Written by Mike Cottmeyer Friday, 21 May 2010 01:21
Trust is an import part of what makes agile really work. It is so important, we are intentional about creating the opportunity for that trust to emerge within the team. We are intentional about creating a planning, delivery, and feedback cadence that helps trust form between the team and the business. Trust is a fundamental precondition to how we write requirements, how we estimate, and how we assess progress. Without trust, agile isn’t really very agile.
But what do you do if you are in an organization where trust is really low? What if you are working in an organization with a long history of distrust between the development team and the business… an organization where the business has unrealistic expectations and a perception that development never gets anything done. You might decide to adopt agile, but that history isn’t going to go away overnight. In this case, is it fair to ask the business to trust the team?
One of the biggest complaints I hear from new agile teams, is that the business does not trust them to deliver. They are convinced that all their problems would go away if the business would just trust them to do their jobs. These teams want the business to trust them first. The problem is that the business has no history of getting what they want. They have no history of software being delivered on time. They have no history of getting the quality they need to be successful with their customers.
If you are a team that wants to be trusted, I would suggest that you stop asking the business to trust you. When you frame the problem this way, it makes you powerless to do anything about it. Either the business changes or you can’t be successful… the problem is beyond your ability to influence. What you need to do is become trustworthy. Becoming trustworthy is something that you have power to do something about. If you are trustworthy long enough, you will earn the trust of the business and won’t have to ask for it.