December 20, 2010
A big part of project management is working to grow a high performing team and then caring for that team so it stays healthy and productive. Agile concepts around empowered teams and team decision making support these goals and so there should be no surprise that agile project management aligns well with team development best practices.
However, it never hurts to better understand some of the things that can go wrong on teams so that we can quickly take action and hopefully resolve issues before they become full blown team problems. Patrick Lencioni’s book “The 5 Dysfunction of a Team” lists the following 5 common problems that build on from each other to undermine trust and eventually performance.
1) An absence of trust – an unwillingness to be vulnerable and honest within the group.
2) Fear of Conflict – Teams that lack trust cannot engage in unfiltered debate. Instead they resort to veiled discussions and guarded comments
3) Lack of commitment – without passionate debate, team members rarely if ever, buy in and commit to decisions, though they may feign agreement during meetings
4) Avoidance of Accountability – Due to the lack of commitment and buy-in most people will hesitate to call their peers on actions and behaviours that seem counterproductive to the good of the team.
5) Inattention to results – Failure to hold one another accountable leads to putting individual goals (or department goals) ahead of the project.
Fortunately agile methods and some common sense offer many tools and values to address these issues...
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.
In my experience, these 'dysfunctions' are a symptom of something bigger - a lack of a learning culture, no slack time to experiment or learn anything new, management being intolerant of mistakes so that it doesn't pay to try to improve. When management keeps driving the team to meet deadlines and do a certain quantity of work, instead of truly letting teams self-organize, teams will respond in bad ways. When management tells people "Don't ask questions, just do as you're told", when the business management does not have a commitment to quality - how can the team have any kind of trust or commitment? When I see these problems, I look for the answer higher up. Of course, it's very difficult to effect change there.
Posted by: Lisa Crispin | December 23, 2010 at 12:31 PM