What is a software development team?

On software development teams: how to form one, what good looks like and how to set them up for success.

Digital technology is now pervasive through societies world wide. Industries have been disrupted – even governments, too – and we now find ourselves in the software age. Software development is mainstream and organisations have now realised that in order to stay relevant they must embrace software to the point where most are now funding their own software teams.

What exactly is a software development team? The answer may seem obvious and I suppose it is in some ways – clearly, it's a team that develops software. How useful is that definition for organisations forming software development teams for the first time? What does a good one look like? How do you know if your software development team is set up for success?

They develop working software

Three factors need to be considered when developing software: value, usability and feasibility. Your team should have the necessary skills to ensure these factors are carefully balanced. The software they develop needs to be valuable, usable and feasible.

A successful team will weigh up each of these factors and make tradeoffs where necessary when deciding what to build, when to build and how to build. Failing to balance these factors can have undesired consequences:

• If what you develop is valuable and usable but not feasible you'll never actually release any software
• If what you build is usable and feasible but not valuable to your organisation, then you won't be able to claim any return on your investment
• If what you build is usable and feasible but not valuable to your users, then I'm sorry to say but no one will use your software
• If what you build is valuable and feasible but not usable, congratulations – you built enterprise software

The last point was a little tongue-in-cheek, as you might have detected. It's an important point, though. Often business users do not get a choice in the software they use to do their job. Often their managers or directors will have made a purchasing decision based on cost rather than usability.

A multidisciplinary approach is needed for each of these factors to be considered. We combine two sets of needs with the skills required to develop software. We combine organisational needs with the needs of it's users to identify value. We bring both design and development folk together to translate this value into usable and feasible software, or in other words, working software.

Properties of a successful team

There are five properties a team must have in order to be successful in developing working software: empathy, trust, capability, time and feedback.

A high degree of empathy is needed when developing software and in fact, is a property of all high-performing teams. Empathy for each other is needed in order for a team to work well together and understand each other. Diversity can be a strength for teams but only when the team also has empathy. Empathy is also needed for organisational and user needs. A team must understand the drivers behind the software they are developing.

The team must have trust from the wider organisation so that they may be empowered to solve problems, test their hypotheses and release the software they develop. If the team is not empowered to decide what to build, how to build, or when they can release software, they are not a software development team, they are a feature factory.

Your team need the capability to derive value from the business and user needs, in order to build usable and feasible software. This does not necessarily mean you need a team of distinct specialisms; you could instead form a team of generalists, but whatever you do, you need a team who are capable of developing working software.

A team requires the time to turn the business and user needs into working software. Every member of the team needs to be explicit in terms of their time commitment to developing the software. The team as a whole needs enough time in order to develop working software. The team needs time together where context and understanding can be shared, but also time apart to allow thoughts to be digested.

A continuous cycle of feedback is the only way a team will be able to test whether what they're developing is valuable, usable and feasible. Feedback is the mechanism by which a team learns together. The more frequent your team can learn, the faster they will be able to adapt their plans and deliver value.

Forming a team

Each of the properties need to be understood when forming a team, and be protected throughout the lifetime of the team.

A team first and foremost must have empathy for each other and the people they are solving problems for: their users and even their most tricky organisational stakeholders. Empathy must be nurtured throughout the course of the team's life in order for it to be maintained. It is critical for everyone, but especially leaders, to demonstrate and champion empathy.

Having a shared understanding and purpose is a good starting point for focusing the team and fostering empathy. There a number of ways you can express a team's purpose:

• A purpose, vision, mission and values statement
• Objectives in the form of OKRs, MOKRs and/or KPIs
• A problem statement

Your team may complete one or more of the above, or use a different activity altogether, the important thing here is that they have a shared understanding of why the team exists, the challenges they face and that the challenges can only be overcome through teamwork.

The organisation must trust the team to solve problems and should therefore give the team a problem to solve rather than instructions to be completed. Your team may at this point wish to define a problem statement, or the sponsor establishing the team may seek to define a problem statement with the team.

A good problem statement will explain a desired state or vision that isn't currently achieved. It will explain the current reality or context. It will explain the impact of action or inaction. Lastly, it will set out a question or hypothesis along with measures to prove or disprove success.

With empathy and trust established, next you need to ensure your team has the capabilities and time needed to solve the problem it has been set. This means the team needs a budget to cover both staff time and expenses. If your team can't dedicate time to their mission then it won't be achieved.

This also means recruiting a team with necessary skills. The team will need the leadership necessary to make decisions on value, usability and feasibility. This will often involve product, design and development skillsets, but may also include subject matter experts, senior leadership and even users.

Finally, the team need to define and agree ways of working that enable rapid feedback cycles. Regardless of your approach to process you need to ensure your team are regularly:

• Providing feedback to each other
• Seeking feedback from the organisation and users
• Learning from feedback and deliberate practice
• Changing their plan in accordance to feedback

Short feedback cycles will minimise wasted time building the wrong thing and will guide the team towards developing working software.

Measures of a healthy team

A team must be healthy in order to be sustainably successful. The health of a team has several measures including safety, balance, learning and happiness.

The team needs certain safety levels in order to be honest and productive while working together. You can measure safety levels by looking at the team's ability to express how they're feeling. Can they provide and receive honest feedback? Is blame projected when things go wrong? Do they feel they can push back if they disagree? Are they able to compromise in order to move forward?

Team members need to balance their work with the rest of their lives. Balance is required in order to sustainably develop software. You can measure balance by looking at how frequently people are starting early or working late in order to meet goals. Are the team taking adequate holiday? How often are the team crunching? Are there high levels of sickness in the team?

Teams have to be empowered to make their own decisions and solve problems. How often are your team blocked by outside influences? Does the team have the necessary leadership within the team to make decisions? Is the team trusted by its organisation?

Teams should always be learning. Does the team feel like they are learning on a regular basis? Is the team's confidence growing with time? Are the goals of the team in line with each member's career goals?

A healthy team is a happy team. Happiness is perhaps the hardest measure of success as everyone has ups and downs, and so happiness will vary but the team as a whole may still be healthy. To measure happiness you need to look at the team as a whole as well as on an individual basis. Is the majority of the team unhappy? Is only one person really unhappy? You need to dig into the why behind happiness and unhappiness in order for it to be useful. Use regular check-ins with your team to understand their happiness levels.

The measure of a successful team

There is only one measure of success for a software team: are they developing software that is valuable, usable and feasible? Are they developing working software?

The team should be trusted to solve a problem. Along with that comes the responsibility of proving their success. This is both rewarding and fair. Proving or disproving their success is also important for feedback and adapting the plan based on new learnings. A team should have the freedom to iterate towards success.

Measuring value, usability and feasibility should be a continuous process of the team. At the outset the team should have defined the reason why they exist and have a clear problem statement they are working on solving. The team should be reflecting on a regular basis as to whether they are achieving their mission.

Problem statements and missions can sometimes be long-lived, and so the team will also want to set out smaller problems, missions or hypotheses to work on. Each should have experiments and measurable objectives that can be used to determine success.

At no point should the team consider they are done after releasing software. Before they are done they must prove what they released is working. Only then are they truly accountable and empowered to develop software that is valuable, usable and feasible. Only then have they delivered working software.