Category: Uncategorized

Beyond Superstars: How to Strengthen Team Ability for Maximum Success

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.

Diagram from worldofagile.com

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.

The four essential strategies for building a fit, resilient and high-performing team

If you have had read my previous two blogs you will know how to have a highly motivated team with a strong tactical structure to deliver fast but without a fit team you are not going to win.

In soccer about 20% of the goals scored are in the last 15 minutes of the game. There are several reasons for this which include urgency and increased risk taking, but a major factor is fatigue. Team fitness is the third most important influencing factor for a soccer team to win a match. I think this is true for a software delivery team as well.

If the team isn’t fit then it doesn’t matter how motivated they are (and they won’t be for long), or how good the operating model (tactics) are. An unfit team won’t be a high performing team and win the match, the project and achieve the product goal.

A fit software delivery team is a team that:

1.      Deliver as fast as possible whilst at the same time maintaining a stable product

2.      They are accountable for the outcomes

3.      They are resilient to setbacks and issues

4.      They are happy

1.      Fast pace whilst maintaining quality

To deliver quickly whilst at the same time maintaining the quality of the product I suggest you implement the lean software development and DevOps practices described in “Accelerate: The Science of Lean Software and DevOps” (Nicole Forsgren, Jez Humble, and Gene Kim).

In the book the authors describe how to implement these critical practices:

  • Continuous Integration/Continuous Deployment (CI/CD)
  • Automated testing Version control
  • Utilise cloud infrastructure
  • Alerting and monitoring
  • Lean management techniques (limit WIP, visualize work)

and then track these metrics to make sure you’re getting better:

  • Deployment frequency
  • Lead time for changes
  • Mean time to recovery
  • Change failure rate

Forsgren and her co-authors demonstrate that high performing teams share key characteristics: they deploy more frequently, work in smaller, more manageable batches, maintain lower change failure rates, and recover from incidents faster. But I really recommend you go and read the book; it is very easy to read and understand and has lots of other points on cultural changes which I have described in my other two blogs in this series.

2.      Accountability

In a high performing team, every member of the team needs to own the goal and make sure that everything they do is a step towards achieving the goal. In soccer, a left back can have a shot on goal they don’t need to always pass to the striker. The same applies in our teams: if everyone is waiting for someone else to solve the problem we don’t move as fast as we should.

“When everyone is accountable for achieving organizational results, and not just doing her job, the right things tend to happen.”  – The Oz Principle

In “The Oz Principle: Getting Results Through Individual and Organizational Accountability” (Roger Connors, Tom Smith, and Craig Hickman), the authors use the Wizard of Oz as an analogy for accountability. Essentially their message is: don’t expect the Wizard to solve all your problems, you have to do it yourself.

The authors introduce the Accountability Model, which consists of two primary zones:

·       Above the Line – taking ownership, solving problems and making things happen.

·       Below the Line – blaming others, making excuses and waiting for external solutions.

Success requires shifting mindsets and behaviours to stay “Above the Line.”

The book outlines a four-step process to accountability, summarised as “See It, Own It, Solve It, Do It”.

You need to coach accountability into the team. When they come to you with a problem, ask them to come up with the possible solutions and fix it themselves. The team retrospectives give you an opportunity to practice this. When the team identify issues make sure you don’t take responsibility for solving them, discuss possible solutions and then assign the follow-up actions to the team members.

Photo by ThisIsEngineering

3.      Resilience

A fit team can overcome any obstacle, any setback and come back stronger. In soccer, the best teams cope with going a goal behind, losing a player due to injury or having a player being sent off. Your team needs to be able to anticipate, prepare for, respond to, and recover from disruptions.

“Resilience is not about avoiding risks or disruptions; it’s about having the capacity to anticipate, absorb, and recover from them—and even use them as opportunities for growth.”  “The Power of Resilience“

To be resilient you must be flexible and agile. This is where the Agile methodologies come into their own. If something changes you can change your approach almost immediately. You don’t need to follow the project plan created 6 months ago. Agile methods mean you only need to design solutions to problems when needed, and therefore you are not wasting time on tasks that may need to be done further in the future which actually can become obsolete.

Another way of building resilience into your team is to avoid key person dependency. This is where one member of the team has specialised knowledge or skills that no one else in the team has. If that person leaves unexpectedly then performance will be lost. To avoid this happening:

  • Knowledge share, document critical processes, decisions, and expertise.
  • Cross-train, train multiple team members to handle essential roles and responsibilities.
  • Succession plan, identify and prepare backups for critical roles.
  • Automate, repetitive tasks can be automated to reduce reliance on individuals.
  • Encourage collaboration, make the team decide on next steps and solutions to reduce centralized authority.

