To build expert, mobile apps, you need mobile experts — if you are developing an app for both iOS and Android, you need experts in both iOS and Android. The Rolls-Royce approach is to create a sub-team of iOS specialists and a sub-team of Android specialists, each responsible for their own platforms. But mobile experts are expensive and hard to recruit, so to achieve this, you need a big budget, and power in the recruitment market.

If you don’t have the Rolls-Royce budget and recruiting power, you might turn to a cross-platform technology, such as React Native or Flutter. You still need mobile experts to build expert, mobile apps, but you need fewer of them, and you can create a smaller team around a single codebase. However, whilst cross-platform technologies are sometimes the right choice for a project, they often aren’t — I’ve written about the advantages and disadvantages of cross-platform technologies on the Infinity Works knowledge base.

The good news is that there is another approach that lets you build expert, mobile apps for both iOS and Android, with a smaller team and fewer experts, whilst leveraging the benefits of native mobile development. This approach uses what I call a blended team.

What is a blended team?

A blended team is a single team, made up of a few mobile experts combined with T-shaped team members. All team members are responsible for development across both iOS and Android. It works because, although you need mobile experts to make expert mobile apps, not all tasks on the project need to be done by experts.

What are the benefits of a blended team?

The blended team approach has the following benefits:

You can build native iOS and Android apps with a small team
You minimise the number of mobile experts you need to recruit
Domain knowledge is shared across both platforms
The team is an effective engine for developing new mobile experts
It’s popular with team members, who can grow their skills on different platforms whilst maintaining their specialism

How do you make a blended team work?

To set up a blended team to run successfully, you need to answer the following questions:

How do you get the right level of experience and expertise into the team?
How do you create an environment where anyone in the team can take on tasks without risk to the project?
How do you share the expert knowledge through the team?

1. Getting the right level of experience and expertise

Key specialists

The team needs at least one iOS and one Android expert to act as technical leads. They need to be experienced in implementing architecture patterns and solving platform problems. Additionally, they must be good leaders and communicators who can coach the team on their platform.

Team members

The rest of the team should be built with T-shaped individuals. It’s beneficial for some of them to have iOS or Android experience, but not every team member needs that. These team members can be at various levels from experienced to junior. The most important thing for them is that they are adaptable.

Team size

The best team size for your project will depend on your exact needs, but for many projects I’ve found the sweet spot for effectiveness to be around six people, correlating with Amazon’s two-pizza rule. This is enough to allow flexibility to pair or work individually, but few enough that people aren’t treading on each other’s toes in the code base.

2. Anyone can take on tasks without risk to the project

Using a well-defined process allows anyone on the team to take on tasks without risk to the project. It ensures that everyone knows exactly when each development step is complete, fully reviewed and tested, and ultimately, when a feature is ready to ship.

Your process will vary according to your needs, but here’s the one from my most recent project.

Analysis — turn requirements into discrete tasks
Elaboration — work out how to implement each task
Implementation — do the development work
Demo — show the rest of the team what it looks like when it’s finished, and how it was implemented
Code review — ask questions to learn how it works, look for any potential mistakes or bugs, share suggestions for different ways of doing things
Test — make sure the feature works on different devices and under different conditions
UAT — the product owner carries out user acceptance testing and signs off that they are happy with the completed feature

Definition of done

Each of the steps in your process should have a definition of done. This means that everyone knows when one step is complete, and the next step is ready to be started. If a team member doesn’t have the experience or expertise needed to complete a step, they can get support from someone else in the team.

For example, in my process, implementation is done when all the coding work is finished, and appropriate automated tests have been written. Code review is done when two team members have approved the feature, and all comments have been considered and responded to. Testing is done when at least one team member has run the code, followed test instructions and looked for edge cases.

Everyone follows the same process

Everyone, regardless of expertise and experience, should follow the same process in the same way. This might feel counterintuitive, e.g., why would an expert need the same number of code reviews as a junior?

The first reason is that you can significantly reduce risk if everyone follows the same process in the same way. This gives team members a safety net to work outside their comfort zone. For example, imagine if code reviews were optional. Team members would have to make decisions about whether they needed a code review. They would need to assess if a task was trivial compared to their skill level, if the feature was risky, and if it was worth bothering other team members to do the review. However, there could be unknown unknowns that mean they make the wrong decision. If on the other hand everyone always follows the process in the same way, team members can be confident that they have support from the team with tasks they work on, and the team can be confident that all tasks are completed with a low level of risk.

The second reason is that there is value to the team for reviewing code written by more experienced members of the team. It provides an opportunity to ask questions, share knowledge and learn from other people’s code.

The team owns the process

The process should be agreed and developed by the whole team. It should act as a framework allowing the team to do its job effectively and with low risk. Note, it shouldn’t be a set of rules imposed from above, to be followed dogmatically.

To achieve this, get the team to define their process and definitions of done. Then regularly review the process, looking out for areas that could be improved. A good test is to consider how well it would work when supporting a new team member. Would they be able to follow the process? And would the team be confident that everything was completed properly and with high quality? If so, that’s a good sign that your process works well for your team.

3. Sharing expert knowledge through the team

So far in this article I’ve discussed how to structure the team to contain the right mix of expertise. And I’ve discussed how to create a well-defined process to allow all team members to work on tasks in a low-risk way. The final piece in the jigsaw is how to share the knowledge of experienced experts across the team. If this works well it allows everyone to up-skill and work on more complex tasks.

Features are the responsibility of the team rather than individuals

If you make releasing high quality, completed features the goal of the team as a whole, everyone can focus on what’s best for the team, rather than feeling pressure to maximise their own personal output. This lets experienced experts coach, support, and share knowledge, rather than incentivising them to work alone.

A good way of doing this is to structure daily stand-ups to focus on features, and getting them over the line, rather than what individuals have been doing.

Encourage pairing

Encouraging team members to pair (i.e., work together) on tasks is a good way to foster knowledge sharing. I’ve found that a flexible approach works well. Sometimes people prefer to work independently, but they may choose to pair if:

they’d like help with a task
they have knowledge relating to the task that they’d like to share
to put focus on a task to complete it more quickly

Work in progress (WIP) limits are a good way to encourage pairing. By setting the limit on how many tasks can be in progress at a given time to be (just) smaller than the number of people on the team, you effectively give the team permission to pair.

Safety nets and knowledge sharing, not quality gates

In the previous section I talked about the importance of having a well-defined process, with each step having a definition of done. As part of these definitions of done, it’s sensible to build in quality checks, such as demos and code reviews. In a traditional team, these are often seen as quality gates, where someone’s work is scrutinised in the same way a teacher might mark a student’s essay. In a blended team, it’s important to invert this approach. Rather than being for the team to mark the work of an individual, they are for the individual to enlist the help of the team, and for the team to share knowledge. They act as a safety net, where potential issues can be caught and improvements can be suggested.

Allow team members to choose their tasks

With a culture of team responsibility, pairing and safety nets, team members can decide which tasks to work on to achieve team objectives. Your key specialists are available to remove technical blockers and coach the rest of the team. T-shaped people like to work on tasks that stretch them, so you soon see mobile expertise growing throughout the team.

Conclusion

In this article I’ve described how blended teams give you the benefits of using mobile experts to build expert, mobile apps leveraging native technologies, but without needing a Rolls-Royce budget or recruiting power. You can create a single team to work on both iOS and Android versions of an app by ensuring:

Create a Blended Team to Build Mobile Apps