Many of us work in software development companies that use agile practices and frameworks. For most of us, it works well, and we’re satisfied with the results. However, most agile frameworks are not complete methodologies, and therefore don’t include solutions to all of the problems. For example, how to form new teams, how to educate clients and how to organize your work as a PO etc. In this article, I will present my view on forming agile teams within a company.

To do this, I will assume some typical scenarios. We have a company with several projects on the go, and one of our new clients is close to making a deal. In this situation, we have to fully prepare for software development – we have to form a team. There are many ways to handle this process, so let’s find the one that will best suit our needs & capabilities.

1. Ideal Scenario 

First off – the ideal situation. Imagine you have a dozen agile developers who are good at self-organisation, are technically skillful and have advanced soft skills. If you have such a group, you can simply arrange a meeting with them and the new Product Owner, who will present the product vision and high-level requirements. Together they should be able to determine the necessary details, skills, and technologies, and enable the developers to self-organize into team(s), based on many factors, including:

• their feeling of the ideal team size (which depends on the scope, possible parallelization of tasks, required time/budget and other factors)
• required skill-set
• other project-dependent factors (like available budget, special requirements etc.)
  In reality, most organizations/developers are not mature enough to follow this process in every detail. So we have to aid it in some way to make it happen.

2. The real world scenario

A more real-life scenario is that a group of developers (potential future team) will meet with a client/PO, but will be accompanied by a Scrum Master and/or other experts (like team leaders, seniors, technical managers etc.). They will aid the process by facilitating the developers’ decisions, suggest solutions, or, as a last resort, make decisions if none are made by any group members.

How much of the decision-making is done by developers depends on the maturity of the agile mindset across the organization. By that, I mean how skillful the developers are themselves (technical + soft skills), how much practice they have in self-organization, the level of trust inside the company (do managers trust developers’ decisions?), and how proactive the developers are at achieving goals.

Our goal is to make decisions with all parties involved. So in the future people will be able to make decisions for themselves. If somebody is affected by a decision then give them the ability to make a decision about it! They will be the ones who have to cope with the consequences, so why should we make sub-optimal choices for them? If we don’t trust our people, perhaps we should stop and think about it for a second. That can be a very limiting factor for our company growth and scalability.

While you’re here, check out our latest job offers. We are still looking for a Scrum Master.

3. Agile organisations

If an organisation has been following agile practices for a long time, then it should already have several agile teams working on products. It’s safe to assume that some of these teams will be finishing work on the product sometime soon.

Keep the development team consistent

The best practice is to try to keep the development team composition unchanged, because every change will have a temporary negative impact on the team’s efficiency, due to repetition of the process of team forming & normalizing. It’s especially prevalent if we decompose teams entirely and assemble them from scratch with every new project – efficiency will be sacrificed by a huge amount, people will have to re-learn to work together (see: The Seven Wastes of Software Development) etc.

So in practice, you should be able to frequently re-use an already existing team, maybe with some small-scale changes to their composition. An existing team will be more efficient than a new one because:

• people already know each other,
• they have very good communication between them,
• they know how to collaborate and what to expect from each other (as if they are one big family).

It requires months or even years of working together to achieve this. So if you already have it – don’t destroy it and try to make good use of it.

Focus on teams, NOT individuals

Agile organisations should really focus on the team, rather than making decisions about individuals as if they were separate entities. Idealistically, all people in the organisation should be well-connected as if they were one big team (“family”). In practice, interactions in such an environment will be very complex, and because we have limited time, focus & resources, we need to structure this approach by introducing a smaller concept of a team, which consists of no more than about 10 people. This approach can be of course scaled further into a bigger organisation, but that’s a topic for another article.

4. Anti-patterns

Like with all agile processes, we should try to avoid making decisions by people who will not be involved in the final usage of the product.

A typical anti-pattern here is to make behind-the-door decisions by the CEO, sales department or technical leaders etc… What usually happens next is that a group of people (the “new team”) gathers together and they shortly discover that decisions were far from optimal. So they quickly become frustrated. This may mean reworking things or create serious doubts about whether there was any point in using the effort already put in. This results in lower performance, higher cost, and eventually in less trust in management’s decisions and competences.

Summary

To help you remember the uppermost practices, here’s a short summary:

• Build your teams with skillful/capable people from the beginning. I can’t stress this enough – if you don’t, it will be almost impossible to make up for it later
• Take care of your teams – don’t divide them, don’t terminate them – cultivate them and help them grow
• Try to make your decisions as close to the source as possible. The best decisions are made by people directly involved with their outcomes
• During the growth of the team’s organisational skills: facilitate their decisions and help them, until you’re satisfied with results that they can achieve themselves
• If all done right, in the end, you will have autonomous teams, which don’t require micro-management. It’ll give everybody the ability to focus on other areas

P.S. If you would like to learn more about software development methodologies then check out some of our other blog posts, including:

How to effectively use timeline to plan and monitor your sprint

Is Planning Poker a perfect estimation technique in scrum?