Pretty image
One of the biggest culture shifts in our industry over the last ten years is that, for the first time, we have stopped lying to each other.

The best time to plant a tree is twenty years ago. The second best time is today.–Chinese Proverb

One lubricant that underlies just about everything we do in work, play, and creating great software is trust.

When you’ve got it, you become empowered. Free to take initiative, make your own decisions, and be your own boss.

Without it, life can be tough. You’ll be asked to justify everything you do, your decisions will continuously be scrutinized, and you’ll be kept on a very short leash.

In this article we’re going to look at what a lack of trust costs us on projects, what we can do to earn our customers’ trust back, and what an environment where elevated trust has been earned looks like.

Waste

When you break the big laws, you do not get liberty; you do not even get anarchy. You get the small laws.–G.K. Chesterton

If you work in a typical office environment, you probably don’t have to look too hard to find examples of waste.

It might be waste in the form of unnecessary meetings. It might be waste in the form of documentation that no one will ever read. Or it might be waste in the endless series of sign-offs, hand-offs, plans, documents, templates, signatures, and compliance hoops you have to jump through just to push your software live.

And of course the ultimate form of waste is spending six months writing software that will never see the light of day because the company isn’t able to pull the right people together to release it into production (true story!).

Whatever form it takes, unchecked waste can be demoralizing and soul-sapping. It takes the best out of our people, and drives some to seek employment elsewhere.

But waste isn’t the cause. It’s the symptom. A lot of the waste we have to put up with in our daily lives is a byproduct of a lack of trust.

If companies simply trusted their people, a lot of the waste we see on software projects would go away. We wouldn’t need 10,000 meetings before pushing our software live. We wouldn’t need a six-week regression-testing cycle for two days of bug fixing. And we certainly wouldn’t need those countless checks and balances that ensure that nothing bad happens by ensuring that nothing ever gets done!

But trust is a two-way street. A lot of that waste is there because we haven’t demonstrated enough competency as an industry to show that we don’t need it.

If that’s going to change, it’s up to you.

If you want to be empowered, listened to, respected, and trusted to take initiative and get things done, you’ll need to get good at earning your customers’ trust.

Here are three simple but powerful ways you can go about doing that.

Three Ways to Earn Your Customers’ Trust

“Verifying that my software still works slows me down.” Yes, code can be delivered much faster if having it work is optional–@jasongorman

1. Take away the quality lever.

I was on a project once where a developer told me that he was told explicitly that he wasn’t allowed to test. The project manager said there wasn’t enough time and they simply had to build it and get it out there (bonuses were on the line). The results were about what you’d expect.

One way to nip this kind of behavior in the bud is to take away the quality lever from the customers. Simply don’t give it to them.

Look. Your customers expect you to test their software. It’s not only unprofessional not to test, it’s going to hurt you inside if you don’t. You’ll feel bad about the work you’ve done, and you’ll probably take the heat for it when things blow up.

So don’t give them the quality lever. Just explain that writing untested crappy software that doesn’t work isn’t what we do around here. There is no quality lever.

2. Deliver something of value every week.

value-every-week.jpg

This is probably the best way I know to get a customer on your side. Simply break their system down into a whole bunch of small chunks and then, like a metronome, start delivering their most important features as working, tested software every couple of weeks.

Doing this helps you build trust in a number of fundamental ways.

First, it shows that you know what you are doing. There’s still enough dysfunctional software being written that if you show how it’s done and deliver them a stripped-down (but fully tested), working version of their system in a couple of weeks (instead of a couple of months), you’ll earn huge street cred.

Second, they are going to realize (maybe for the first time ever) that they play an important role in the success of the project. Instead of having a project done to them, they enjoy being in the driver’s seat for a change. All they have to do is answer a few questions, tell you what the most important stuff is, and poof! It gets done.

Third, (and most important) it’s hard not to appreciate a team that shows up every week and delivers something of value. Sure, you’d like them to go faster. Yes, you wish they could get more done. But at the end of the day they show up and they deliver. ’Nuff said.

3. Be open and honest about the schedule.

