Trust
Trust. If you read about Agile you will see this word. If you read about implementing Agile you will see it even more.
There’s a good reason for this. Trust is important to the success of Agile. Without trust from the organization a team will not function at the level expected.
Thing is, there’s a piece of this that is missing from almost every discussion of Agile I read. The team has to trust the organization.
Though it is mentioned by everyone it bears repeating that the organization wanting a team to go Agile needs to trust that team. The team needs to feel safe in trying new ways of working. They need to know that it’s fine for them to take on less deliverables this week so they can try a new way of providing those deliverables. It has to be just as OK for that experiment to fail as it is for it to succeed.
This isn’t the whole story though. Far fewer times will you read about the need for a team to trust the organization in an Agile transformation. In fact, the organization is often depicted as the bad guy. After all, they are the ones that got us into this place where we need to learn Agile, why should they be trusted?
The Agile Manifesto was created by a group of software developers. The majority of practices used by those developers were evolved as a way to escape the heavy methods being forced on them by their organizations. The manifesto was created 14 years ago. It’s time to release the grudge and trust the organization.
People learn and change. Those in charge of organizations today may have led teams that experimented with Agile methods 15 years ago. At the very least upper management can see the success of Agile in other organizations. The fact that they are pushing, or at least open to allowing, a change to Agile methods means they have probably learned a little about it along the way. Not only that, but some non-developers will be part of the team.
The Scrum Guide tells us that a scrum team consists of not only the development team, but also a Product Owner and a Scrum Master. Furthermore the Development Team, while only consisting of “Developers,” is cross-functional. The team members are Developers only in reference to the team they are on. Their day-to-day job duties could be that of a Marketing Analyst but they are still considered a Developer by the rules of Scrum. This is an example of course. Agile is much bigger than just Scrum. Considering that Scrum is already much bigger than just software developers or the Development Team it stands to reason that Agile is about much more than the team.
Where this really starts to be seen is in the teams ability to trust those outside of the team. The team needs to trust that the Product Owner really does know what’s best for the product. They need to believe that the Agile Project Manager cares about the team as much as the project. They have to realize that upper management wants their product to do well in the market.
Trust is a two-way street. We as Agilists need to remind the team we coach to trust the organization just as loudly as we tell the organization to get out-of-the-way and trust the team to deliver.
How do you deal with a lack of trust for the organization in your teams?