Risk Identification and Assessment is also important so that you can proactively plan for any disruption. This is large subject which I won’t tackle now as it is deserves a whole blog dedicated to it. I recommend “Waltzing with Bears: Managing Risk on Software Projects” (Tom DeMarco and Timothy Lister). As well as providing the risk management frameworks common across all types of projects, the book also outlines common software delivery issues such as schedule flaws, requirements inflation, specification breakdown and under-performance.

4.      A Happy Team

This seems obvious: to have a fit team they will need be happy and motivated. See my previous blog on motivation for some tips on how to make a team happy (top tip – it is not about giving payrises!).

If you can create a team which delivers as fast as possible whilst at the same time maintaining the quality, and is resilient and accountable you will have an all-conquering team which will succeed in any situation.

Let me know how you get on.

Winning Tactics for Successful Teams

“If football were played by robots, I would win everything.”

Marcelo Bielsa

This is the second blog post of my series on how to build a team that can win. In the last blog I discussed how to motivate the team  and in subsequent blogs I will discuss Ability, Fitness, Motivation, Power and Luck.

No matter how motivated your team is, if your tactics are wrong, you’re never going to win a soccer match. The same applies to business teams – to win you need to achieve an effective work pattern. So in this blog I look at  what tactics are the best, and how you can implement them.

Strategy v Tactics

I see the terms strategy and tactics used interchangeably, but they are at two ends of the scale. The strategy defines the problems you aim to solve in the long term and explains why. The tactics outline how you will approach solving these problems on a day-to-day basis.

The strategy will be hard to adjust, but tactics should change to make sure they are effective or continue to be effective. In software delivery the strategy is defined by the product owner, how to achieve that strategy should be the role of the delivery team. There are many great books on how to define and execute strategy and product management, but here I want to dive deeper in to how to organize a team in order to achieve the strategy.

 “A good team plays with intelligence, awareness, and a good tactical structure.”

Arsène Wenger

My best tactics for a delivery-focussed team is to:

  1.  Focus on outcomes
  2. Experiment
  3. Use Lean principles
  4. Implement a team organisation framework
  5. Define Roles and Responsibilities

Focus on outcomes

Once the product owner has defined and stated their strategy, work with them to identify the desired outcomes. These can be expressed as OKRs.

Being focussed on outcomes means that you will aim to solve the real problem rather than just delivering tasks blindly. It increases innovation and gives the team greater flexibility in how they achieve the required results.

Experimenting/Intelligent failure

To achieve these outcomes, you need to experiment. Create a hypothesis that a chosen  change will create the desired outcome and then try it, analyse the results and if it doesn’t have the desired outcome iterate (or tweak) the experiment or try something completely different.

Make sure if the experiment fails it is intelligent – by this I mean that it is Quick, Cheap and Unique. I have already written a blog on Intelligent Failure.

How do you choose and prioritise your experiments? In game theory there is a practice of backwards induction – this can be used to identify feature prioritization. In backwards induction you start with the desired outcome and work backwards to identify and prioritize the most critical features that need to be developed first.

Here’s a soccer analogy example which might explain things clearer-

In this scenario the striker is approaching the goal with the ball, and there are 3 seconds left in the game. The striker must make a series of quick decisions to score.

  • At 1 second (final decision), the striker is in the penalty area and must decide to shoot or pass. Shooting has a 70% chance of scoring, passing has a 30% chance. Optimal choice: Shoot.
  • At 2 seconds, the striker is at the edge of the penalty area. The options are to either dribble into the area or attempt a long shot. Dribbling leads to the higher probability shooting opportunity in step 1. Optimal choice: Dribble into the area.
  • At 3 seconds (initial decision), the striker is approaching the penalty area. The options are to sprint forward or attempt to draw a foul. Sprinting forward leads to the optimal dribbling opportunity in step 2. Optimal choice: Sprint forward.

Let’s transpose this into a Software development situation:

  1. Final stage (Month 6) Target = 50,000 active users, required feature: Advanced reporting and analytics
  2. Month 5 Target = 40,000 users, feature: Integration with popular third-party tools
  3. Month 4 Target = 30,000 users, feature: Mobile app launch
  4. Month 3 Target = 20,000 users, feature: Team collaboration tools
  5. Month 2 Target = 10,000 users, feature: Task management and scheduling
  6. Month 1 (Launch) Target = 5,000 users, features: User authentication, project creation, basic task management

In the example above we don’t know if the task management and scheduling features will achieve 10K extra users but it is an experiment we will try.

You can read more in “The Art of Strategy: A Game Theorist’s Guide to Success in Business and Life” (Avinash K. Dixit and Barry J. Nalebuff).

Use Lean principles

To follow on from experimenting, you need to conduct these experiments as cheaply as possible. This means using the Minimum Viable product principle, popularised by Eric Ries in his book The Lean Startup.

