Is it important to have a team of super stars to succeed?
By superstar I mean someone who knows their subject, completes tasks efficiently and to the highest standard as well as driving thinking in their area. Sounds pretty good to have a team of these guys? But in reality, a team’s success is built on bringing the weakest members up to standard rather than elevating already successful performers.
You are the weakest link, Goodbye!
Let’s go back to my favourite analogy: Soccer!
David Sally in his book “The Numbers Game: Why Everything You Know About Soccer Is Wrong” says that Soccer is a “weakest link” sport, which means that the squad is only as good as its weakest player. It has been statistically proven that by improving the weakest players in a team you can have a more significant impact on overall performance than further enhancing the strongest players.
I know that this is true for software delivery teams as well – you can only deliver as fast as your slowest team function. Notice I say function rather than team member. In any software team there are several functions: Backend or Frontend Developers, Product Owners, UI/UX Designers, Testers and DevOps. Most of the delivery items will need to go through each one of these functions. If one is weaker than the others it will cause a bottleneck in the flow of work through the delivery process.
If you have a superstar before the bottleneck, it will cause more of a queue if it is after the bottleneck they will be starved of work and won’t be efficient.
How do you spot where the team’s weak points are?
You can use Cumulative Flow Diagrams (CFDs) to spot where there are bottlenecks in the process. CFDs help you visualize workflow progress and stability over time. They are area graphs that depict the quantity of work in different states, showing arrivals, time in queue, quantity in queue and departure. You can use them to spot in which stage your tasks are taking longer to complete. If one of the stages is taking longer this would indicate that there is a bottleneck in this area. See the example below.
In this example you should spend time working with the team members who are responsible for Deployments to see how their skill needs to be increased.
But don’t rely solely on CFDs to work out weak points, you should also use quality indicators such as:
- Are there a lot of bugs found in production? This indicates that testing needs to be improved.
- Do we get feedback from users that the UI/UX is complicated? So you need to work on UX design improvements.
- Is the expected outcome not achieved after delivery of a new feature? There is a weakness in product design which needs to be improved.
How do you fix weak points?
Just like a soccer manager, David Sally suggests concentrating on these three strategies when improving your team’s overall ability:
- Recruitment Strategy – teams might benefit more from investing in solid, reliable players to fill weak spots rather than spending heavily on one superstar.
- Training Approach – coaches should focus more on bringing up the level of weaker players rather than solely developing top talents.
- Team Dynamics – creating an environment where stronger players mentor and inspire weaker ones becomes crucial.
Hidden Skills
To improve the overall ability of your team you should also seek out “Hidden” skills in the team. These “Hidden” skills can supercharge the productivity in your team by unlocking untapped potential, matching employees with roles that align with their natural strengths as well as boosting individual and team morale.
These “Hidden” skills can be categorised in four ways:
- Leadership and Communication Skills – for example, can the tester be capable of training team members, or can a developer be a talented team lead?
- Practical Skills – this could be a backend developer who is programming iOS apps in their spare time.
- Personality-Based Hidden Skills – does a team member have good organising skills and therefore be a good match for the Scrum Master role?
- Unique Personal Talents – such as creative problem solving or attention to detail which can be used to enhance the team environment.
Finding “hidden” skills doesn’t need to be complicated. I’ve found these strategies work well:
- Observe and Challenge – pay attention to how team members conduct themselves and if you can spot a skill that they don’t use in their day-to-day job then challenge them to use it more e.g. if they show capability in their presentation skills then get them to present user demos.
- Conduct skills surveys – implement formal assessments or surveys to identify other skills.
- Conduct 360 reviews – ask each reviewer to identify skills they see in the reviewee. They may be surprised what other people say about them!
- Celebrate unique talents – praise all skills including those unrelated to work. This builds trust, connection and keeps the team energised.
Diversity
Your team needs to play Total Football!
If you haven’t heard of it before, just let me explain a little. Total Football was a groundbreaking tactical model that emerged from the Netherlands, during the 1960s and 1970s. It is characterised by flexibility in player positions on the pitch as well as collective responsibility. The strategy allows any outfield player to seamlessly switch positions which creates a dynamic and unpredictable playing style where players are expected to understand and execute multiple roles on the pitch.
This strategy of flexible roles could work well in software development teams. If they understand another team member’s job, they can be sensitive to how they need to interact with them. For example, developers can experience the QA role (temporarily), and by doing so they will learn first-hand the frustrations of the testers and change how they interact with them in the future. When there was a communication issue in one team I was heading up, I successfully moved developers to work on automation in order to reduce conflicts with the testers job after sharing the role.
By being a bit more flexible in assigned roles, you also have less key-man dependencies – which is to be avoided.
Role-sharing in practice
A few examples of successful role sharing:
QA and Developers, Devs can test and QA can code
DevOps and Devs, Devs can deploy code and DevOps engineers code
Scrum Master and Product Owner – Scrum Master works on specifying a feature, Product Owner conducts the team rituals
Roundup
If you can elevate all team members to the same standard, find hidden skills and build in some flexibility in roles, you will have an all-conquering team which will succeed in any situation.
Let me know how you get on.
This is my fourth blog on how to create winning teams. I have already discussed motivation, tactics and fitness. You can read them HERE.
Pragmatic Agile 