Dysfunctions of (Agile) Teams

Over the holiday break I read Patrick Lencioni‘s “The Five Dysfunctions of a Team: A Leadership Fable“.  The premise is that each dysfunction builds upon the dysfunction before it.  Much like Maslow’s Hierarchy of Needs.   Below is an illustration of the dysfunctions with absence of trust being the building block of dysfunction.

Running multiple organizations and being part of an agile team gives me ample time to see team dynamics and participate in them on a regular basis.  This book really made me think a lot.  The information wasn’t particularly new, but it reminded me that much like agile, leadership of a team can be simple yet insanely difficult at the same time.

Absence of Trust
For some reason most teams think that if they all get along they have some super team work trust going on, but if there is any conflict what so ever that the team is some how not in harmony and that all is wrong with the world.  I remember early variations at Integrum where this certainly was the case.  The truth is that Trust is all about comfort in being vulnerable.  On an agile team this vulnerability is necessary because the only way to continually improve towards excellence is to be honest about your deficiencies.  If someone doesn’t feel they can be open and honest in their weaknesses and mistakes this can never happen.  What is your team doing to build trust and encourage vulnerability?

Fear of Conflict
The biggest smell of a dysfunctional team to me is one that agrees on everything and never has conflict.  Without conflict there are things being left unsaid.  In the end this is just unhealthy.  Willingness to have healthy conflict allows unfiltered and passionate debate about new and innovative ideas.   A good agile team is a “noisy” team.  I think the same goes for pair programming.  If a pair isn’t regularly in heated debate they probably aren’t trying very hard.

Lack of Commitment
I am starting to think that commitment is one of the most powerful words in agile software development.  Healthy teams don’t make excuses.  They don’t blame or shirk responsibility.  The get on the same page and drive towards completing the goal.  Deciding on what to commit to and then measuring to that commitment is key in building a strong team.  I have long thought that accountability was a major problem with no solution, but I am reminded that it’s probably a lack of commitment to blame.

Avoidance of Accountability
This is so so so so difficult.  As calling peers out feels so unnatural.  Who am I to tell you what or how to do something?  What authority do I have over you?  In reality if we have a shared commitment, I am doing both of us a disservice if I don’t speak up and hold you accountable.  It just never feels that way when it’s time to step to the plate and do it.  Recently I was told by someone to RTFM (Read The Fucking Manual) and it kind of stung.  It made me realize that I demand a lot, but at a bare minimum I wasn’t able to perform a basic function of one of the teams goals towards quality.  How embarrassing.  I wasn’t angry.  I was glad.  Their commitment to the goal and trust that I wouldn’t blow up over such a conflict ultimately improved what I was doing.  That’s how agile works right?

Inattention to Results
So often in the past people on our team were driven by ego, career development or recognition.  I childishly called them the “What about me’s?”.    Ultimately the one to blame is not them, but myself.  Failure to give them goals to commit to, left them no choice but to think selfishly.  It’s something that I painfully work on in everything that I am involved in, because frankly it’s hard work.  Guess I need to quit making excuses.

Patrick’s observation in the final summary seemed too fitting for an agile team to not share…
Ironically, teams succeed because they are exceedingly human.  By acknowledging the imperfections of their humanity, members of functional teams overcome the natural tendencies that make trust, conflict, commitment, accountability, and a focus on results so elusive.

For the first time I feel like Integrum has a team that is human.  It might just be that we are starting to achieve that right level of imperfection to function as a committed team.  Makes me feel pretty lucky and excited!

Accountability Is Painful!

Part of doing agile development means being accountable and transparent. Recently Integrum has started to step up it’s path towards excellence. The team felt that testing was not being all that it could be and more importantly that it wasn’t visible enough. We have a “FAIL board”, which a large screen TV out in the open, that shows all current projects with failing builds. Last hacknight Jade and Clayton made a plugin so that setting up a new (or existing) project on Cruise Control is completely painless. (Will work on publishing it in near future)

All projects were immediately added to CruiseControl. All developers were then required to get their builds passing. One project got “built” really fast. Seems they had no test specs or features. Of course, the easiest fix to this problem was to run a little script to build all the spec/feature files and create mass failure. (Will work on publishing it in near future) It only would be fair to then call out to the entire team the Shenanigans!

Accountable

Names cut out to protect the innocent. I <3 this team!  Where else do you get to work with evil?