Do the least you need to do to prove or disprove your hypothesis, validate it and learn; and then either Pivot or Continue with the current approach.

Team Organisation

“Talk to each other” is the most common phrase shouted by soccer team coaches at the junior level (I know because I do it!). You need to create a way of working within the team that means they own the delivery, they coordinate tasks and they inspect, adapt and improve.

This is where Agile ways of working can help, especially the Scrum framework. It offers a standard operating model which provides opportunities to communicate (daily meetings) and regular intervals to reflect on progress with Iterations (Sprints) and a formalised approach to approve the team (retrospectives).

Roles and Responsibilities

In a soccer team you can’t have 11 defenders, you need a mixture of competencies. A coach will think carefully about who is performing what role. In a business team this is rarely done beyond asking the question, “do you have the necessary job functions filled?” (e.g. DevOps, Tester, Devs).

In “Team Roles at Work” (R. M. Belbin), the author describes the following roles-

Action-oriented Roles

  • Shaper – Challenges the team to improve and pushes for action.
  • Implementer – Turns ideas into practical actions; reliable and efficient.
  • Completer-Finisher – Ensures thoroughness and attention to detail.

People-oriented Roles

  • Coordinator – Acts as a facilitator, ensuring that everyone is involved and focused on team goals.
  • Team Worker – Supports team members and promotes harmony within the group.
  • Resource Investigator – Explores opportunities and develops contacts outside the team.

Thought-oriented Roles

  • Plant – Generates creative ideas and solutions; often seen as the innovator.
  • Monitor-Evaluator – Analyses ideas critically; provides objective judgment.
  • Specialist – Brings in-depth knowledge or expertise in a specific area.

Make sure you have most of these roles covered within your team – this can be multiple roles per person. Make sure they know that this is the role(s) they bring to the team. Encourage them to expand on this role and improve in it.

If you think that an important role is not fulfilled by a team member, think about who could do this role and speak to them about stepping up into it.

Making sure you have the right players in the team, and they can do the tasks they are assigned will be discussed in a subsequent blog on Ability.

If you can create the perfect tactics suited to your situation you will have an all-conquering team which will succeed in any situation.

Let me know how you get on.

Feature image photo by Markus Winkler: https://www.pexels.com/photo/top-view-shot-of-foosball-13548815/

Intelligent Failure

I was watching a video of Jonathan Smart talk about his excellent book Sooner Safer Happier and something he said jumped out at me:

“We want intelligent failure”

Intelligent failure, he explains, is a failure that is:

  • Quick
  • Cheap
  • Unique

Failure is not intelligent if you have spent a lot of time and money and/or you have made the same mistake several times already (doh!).

MJH SHIKDER

This is a great concept – making a mistake is not bad as long as we do it quickly, cheaply, learn from it and alter our approach next time. In fact, in her book, The Right Kind of Wrong, Amy Edmondson suggests companies should actively seek to make mistakes in order to use the lessons learnt to make strategic decisions.

Agile and failure

Guess what? Scrum and the general Agile methodology provide the tools to ‘fail intelligently’ in the inspect and adapt principle!

An iteration retrospective provides the opportunity to identify where failures have occurred, learn from them and adapt ways of working accordingly.

The next time you do a retrospective, ask the team where they have failed specifically rather than the usual Start, Stop or Continue topics. Why not ask the team to identify some experiments they can do which are likely to fail so that lessons can be learnt quickly and can be used to make decision on how to continue the work.

I would suggest that you also broaden it to be company-wide and ask the management team to do the same. Failure is not negative when it can be used to drive the company forward.

Photo by Miguel Bruna

Further Reading

If you are interested in reading a bit more on this topic, these two books and in-depth article would be a great place to start:

The Right Kind of Wrong

Amy Edmondson’s book, The Right Kind of Wrong is recommended by Jonathan Smart and is an excellent book on business practice, which I promise I won’t fail in finishing.

Amy describes how leaders should create a culture that supports healthy risk-taking. Leaders should model transparency about their own failures and create an environment that values honest discussions about mistakes. This creates psychological safety which will enable using failure as a step toward growth.

Nurturing innovation through intelligent failure: The art of failing on purpose

This in-depth article describes how traditional failure is viewed as an unfortunate outcome that organizations either learn to live with or try to avoid. The authors, Narduzzo and Forrer, argue that there’s an alternative way to view failure: intelligent failure, failure that is designed and executed intentionally. This approach allows organizations to explore unknowns, test unvalidated assumptions and learn what to do next.

Narduzzo and Forrer propose the following systematic model for intelligent failure:

  1. Identify Assumptions – Start by questioning the assumptions behind your current knowledge. Which ideas, technologies, or beliefs are you taking for granted?
  2. Design the Experiment – Structure an experiment that will either validate or challenge these assumptions. The key here is to design it so that failure is a real possibility—this means avoiding low-stakes, “safe” experiments.
  3. Learn from the Outcome – Whether the experiment succeeds or fails, it generates valuable insights. If it succeeds, you confirm the current understanding. If it fails, you gain insight into why the existing knowledge or assumptions might be flawed, opening up new perspectives.
  4. Revise Knowledge Systems – Use these insights to update and improve the organization’s knowledge base, allowing it to adapt and prepare for further experimentation.

Sooner Safe Happier – Antipatterns and patterns for business agility

I mentioned this book at the top of the blog post. Written by Jonathan Smart, it is one of the business books I most frequently refer back to.

Smart describes a series of patterns and anti patterns which he has learnt from implementing the Agile Methodology in over 40 organisations.

Escape from the Office – How to run an escape room for 80 people simultaneously

What is the most terrifying thing you’ve done professionally? For me, it was having to guide over 80 people through an interactive ‘get-to-know-you’ session. These type of sessions can be so awkward so I was totally ready to blow the format up and produce something that was enjoyable and useful for everyone. It was just totally terrifying for me!

I have now done these events a few times (getting better each time – and more out of my comfort zone). So let me tell you how I pull them off.

The basics

The escape room style session has multiple groups doing the same activities to escape the “room”. The groups compete with each other to be the first to finish all the activities, work out the escape code, in order to escape the fastest. There’s a range of fiendish or logical puzzles to complete as well as physical challenges. The variety of games maximise the opportunity for the group to interact with each other and create memorable moments which can be discussed and laughed about later!

Materials

  • 1 set of escape room puzzles per team (see below)
  • Physical activity instructions (see below)
  • Ping pong balls (number depends on activities chosen)
  • Chopsticks (number depends on activities chosen)
  • Plastic beer cups (number depends on activities chosen)
  • Table for each team and physical activities

Puzzles

I used the puzzles created by a professional paper-based escape room creator, Paper Escape Co.

I recommend spending the money on this kit, they are really varied, well thought-out and just the right side of tricky to work out! They also save tons of time. Choose 6 and 10 different puzzles which each give a specific answer. The answer from each puzzle can then be combined to provide a code word which can be used to “escape” the room.

The number of puzzles you choose will depend on how long you want the activity to go on for. The more puzzles you have, the more possible combinations of answers there will be. Use this table to calculate how many puzzles to use.

Here’s an example of a puzzle you could use (I have created this one myself to protect Paper Escape Co’s copyright):

The pack from Paper Escape Co contains hints for the competing teams, which is necessary for some of the more fiendish puzzles.

Physical Activities

It is difficult to find physical activities that keep both the athletic and the sloth-like happy. But I really like the Beat That! selection of physical challenges, and used it for inspiration. Watch the video in the link for ideas on what tasks you can ask the teams to complete.

Directions

Here are my top tips on how to run an escape room session with a large team:

  1. As a rough guide I recommend you split your group into teams of between 4-8 people and have 2 and 4 physical activities and up to 10 mental activities for them to complete.
  2. As part of your planning for the session, rope in as much help as you can. You will need a small group of people to help facilitate the session and support the teams through the puzzles and activities. One person can support up to 4 teams or 2 activities. For example for 80 people I had 10 tables and 4 activities – I had 3 people looking after puzzles and 2 people looking after the physical activities (5 helpers in total). Brief the helpers and give them the hints and even the solutions so that they can help the teams. We actually did the puzzles together before the session, so that all the helpers understood what needed to be done.
  3. Set up the room so that there is 1 table for each team (where they will do all the puzzles), and 1 table per physical activity. I had 14 tables in a very large room!
  4. Place half of the puzzles on the tables ready for the teams to start.
  5. Split the attendees into the teams. You can do this however you want, but I love to add a bit of silliness and get everyone to order themselves in a line according to the number of graters they own (cheese, nutmeg, foot!). I then go down the line giving everyone a number between 1 and 10. The number represented the table and team they were on.
  6. Let them start cracking the puzzles – the helpers can give hints progressively to help them out. I gave the helpers a timesheet for when to start helping the teams; e.g. no clues until after 5 minutes with no puzzles completed.
  7. Once the puzzles have been completed, move your teams on to the physical activities tables and complete the first and second activity.
  8. During the time it takes the teams to complete the physical activities, get the helpers to lay out the second half of the puzzles on the puzzle tables.
  9. Once the two physical activities have been completed, move the teams back to the puzzle tables to complete the second half of the puzzles.
  10. When they’ve finished the puzzles, move the teams to do the third and forth physical activity.
  11. Once all activities have been completed they can be given the final puzzle – arrange the letters (the answers to the puzzles) into a passcode and the winning team is the one to complete the passcode and tell the facilitator their answer.

That’s it!

Good luck! Have fun! And let me know how you get on.

Leave a comment