Zen and the Art of Building a Great Software Team
More often than not you cannot pick and choose the people you want; if you are fortunate enough to be in this position then this article may change your outlook on which it is best to pick. If like most managers you need to make the most of what you have been given, then don’t despair there are some tips here for you also.
If we are experienced then it is highly probable that we have experience of working in highly effective teams and also poor performing teams. Identifying the magic ingredients that make a team great is not necessarily obvious, but there is some common (non software related) psychology that plays a big part here.
What makes a great software team?
There is a misconception that an articulate and charismatic leader is what makes a great team, although this can contribute it is not necessarily a requirement for an effective team. Different leadership styles can be equally productive; the mix of personality types within the team and their assigned roles plays an equally important part. Having effective teams is essential for businesses to be successful; hence it is not surprising that there are literally thousands of teamwork psychology studies out there.
Everybody has a different personality but personality is testable via questionnaire and can be categorised and grouped. There are a several different popular models out there, but my personal favourite is the Belbin ®, it has become widely used in all sorts of team training and it seems to make sense to most people. Dr Meredith Belbin, UK academic and consultant originally identified eight key team roles, latterly extending it to 9. Essentially people’s personality means that they naturally adopt one or more team-role types when placed in a team. Small teams will mean people are more likely to adopt multiple roles.
|Role Name||Strengths And Styles||Software Team Characteristics|
|Shaper (SH)*||Motivated, energetic, achievement-driven, assertive, competitive||Highly enthused often pragmatic, may force a point to get results.|
|Plant (PL)*||Original thinker, innovative, inventive, imaginative, unorthodox, problem-solving||Ideas man, ideas may be radical or highly original. Maybe a “prototyper”|
|Monitor-Evaluator (ME)*||Serious, prudent, critical thinker, analytical||Objective and may speak up if team is wasting effort on an unnecessary task.|
|Implementer (IMP) *||Systematic, common sense, loyal, structured, reliable, dependable, practicable, efficient||Breaks work tasks down into manageable logical chunks.|
|Resource Investigator (RI)*||Good communicator, networker, outgoing, affable, seeks and finds options, negotiator||May spend time away from the team, finds out what other people are up to. Can be a liaison with other work stakeholders.|
|Team Worker (TW)*||Supportive, sociable, flexible, adaptable, perceptive, listener, calming influence, mediator||Actively tries to hold the team together at times of division or stress.|
|Completer-Finisher (CF)*||Attention to detail, accurate, high standards, quality orientated, delivers to schedule and specification||Permanent sense of needing to finish things urgently. Checks completion of tasks. Can be rare in software circles.|
|Specialist (SP)*||Technical expert, highly focused capability and knowledge, driven by desire to meet high standards and dedication to personal subject area||The “geek” on the team, highly useful but can go down the wrong path or a path that is too difficult for the rest of the team to follow. If managed properly Specialists are great assests.|
A good software team is made up from a mix of personality types. You may think that all you need is a coordinator and a bunch of specialists. But a team with an inappropriate mix of personality types will not be efficient or work well together. Personality test information is available via the Belbin website.
Classic Software Team Assembly Pitfalls
I am sure that most of us have worked in software teams where the atmosphere is polluted and it is hard to concentrate on the tasks in hand. Or alternatively in teams where people are all doing their own thing rather than coordinating effort. The classic response to this is to point the finger at the particular team members and complain. A better response is to train staff to work more effectively together or to physically change the makeup of the team. The preferred way of doing this would normally be to keep the same team members, but reassign some of the roles and responsibilities of each team member. Try hard to get people into roles that maximises their natural team contributing skills.
If you are looking to expand an existing team, it may be worth taking a step back and thinking what the team’s biggest obstacle to being productive is, then look for a new team member that can help overcome that obstacle e.g.:
|Software Team Issue||Could be resolved by|
|Failing to complete tasks, or skimping / underachieving||Coordinator or Finisher|
|Regular conflict||Team worker or experienced coordinator|
|Mediocre Results||Resource Investigator, Shaper, Specialist or Plant – determine cause before making appropriate choice!|
|Bugs or Mistakes||Evaluator|
A shaper can help get new teams up and running, for high-risk situations e.g. safety critical software development a competent evaluator can be very beneficial.
Dealing with conflict in software teams
Constant eruptions of conflict in a team are damaging to morale and productivity. In the UK it is common place for teams to debate an issue before making a decision on the way forward; whereas in some other countries there is more of a subservient culture. Whatever you’re particular culture or working environment conflict should be tackled as soon as it becomes a minor problem and before it becomes a major issue. Productive teams find a natural balance between expressing differences of opinion (and thus encouraging creativity) and going along with the consensus (to get the job done).
The key is to get a consensus on the big important decisions, if team members need convincing be sure that the evidence is there to back a decision, or be prepared to change your mind or accept responsibility if it does not work out. Ensure every team member has an opportunity to express their views (remember some personality types will need to be encouraged to contribute, others will not).
If conflict is a problem, it is worth checking that team members are in their most appropriate roles. To solve a conflict get both sides to state their position clearly and the assumptions that they have made to justify their position, ask them to present their position and give them the opportunity to do so without interruptions. Sometimes having to present a position with assumptions is enough for somebody to self evaluate their position and change their mind.
If after presenting opposing positions the conflict cannot be resolved, it is a good idea to break the conflict down into smaller parts. This can be achieved by analysing each assumption in turn and verifying how truthful it is. If it is truthful establish a consensus on its impact on the final outcome. This action can help to sway an argument.
Finally if these techniques do not work, consider bringing outside expertise in. An outsider can facilitate a technical discussion using a formal process, which includes talking to team members individually (enabling team members to express their position without fear of other team members opinions) , and then reporting findings.
Evolving the software team
A good team leader will help to evolve the capability and proficiency of their team. A company that encourages this can find itself with teams that are dependable to get the job done; these teams are often transferable between projects and with a little adaption time between methodologies, toolsets and software languages. Dependable teams are often small but very productive, all too often in software projects are bloated with too many engineers in too larger teams.
To evolve a team the first step is to get the right balance of team members, ensure that the team is not overly dominated by one or two personality types. Invest in the team members, money spent on the right training just ahead of when it is needed may seem like a cost, but in our experience the ROI is very short indeed.
Each software team member should not only develop their technical analysis, design, programming and test skills; they should also develop a mature understanding of the software process, coupled with good “domain knowledge”.
Productivity can be improved greatly with integrated software development tools. Investing in good tools and automation techniques can yield significant improvements in delivered working code, providing that the tools are well chosen and fit for purpose.
We believe this article (although brief) to be accurate. If you have comments or suggestions, or believe there are inaccuracies in this article - let us know, we appreciate your feedback.
The author (Rob Harwood-Smith) has been developing software from the age of 10, his experience ranges from being in software teams to leading teams and projects for a varied range of client types. Rob is a senior consultant and joint founder of Flexible Software Solutions Ltd.