This seems like a very basic question, but I have found myself asking it again and again. Seems like so many teams never really question what exactly it is that makes up a team.
In an Agile environment this question has even more relevance as the focus on teamwork is greatly emphasized.
Teams have a common objective
The most important component of a team is shooting for the same target. The smaller and more defined the target the more tightly bound the team.
Consider the famous TV team “The A Team.” Each episode of this television series the team is tasked with a common goal of some sort. This pursuit of a common goal is one of the main components that binds them together as a team.
Sports teams provide an even better example. In all team sports the entire team has the objective of winning. More specifically though, there is always some other sub-objective that the team is involved in. The more “team-like” the sport, the more the entire team is involved in that objective.
I have found that it is exactly the same in software development. It is important to try to find small goals that focus the entire team. When differing members of the team have different objectives, you may be operating on a team, but you might not be operating as a team.
This difference is critical because teamwork often produces synergy. Synergy is when 1 + 1 = more than 2. It is when skills are combined together to produce a greater result than the sum.
If you want to increase the feeling of “team” over individual, reduce the breadth of work going on at any given time and focus everyone on the same small goals.
In Agile this looks like having more team members working on a single backlog or story and reducing the number of stories that are put into progress at any given time. Try putting a strict WIP (Work in Progress) limit on your team to force the team to work together and have a common objective.
Teams fates are bound together
Teams fail or succeed together. I’m not much of a follower of professional sports, but I know from TV dramas produced about them that when different team members fates are not intertwined, teamwork breaks down and all hell breaks loose.
This seems obvious, but it is worth taking the time to consider whether your team members fates are truly bound together or not.
Want to find out quickly? Here is a mental test you can do. Pretend that one team member completely fails to do the work that he or she is responsible for. Does the entire team fail at that point? Do some team members get accolades and others get scolding?
If you honestly ask that question, you might find that indeed your team members fates are not bound together.
It is absolutely critical for a team to equally reward members at the failure or achievement of a particular goal!
Call out the over achievers and you will destroy teamwork to create developer heroes who step outside of the team’s workload to do special tasks and take on herculean efforts in order to gain recognition.
Call out the under achievers and you will also destroy the team, creating an environment conducive to backstabbing and snitching. One in which no one wants to be at the bottom of the totem pole, so everyone steps on everyone else's heads and fingers to climb over them.
Don’t get me wrong here. I am not saying to never evaluate the individual and promote or reward them. I am just saying evaluate an individual in regards to their contribution to the team achieving the team’s goal.
Focusing on the team’s success or failures encourages team members to help each other, share knowledge and work together.
If I know that I am being evaluated based on what I get done versus what the team accomplishes, I am much less likely to spend my time helping other team members complete their work. This isn’t to say that I don’t like helping others and collaborating, it is just common sense to prioritize what you are being evaluated on first.
Bottom line is, if you want to make a successful team, make sure that successes and failures are shared. Sure, sometimes the whole team is going to be doing pushups for one team member’s mistakes, but it will force the team to deal with that weakness.
Teams deal with their own problems
Nothing demotivates a team more than bringing external influences into a team to control their fate.
Teams should control their own destiny. It is much better to give a team a problem and ask the team to deal with it than to task a particular team member with a special project or responsibility.
Teamwork is all about sharing the burden. This is closely tied to the idea of fates being bound together.
Imagine this scenario. You have a team that has a common objective. They have their fate bound together. But, you come in and give one team member a special responsibility or assignment.
How does this team member view the world?
Differently than the rest of the team. Now they have to competing goals. The team’s current objective and their special objective. Most people in this situation tend to ditch the team in favor of taking care of the responsibility that is squarely on their shoulders.
A better way to handle this situation is to give that “special task” to the team itself. Let the team figure out how to get it done. And let the completion of that objective fall squarely on the team and not on any individual.
If this is a little too scary, you might consider having a team lead. This is a bit contrary to most Agile preachers, but in reality most teams have captains and leaders. Take the extra step and let the team decide who the lead will be.
This brings us to another way team should deal with their own problems…
Teams should be responsible for both bringing new members into the team and kicking them off the team. Interpret this as you will. But teams have to deal with their own problems. If they need more resources, they need a way to get those resources and if someone isn’t pulling their weight, they need to either deal with it or vote that team member off the island.
Applying this to Agile
I covered a pretty large amount of ground in this post, so let’s wrangle it all together and see how to effectively apply this to an Agile development environment.
Here are a few of my tips to improve your Agile team:
- Most important! Set the team on a common objective by only allowing 1 or 2 backlogs or stories to be worked on at once, regardless of the size of the team. (Imagine what would happen if a sports team had different team members focusing on different objectives. All chaos would ensue.) It is alright to have individual members focusing on different tasks, but those tasks should belong to a common objective. Is this painful? Hell yes! Does it feel inefficient? You bet, but the team will find a way to work together to be efficient.
- If your team is too big to have a common objective, break them up into smaller teams. It is better to have smaller focused teams than big teams with split objectives.
- Don’t split the responsibility based on roles. If a team shares an objective, then that team should see it all the way through. You may have developer, QA people, and business people all on the same team, so it is difficult to break the mindset of “I do this, then this other person is responsible for the next step and so on.” Instead the mindset should be “as a team we need to get this feature defined, developed and tested.”
- Never reward individual heroics and never call out individual failures. This is hard, because it goes against one of my personal principles of always calling out both commendation and condemnation publically, but in a team setting it has to be the team that is called out, not the individual. Trust the team to deal with the individuals.
- On the flipside, reward the entire team for success, call out the entire team for failure.
- Always give a task to the team, preferably in the form of a backlog or story. Never give a task to an individual.
- Let them team decide how to handle any given responsibility. Teams tend to find fair ways to assign and distribute work.
- Never hire unless the team approves.
- Never fire unless the team approves.
- Don’t make team members evaluate each other. This will cause them to compete against each other and to think about merits as individual accomplishments versus team accomplishments.
- As much as possible let the team run itself. If a team is not performing, you might need to appoint someone as a leader or facilitator of that team and give them the responsibility of improving the team’s performance, but in most cases teams figure out how to operate best when left to themselves.