You are about to start a new project and are considering what kind of people you need. Typically people take a project manager, a designer, some developers and a tester so it must be the perfect recipe? Scrum and other agile methodologies came to the scene and confused people: they have roles like “Product Owner, Scrum Master, Coach and ‘the Team’”. Still, you have people with diverse set of skills and you need to staff your team. What should you search for? Here I explain why you should build your project on top of generalists and try to keep the team as small as possible, but no smaller.
Recognised roles
Any project needs all sorts of expertise. In the picture 1 I have illustrated a typical, yet simple, scenario where the project needs some management, architecture, user interface design, development and it operations. The easiest and arguably most common solution is to assign one or more people into each expertise.
Person per role
This seems obvious: if we have a work to do, we need a person to do it. But this leads to problems well known: people are not collaborating effectively, they have their own silos, most of the decisions need to be done upfront which leads to waterfallish development no matter what your official methodology is. Most challenges in real world have cross-cutting concerns. Solving any such problem needs broad understanding of many aspects and in this setup this means you need many people work together. Collaboration is not bad in itself, but when you have two specialists who don’t understand each other’s expertise, it is not as efficient as it should be.
The solution to this problem has been examined before (see for example my problems in current resourcing). But as I see this one of the major hurdles to efficient (dare I say, agile?) development and I don’t see it being handled properly I need to keep refreshing on it. So, what we should aim for?
Person per gap between role: 10 required
Instead of using simple “person(s) per expertise” -method, we should probably use “minimal number of people that is enough to fill all the gaps between silos” –method. First you need to identify all the expertise areas that are needed to accomplish the desired end result. Then you need to find such persons that fulfill every gap between any two expertise areas. In our example, we had identified the five expertise areas so we have 10 gaps to fulfill.
Again, each of these gaps does not directly map into one person. Soon it becomes evident that if each team member only has one or two areas she is comfortable working in, you have a problem. Should each member have only two areas of competence, you’d really need 10 people. But, if even one of them possesses three different skills, the number of required people counts down to 8. If you have one “superstar” that is competent in four areas, you need only two people to fulfill every gap.
Persons with overlapping skills: only 3 required!
In any real-life project you have probably more than just 5 types of expertise needed: concept design, usability design, graphic design, requirements gathering, database programming, UI programming, testing, it operations, mathematical analysis, domain-specific knowledge etc. And as we know, the more people there are in the project, the more demanding the communication. And communication happens to be one of the most important aspects of any project, especially one of software deveopment (see: software development as a cooperative game). This reminds us about the importance of multi-competence.
So as a summary, the suggested method to project staffing is:
- identify the required expertise areas
- find the least amount of people that cover all the required areas
- if you need more firepower into any area, only then can you add a specialist
=> Sami’s rule of project staffing: Build the project on top of generalists, only add specialists if needed.
