Building Trust by admitting mistakes. We have to generate an environment on the project where people can see that it is OK to admit mistakes, ask what they think may be dumb questions, and no one will laugh at them, ridicule them or make them feel bad. The faster we can all improve our business and technical domain knowledge the better.

Project managers have a great opportunity to model the desired behaviour. We can admit our own mistakes “I made an error on the status report and will be sending it out again today”, ‘I forgot to add regression testing effort to our estimates and will redo them”. Seeing the PM admit mistakes sets the stage for other team members to do the same. As my first crusty old PM used to tell me; “We only have two hands to work with, and if you are always using one to cover your rear, your productivity will only be 50%”. Daily stand up meetings where issues and impediments are discussed are also good opportunities for describing problems.

Promoting Constructive Conflict – Getting your team members arguing sooner rather than later may seem a contrary notion, but the “Performing” phase of team progression is later than ‘Storming” for good reason. Passionate debate on issues is necessary to build strong commitment for the outcomes.

Team based estimation models like Wideband Delphi and planning poker are great ways to get the team members debating and discussing work. Estimates and decisions forged from the fires of heated debate generally have a lot more commitment behind them.

Confirming Commitment – we learned that without passionate debate, team members rarely if ever, buy in and commit to decisions, though they may feign agreement during meetings. So we need to build commitment for decisions and test it.

This can take the form of getting team commitment for the work estimated for an iteration. “You guys have estimated these 15 stories can be developed this iteration, are you good with that, shall we present it at the planning meeting?”. Tracking velocity (work done per iteration) is a great way of confirming delivery commitments. The iterative nature of agile projects and the use of frequent retrospectives are also effective ways of confirming commitment. “What did we say we would do? What did we actually do? Let’s understand the differences, etc”.

Driving Accountability – poor accountability due to a lack of commitment and buy-in will cause people to hesitate on calling their peers on actions and behaviours that seem counterproductive.  Agile practices like pair programming can keep people honest in coding by identifying the lazy kludge as it is being written

Short deadlines focus the mind too; we no longer have 4 months of requirements gathering before handing an anonymous specification document off to an unsuspecting development team. Working closely with BA’s, Devs and QA the impacts of short cuts and bad judgement are quickly discovered and transparency is high, leading to better accountability.

Being Results Focused – Agile projects rarely fall into the trap of inattention to results by not holding one another accountable or putting individual goals ahead of the project, since they are so results focused. The application demo’s at the end of every iteration shows the functionality developed. Project metrics like burn down graphs and burn up graphs focus on results (how much work is left) and (how much work has been done vs. how much is still remaining).

The agile manifesto’s “Working Software is the primary measure of progress” speaks to this too. We do not track percent complete against activities of unknown business value “e.g. we are 50% complete the Change Control Plan”, instead we demo the Order Entry module and discuss the upcoming Reporting functionality – it all tends to be more results focused.

Advantages and Disadvantages
While agile methods are certainly aligned with addressing the 5 Dysfunctions of a Team, we should not get all complacent and self congratulatory. Plenty of agile projects fail, plenty of agile teams are dysfunctional, and sometimes the greater autonomy offered by agile methods make diagnosing and fixing agile teams all the more difficult.

Agile teams also seem more prone to influence from toxic team members that can poison the whole team environment. At least with a command-and-control, waterfall approach you could give a toxic individual a big fat spec and tell them to go off and work on it for a couple of weeks, reducing their team impact. Now with much higher levels of collaboration and communication those bad feelings and undermining attitudes have a greater impact on the team.

So while agile methods leverage some great tools for building trust, commitment, accountability and results we still need to work hard on team issues. Another way to understand the Dysfunctional Model is to look at the positive team attributes that lead to productive, cohesive teams and try and promote these behaviours:

1)    They trust one another,
2)    They engage in unfiltered conflict around ideas,
3)    They commit to decisions and plans of action,
4)    They hold one another accountable for delivering against those plans,
5)    They focus on the achievement of collective results

Focusing on these behaviours and tapping some of the agile tools and values can help develop more functional team traits.