Why Teams Don't Work

This title does not seem to fit with today’s mantra of building teams, creating high performing teams, spinning up Agile teams, now does it?  Yet it seems to be a popular choice for those trying to teach the fundamentals of teamwork.

Why Teams Don’t Work

The Harvard Business Review published “Why Teams Don’t Work – An Interview with J. Richard Hackman” in May 2009.  Hackman maintains that in order for teams to “create magic”, they must be real.  When asked to expand on what this means he noted that his research yielded fewer than 10% agreed who was even on “the team”.  He notes that not everyone who wants to be on the team should be included and some individuals should be forced off.

Think about this as it relates to Agile or Scrum teams.  It is well-known and taught that characteristics of Scrum teams include:  members are self-organizing, cross-functional and 100% dedicated.  Yet many organizations ignore this, decide the teams for the people doing the work and tell them that they are now on a team.  Or worse, on more than one team.  Maybe Hackman is on to something in saying teams don’t work because these organizations say they want to adopt Agile or Scrum, ignore characteristics that enable team success and then say things like “Scrum doesn’t work”.

Harvey Robbins and Michael Finley chose this title, “Why Teams Don’t Work” for their book also.  It won the 1995 Global Business Book Award.  They also agree that team members do not have to be best friends but they have to agree that they are on the team and not engage in “turf wars”.  The team has to focus on a common goal and to agree on what that goal is.

Once again this resonates with what we teach Agile and Scrum teams.  One of the Scrum values is Focus.  Requiring a team to be 100% dedicated allows them to focus on that common goal which increases the likelihood they will achieve it.  As opposed to splitting their focus and losing valuable time to the act of context switching between competing goals.

Many who attend Collaborative Leadership Team’s Certified ScrumMaster Class or Agile Boot Camps seem surprised as we talk through the team characteristics.  As class participants paint one picture after another of challenges they face, we find ourselves asking them “Is this a Scrum problem?  Or a people problem”?  They sigh as the realization occurs to them that they don’t have “Scrum or Agile problems” but what these collaborative, transparent frameworks have exposed is the people challenges.

So how do we get better at this people stuff?  If only we had a dime for every time we got this question.  With all sincerity we tell people to read “The Five Dysfunctions of a Team” by Patrick Lencioni, “How to Win Friends and Influence People” by Dale Carnegie and absolutely anything Dr. Phil has written.

The Scrum Master’s job is not about administrivia and is about getting people to work together to deliver business value.  Old ways of doing work allowed us to hide from the people stuff.  We could hide behind design documents, requirements documents, status reports, etc.  With Agile and Scrum approaches, the emphasis is on people instead of the documents leaving many wondering what to do with this new approach.

Don’t have time to read?  Three easy tips for any new ScrumMaster to get started in focusing on the people stuff include:

  • Really listen.  Do not “wait to talk”.  Do not type or write as someone talks.  Look them in the eye and really listen to what’s being said.
  • Actively facilitate. If someone is interrupting, have the courage to ask them to wait until the person speaking is finished before jumping in.
  • Ask questions. We take other peoples’ power away in subtle ways – usually by telling them what or how to do something.  Every time you are tempted to make a declarative sentence, ask a question. This will invite team discussion and enable them to reach their own decisions.  Far more empowering.

Want to learn more skills for working with teams?  Join us as we welcome Harvey Robbins, Ph.D., L.P. for his Creating High Performing Teams workshop November 12: