Achieving Excellence: Understanding High Performance in Agile Teams

High Performance

Do you enjoy your work culture?

Who doesn’t want to show up to work and be in an environment with like minded and talented team members (ability, passion, desire not skill-set).

Do you enjoy your work environment?

Who doesn’t want to be part of a team that is recognised for the quality that they deliver as well as being seen as industry leaders, has the abilities to use technologies that will give the best outcome and help grow your teams skill-set and interest.

Do you want to easily be employable?

Who doesn’t want to be perceived in the communities they are part of as someone others would love to work with.

All that sounds great, right, and they are benefits that happen when working in a high performing team, however truthful speaking I think high performing teams are very rare, though while I think they are rare, I think it is also very important to strive to be a high performing team, not just for others but for yourself.

Before you start

About this post:

  • 2 – 7 min average reading time
  • Suitable for beginner’s through to advanced

What you will gain reading this post:

  • An understanding about high performing teams
  • A set of recipes for success
  • An understanding of problems that occur

What you can do to help support:

  • Like, comment and share this article
  • Follow this blog to receive notifications of new postings

Now, let’s get started.

The benefits

  1. If a team member is away any team member can continue (cross functional members)
  2. Code quality will improve (members will be more critical and review processes will improve)
  3. Feature delivery will be fluid (bottlenecks will reduce)
  4. IM / BA roles will become optional (teams will be self sufficient)
  5. Testing roles could become optional (testing will be performed by devs, and the testing will be a quality gateway)
  6. You will become a much better industry leader (you will learn and be able to scale into any team)
  7. You will care more (not by taking interactions personally, but constructively, blame and wrist slapping will be stop within the team)

Optional roles, wait! what!

Optional is just that, optional not obsolete, meaning what works best for your team dynamic.

If the team dynamic works better with still having an IM to assist the team, then there is no reason to not have that role, but ideally that role will go from having the IM drive the team to the team driving the IM to assist where required.

If the team dynamic works better with still having an BA to assist the team, then there is no reason to not have that role, but ideally that role will go from having the BA gathering requirements and writing stories to the BA assisting where required. The team will be more involved at the feature / story level.

If the team dynamic works better with still having a tester, then there is no reason to not have that role, but once again you will see the focus of the tester change, maybe the tester can exist across multiple teams or maybe the tester will purely perform manual testing, setting up session on best practises, create events such as bug bashing, being key in writing the acceptance criteria, reviewing automated tests, etc…

While there is a blend of skill-sets being absorbed by the dev team, it should not be taken as the dev team performing multiple roles and responsibilities but being able to perform multiple skill-sets.

Once high performing, always high performing, right?

Short answer, NO!

It is quite easy to move from a high performing to not a high performing team, there are many factors in this.

  1. Senior/Upper management (not leadership) driving the team performance / delivery not the team.
  2. Change of team members.
  3. Low individual moral (yes, individuals matter).
  4. Teams not given the ability to attend conferences / training or participate in innovation.
  5. Technology lockdown / technology bleeding edge because “why not” rather than for a purpose.
  6. Perception (outside influences interfering with the team based on their perception).
  7. Unresolved team conflict or conflicting team vision.

That does not mean it is not achievable, being an agile team, processes are always being improved and it is important to capture a process that works for your team, an example of a good process to capture the on-boarding process to help with the changing of team members.

Recipe for success

While there is no one size fits all solution to being a cross functional team. There are certain traits that a team does require:

  1. Everyone has to be onboard (you can have specialised skills in the team but they need to be open to pick up tasks outside of their skill-set)
  2. The team needs to be flat (while you can have different roles like leads, senior, junior etc, those just represent the level of experience the individual has not the level of authority they have)
  3. Don’t take it personally (be open to the opinions of the team, while you may not agree to all decisions made, the end result is a team decision)
  4. The team is responsible not the individual (you cannot throw your team members under a bus, you agree to a solution as a team and delivery a solution as a team, if something is missed it is the teams responsibility to resolve, and the team can later have ceremonies to ensure that doesn’t happen again)
  5. Must have high collaboration (you must be open to improvement, you must communicate)
  6. Everyone must participate (in ceremonies, leadership, and general team activities)
  7. Give everyone a chance to lead (support those taking the current lead as well)

What are these roles and responsibilities

Everyone in a team is equal and different roles just mean different skill-sets as well as attending different ceremonies that may not be suited for all team members.

Leads should do just that lead by example, ensure the team is not blocked as well as ensuring you are across what the team is doing to be able to communicate clearly to other team members outside of the immediate team.

Embrace Cross Functional

Encourage ownership around the team, it is quite common to have members within the team always stepping up to take ownership or stay away from ownership, I have found this has some benefits and problems and in my experience found the problems out way the benefits.

Benefits

  1. Easy to see who the leaders are within the team.

Problems

  1. I have found that teams can get a competitive attitude that can create an unhealthy team. (comments such as, “why don’t you step up like …”, “your not performing your roles and responsibilities”, “other team members are outshining you”, “I want you to be the go to person” all detract)
  2. People are not always out there, and they can often get left behind, or not seen as a valuable team member. (some of the most quiet team members are the best I have worked with over the most opinionated)
  3. Single point of expertise. (if the member leaves the team, it can leave a hole, it is better to spread the knowledge)

Don’t be afraid to step outside of your comfort zone, you won’t have the same skill-set as others in different roles but you can learn from them and in turn improve your own skill-set but understanding others.

Don’t have the attitude of I don’t want to learn that, knowledge is key, and learning another skill-set will help you to better understand and relate to others.

Analogy, that helped put things in perspective

Sometime you just need to relate lack of understanding with a personal experience to better understand, for instance, when speaking about this topic on what is means to be high performing with my wife, she was able to share with me an analogy that really helped me to clarify and better realign my previous understanding, the analogy goes…

“In this situation you can think of your partner as your team, the baby as the higher cause also the deliverable and what we are working so hard to be successful.

In a family the baby is required to have the nappies changed. It is not about focusing who’s role and responsibility it is too change the nappy but to change the nappy when required, if your partner changes the nappies most days, since they look after the child while you work and you come home to a baby with a soiled nappy, don’t focus on getting your partner to change the nappy but go and take the baby to have a nappy changed, ask where the nappies/cream/powder/wipes are if you are lacking that information but go and change the nappy and come out of it happy and uplifted resulting in respect and admiration from your partner.”

What you get from this try not to to manage roles and responsibilities but to lead the situation in your team, admire and respect from your team, this in turn builds trust and relationship, which then helps collaboration to flourish, these are all positive aspects a team require to be high performing.

Along the way you have also increased you skill set within the team but improving your ability to change the nappy, once again you are still not at the level of your partner who regularly changes the nappy but you are one step closer to having a proficiency in that skill.

Did this help?

  • Like, comment and share this article
  • Follow this blog to receive notifications of new postings
  • View previous postings

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.