Engineering / Development
Close (Esc)

What is a (genuine) high performing software engineering team

'How to measure' Artwork

Recently I had an amusing conversation about everything Scrum transformation (early hours of the morning due to timezone differences). The person driving the conversation was keen to understand how to create a high performing software engineering team without leveraging on TDD, BDD, Pair programming or using any XP practices.

To be clear, so that there can be no doubt; YOU CANNOT CREATE A HIGH PERFORMING SOFTWARE ENGINEERING TEAM WITHOUT ADOPTING AGILE PRACTICES.

I am happy to take this even further that you can only achieve true Agility with Continuous Delivery.

Behaviors, beliefs (a bit evangelistic), culture and principles are part of the critical path to becoming a high performing software engineering team, but these MUST be used in tandem with;

  • Driving requirements through BDD (its not a test, its specification)
  • Adopting a ‘write tests first’ mentality
  • Automating your builds with fast feedback loops
  • Pair programming (ad-hoc) when needed to support either the work efforts or a member of the team

Don’t kid yourself if you are only doing one part of any of the above; you are not a high performing software engineering team. Genuine high performing software engineering teams are more rare than people think.

How can you determine if your team are performing like a high performing team without test coverage statistics? or how do you know you are building what the business wants without testable specification (BDD)? Without these types of practices, how can you measure performance? In simple terms, you cannot.

People often misinterpret ‘self managing’ teams as high performing software engineering teams, this is not the case. Self managing teams are the foundations (post forming, storming and norming) of a high performing software engineering team, but this can be achieved without the adopting the Agile practices highlighted above. I’m a big believer in teams lessening their dependency on a Scrum Master and / or Agile coach, but this alone is not enough to warrant being called a high performing software engineering team.

I’ve only had the pleasure of work with a small number of high performing teams, please self promoting PR types stop using ‘high performing’ as a soundbite.

Back to Top
Have a chat with us info@acue.io
We use cookies in order to give you the best possible experience on our website. By continuing to use this site, you agree to our use of cookies.
Accept