Agile is pretty open and honest about things like schedule. We don’t make commitments until we are relatively sure we can meet them, and we don’t sugar-coat it or hide the state of our projects. We put it out there for all to see.

This is perhaps one of the biggest culture shifts that has taken place in our industry over the last ten years. For the first time, we as adults have stopped lying to each other.

open-honest-schedule.jpg

Being open and honest about schedule means not making premature commitments about scope and time. It means leveling with your customer and telling them that you aren’t sure exactly how much you’ll be able to get done by the end of the project because of the sheer number of unknowns (like their level of participation in the project).

Some customers find this kind of candor refreshing—usually because they face the same problems when they deal with their bosses. But by being open and honest about things like schedule we can then focus on delivering value instead of spending valuable shareholder capital thinking about how we are all going to cover our butts when things blow up.

Leveling Up

Few things can help an individual more than to place responsibility on him, and to let him know that you trust him.–Booker T. Washington

Agile projects aren’t perfect. We still do things, set expectations, and plan in ways that wouldn’t be necessary if we had complete trust with our customers.

Here are some examples of how agile teams have morphed their practices once they have earned very high levels of trust with their clients.

1. Questions about estimates go away.

Once you’ve proven you can deliver, most questions about estimates go away.

Your customers know you can deliver 4-6 stories per iteration. They trust you to get the most important stories done every iteration, and that’s good enough for them.

Some agile teams are even able to dispense with the estimation process altogether, by simply sizing their stories roughly the same and delivering the same number each iteration. Nobody cares whether something has 1, 3, or 5 parts—it doesn’t really matter. More time spent adding features, less time estimating and planning.

2. UAT becomes a formality.

Formal User Acceptance Testing (UAT) isn’t an agile practice. It’s a relic from a software delivery process that became entrenched due to a lack of trust (a lack of trust that we as an industry earned).

We still do it simply because we haven’t yet demonstrated that it is no longer necessary.

The good news, though, is that for many teams, formal UAT cycles at the end of a release are becoming a thing of the past.

When you get used to testing and releasing software regularly, a lot of the fear and waste that traditionally comes with releasing software goes away. It becomes breathing. It’s just something you regularly do.

I don’t recommend teams new to agile start here. You’ve got to earn the right to lighten up on UAT before you consider dropping it. But there are a lot of companies for whom UAT is quickly becoming a thing of the past and they are able to redirect that energy in more useful ways.

3. Mistakes are easily forgiven.

You’re going to make mistakes. It comes with the game, and it comes from continuously trying to improve. But when you do make a mistake, customers are way more forgiving when you’ve demonstrated that you have their best interests at heart and are busting your hump for them each and every iteration.

I remember once doing a print story for a construction project I was working on. The story was pretty simple (print the work permit for the construction site) but my first attempt was less than stellar (and I knew it as soon as I demoed it to my customer, the director of construction).

But because I had just spent the last five iterations delivering really valuable stuff, I had banked enough good will that it wasn’t a big deal. He just said try again and we’ll take a look at it again next week. I didn’t let him down.

Summary

Trust is speed. If you want to go faster and have more fun on your project, you are going to need to earn the right to work in a high-trust environment. Three things you can do to get there are:

  1. Take away the quality lever.

  2. Deliver something of value every week.

  3. Be open and honest about the schedule.

It won’t happen overnight. And you can easily lose it if you are not careful. But the dividends it pays justify the investment. You will be happier, and instead of dreading the thought of coming in to work and being told what to do, you’ll be free to take the initiative and empowered to direct yourself and your team in how you’d like to work.

To learn more about the impact of trust and how it affects your life, I highly recommend reading Steven Covey’s excellent book, The Speed of Trust.

Jonathan Rasmusson is the author of The Agile Samurai. As an experienced entrepreneur and former agile coach for ThoughtWorks, Jonathan has consulted internationally, helping others find better ways to work and play together. When not coaching his sons’ hockey teams or cycling to work in the throes of a Canadian winter, Jonathan can be found sharing his experiences with agile delivery methods at his blog, The Agile Warrior. For more information on the Agile Inception Deck check out The Agile Samurai.

Send the author your feedback or discuss the article in the magazine forum.