Archives for 12 Nov,2015

You are browsing the site archives by date.


TrustI’ve been thinking a lot lately about what makes Agile work, and what types of things make Agile fail.

I like to strip things down to their smallest, most basic point. When I do this with Agile, I keep coming back to trust.

Many times Agile fails because leadership fails to trust the team. Or because team members fail to trust leadership. Sometimes it’s because team members and/or leadership fail to trust the chosen processes. Now and then it’s because team members fail to trust each other.

When Agile works, it’s because the members of the team trust each other. Leadership trusts the team. Everyone trusts the processes.

I do not think that Agile is such a difficult thing for people to learn. Agile is awesome because it is such a simple, easy concept.

I do, however, know that lack of trust can be a huge barrier to overcome.

I’ve worked with people who don’t trust. I can see them working against the team, reaching for their own goals, making assumptions that the team will turn on them if they aren’t somehow protected.

These are people who hoard responsibilities and avoid visibility. They chafe at requests for communication, and have a difficult time seeing the team as a unit with a shared goal, rather than as a group of individuals each working independently toward their own benefit.

I’ve also worked with people who have no problem trusting. People who gladly collaborate and who see the team’s successes as something shared, which everyone owns equally.

Sometimes it’s a personal thing, where an individual just can’t trust anyone – in any setting.

Often, however, it’s due to a culture of distrust in the business environment.


We know that “culture” is a common barrier to Agile adoption. Cultures in the past – cultures which I feel are antiquated and outdated – have created environments where leadership must oversee every aspect of productivity. Where team members must account individually for their contribution.

That type of antiquated culture breeds distrust, and a lack of trust impedes a lot of other important aspects of Agile, such as visibility and communication.

If you want to adopt Agile, the first step is addressing your culture. Take a good hard look at the trust in your organization.

Gone are the days when each person stood alone on their own pile of achievements.

Gone are the days when a success was owned by one person who was fast enough, sneaky enough, or powerful enough to put their name at the top.

Gone are the days when developers had to be monitored and babysat (usually by someone who had no idea what they were working on or how to tell if they were actually producing anything of value).

Gone are the days when we had to worry that if we didn’t hoard our tasks, someone else would step in and take them, getting that promotion or accolade.

Today, we work in teams.  Each success belongs to a group of people.  (The team may choose to high-five one person who came through in a big way, but the “win” belongs to the team as a whole.)

Today, tasks flow freely through a group and you trust the person next to you to share your goals.

Today, visibility and communication have improved to a point where leadership no longer needs to bear down on team members in order to have an idea of where a project is in its development cycle.

Today, we trust our team members to self-organize, to create their own processes and choose their own tools.Trust is such a simple little word. We all know what it means, and I think we’d all like to do it.

The trick is identifying how your current culture – your processes, your tools, your relationships, your organizational hierarchy, and even the physical layout of your office space – creates distrust.

I am 100% convinced that Agile can work anywhere.

But without trust, it’s going to be a very difficult and painful process.

Talk to Us Today



post =