Often a key ingredience of making agile work for an organization is trust. For an organization used to more traditional ways of doing things it’s hard to let go of the command and control style and trusting the team to be self-organizing. Also, trusting that the team (who is actually doing the work) knows best what needs to be done and trusting their estimates of how much work needs to be done can also be a challenge. This also goes the other way – where the team trusts the organization as a whole to support it, remove impediments and to foster a healthy environment for trust to grow.
This being said, trust is important outside of agile as well. A brilliant take on this is from Patrick Lencionis book “The Five Dysfunctions of a Team”. The first dysfunction you need to handle to be able to get anywhere with teamwork is the abscence of trust.
Teams that lack trust waste inordinate amounts of time and energy managing their behaviors and interactions within the group. They tend to dread team meetings, and are reluctant to take risks in asking for or offering assistance to others. As a result, morale on distrusting teams is usually quite low, and unwanted turnover is high.
Whether or not you are in a self-organized agile team or you work in a more traditional way, micro management is a clear indicator of lack of trust. Not only is micro management something that affects motivation among people in the organization, but it also is wasteful. Letting the ones that actually have the technical skills make technical decisions is a proven good way to do things. This opposed to having the manager with little to no technical skills decide which database technology best fits your purpose. A traditional belief among managers is that whenever hands are not on keyboard – no work is being done. This of course is wrong since creating software is knowledge work. Knowledge work requires thinking, discussing and exploring options. Managers have to trust that the right things are being done to achieve the end goal.
Also, to really drive good communication and debate around decisions that needs to be made on architecture, design, requirements, team composition or whatever else that needs to be discussed to achieve results – trust is needed. A lack of debate around these topics or any other topic that is important for achieving results is a sign that trust is abscent. What really is needed is vulnerability-based trust. Trust of predicting behavior is of course important, that is trusting others to do what they are supposed to do, the best way they know how to. Vulnerability-based trust is even more important. A team that trusts each other to take risks and speaks their mind will drive healthy debate and fear of conflict will go away. To achieve this kind of trust it is a matter of parking your ego, and focusing on collaboration over competition with your peers.
When you achieve trust where people are willing to take risks and trusts each other to speaking their minds, people start to challenge each other and healthy conflict will occur. Going along with whatever the manager says or the CEO says in a meeting, just because you don’t want to stir things up is clearly not going to achieve good results in the end – particularly if his or her opinions are on something he or she really don’t know that much about.
All in all it is absolutely a shift in mindset that needs to be done. Trust of predicting behavior is step one and this should be fairly straight forward. The next step is vulnerability-based trust and this takes some work to achieve. Trust is essential to achieving results – no matter if you are agile or not.