How can this team really work together?

How can this team really work together?

I recently got a question from a long-time reader and listener.  I have removed the name to ensure confidentiality.


  • The person who asked the question is an experienced Agile leader.
  • The team is not all technically-equal full-stack developers, some developers work on UI stories and others work on backend stories.
  • The team has 8-10 people.

The Problem:

  • During story grooming/sizing, the entire team does not participate equally to offer up their points. UI developers participate on UI stories and are reluctant to chime in on backend work, and vice-versa.

The Question:

  • Scrum seeks to involve the entire team.  How can I get everyone involved (or should I)? 

Both questions are interesting questions.  I answered with some advice and some follow-up questions.

Further Thoughts Part 1:

  1. Do you really have two teams that you have grouped together into one for organizational purposes?  Are the stories on your backlog related to each other or could you have two separate backlogs with the resultant code implemented separately?

It is possible that although the organization has decided that this group of people are a single team, they really represent two separate teams serving different masters and pursuing separate goals.  If that is true there is no reason for them to act as a single team.  That said, I suspect the segregation driven by specialization is the real issue.  The leader (who may or may not be the organizational manager) needs to work on breaking down silos.  Historically organizations have adopted the manufacturing model as a tool to increase task efficiency. The manufacturing model does not fit software development and maintenance perfectly and often causes local optimizations, which rarely produce the most output (flow) from the system.  Therefore . . .

Further Thoughts Part 2:

  1. Could you reshape your stories so that they would include both UI and backend programmers?  This would create a scenario where they have to collaborate and it makes co-estimating more than an academic exercise.

Reshape the user stories to represent thin slices of the functionality so that someone from each silo needs to be involved in order to deliver. Functionally slicing the stories creates a reason for UI and backend personnel to coordinate and collaborate.  Creating scenarios that both facilitate and require collaboration will give each silo a reason work together in deciding how much work to commit to in a sprint as a team.  The thin functional slicing drives home the point that unless the story works in production and meets the business need, it isn’t done.  Note: sometimes a story will only impact the back or front end (although I suspect there would need to be testing), but these should be relatively rare IF this is a single team.

Further Thoughts Part 3:

  1. Perhaps this is a scenario where pairing might be an interesting approach to getting team members to have a single vision.

The XP practice of pair programming is when two people and one keyboard collaborate on programming.  In this scenario, put a UI and backend person together with a single story, a single keyboard and then lock the door (ok, that’s a little hyperbole).  This practice will help break down barriers.  Another possible solution is to try mob programming on the first day of the sprint (one keyboard and the WHOLE team collaborating together).  Mob programming on the first day of a sprint is a fantastic tool to get the team moving in the same direction and to focus on common issues.

There are other possibilities, such using a test-first approach (perhaps start with acceptance testing driven development), to help involve business community.  I have occasionally used ATDD to help get lots of eyes on a problem.  All of these topics should be addressed in a retrospective. Until the team recognizes that they have a problem, it will be tough for them to commit to a change.