Functional Teams

This content is syndicated from LeadingAnswers: Leadership and Agile Project Management Blog by Mike Griffiths. To view the original post in full, click here.

Functional Team 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.

Leave a Reply

Your email address will not be published. Required fields are marked *

fourteen + nine =

There are 101 ways to do anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”



To explore how we can help you, please get in touch