5-10 person team - how would you distribute developers and other roles?

Question

You have 5-10 person slots for developing web application with lots of backend stuff.

How would you assign developers, UI design, test etc. to the team? Which roles would you recommend?

(Team gets business requirements and produces tested and deployable code, no support or work on production systems is required)

Answer 1

I would read The Mythical Man-Month to get a good background in software team organisation.

Which reminds me, it's been a few years since I've read that so I need to reread it soon!

Answer 2

The Ideal Development Team

Notes and summary of ideas taken from the book “The mythical man-month” by Frederick P. Brooks, Jr., 1982.

This book presents a model of an ideal software development team. The proposed model requires an extremely talented programmer who is “the boss”, and a set of support staff who are each expert in their own domain. The central idea is to establish and support a heirarchy that capitalises on the strengths of individuals. The book specifically targets software development but its ideas could be applied to any technical system development where domain experts exist.

Assumptions

• Good programmers may outperform average or poor programmers by a ratio of 10:1.
• Large teams of programmers (ie more than 10) are inherently inefficient.
• Small teams of good programmers are too slow for really big systems.
• Good programmers should program, not manage.

The 10 team members of an ideal team:

1. The surgeon defines the problem, designs the program, codes, tests and documents. This person must be talented, have 10+ years experience and considerable systems and applications knowledge.

2. The copilot is the alter ego of the surgeon, but is less experienced. This person is not responsible for any code, but serves as a sounding board, evaluator, insurance against disaster and an interface to other teams and projects.

3. The administrator is the interface to the bureaucracy of the rest of the organisation, and serves to remove all administrative tasks from the surgeon, who remains in charge at all times. The administrator may serve more than one project or team.

4. The editor is responsible for producing clear documentation. This person may take the raw documentation produced by the surgeon and revise it for clarity.

5 & 6. Two secretaries, one for the administrator and one for the editor.

7.. The program clerk is trained in secretarial methods and is responsible for the systematic maintenance of the developing system. This person ensures that all project output is filed properly and made available to the entire team, including both machine-readable and human-readable files.

8.. The toolsmith is an expert who is responsible for providing and maintaining the development tools that the surgeon uses..

9.. The tester is in an adversarial position relative to the surgeon, and designs banks of test data from the system specifications. This person is responsible for devising day to day test data, and also for the creation of a test harness required for component tests.

10.. The language lawyer is an encyclopaedic reference for the surgeon and may also be responsible for difficult, obscure or tricky aspects of the system. This person may serve more than one project or team.

Key differences between the surgical approach and the conventional divide-and-conquer approach:

• A surgically created system is the product of one mind, or at most two, helping to ensuring conceptual integrity.
• The team is naturally efficient through functional specialisation and a simplified communication pattern.
• Internal differences of interest and opinion are eliminated in the surgical team where the surgeon is the unilateral decision maker.

A team like this is mostly suited to small to medium projects. To scale up to very large projects, the team must be duplicated as many times as necessary, and the project must have one overall architect who will design the entire system.

This approach is opposed to the ideas of multi-skilling and democratic decision making - the surgeon is king of the castle and depends on the support of functional experts in order to fulfil the role of a controlling brain.

The experiences recounted in this book are largely derived from the System/360 project, which was to build a mainframe operating system. Business application development is different from system application development because the end-user has significantly more say in the analysis and design phases.

Answer 3

Totally depends upon their talents and the backlog of work to do. I don't think I could give you a "you need three coders to do X and two to do Y", because I don't think you can do a "just add water and voila!" approach to development. I'm not saying this is what you're expecting, but I'd definitely not take that approach.

First, I'd take an agile approach, decipher the requirements and put together a high level design from that, determine the backlog and what was going to make it into each iteration and then move forward.

I'd be doing a test-first approach because I think it works (at least for me) and I'd have the team distribute itself based upon their strengths and the backlog to work on. The amount of documentation and non-unit testing that has to be done wasn't specified, but I'd expect that everyone would be doing some hands-on testing throughout the project. That's what we do at my shop.

Answer 4

if you pigeon-hole your developers into 'back-end guy' and 'database guru' and 'user-interface specialist' roles, expect to start slipping or failing when one of them leaves and no one knows how to fill the now-empty role

i would recommend agile practices (XP in particular) instead

and stay far, far away from the Mythical-Man-Month military-style hierarchy presented above; deep tree structures are great for growing roots, but not for moving quickly ;-)

Answer 5

I'd start by looking at the functions the team needs to operate.

Some of the key things that need to take place:

1. There needs to be an architecture/high level design and it has to be looked after.
2. Regular builds and smoke tests are required.
3. There needs to be a good UI design, at least if you are in a competitive space.
4. The project needs to be coded and unit tested.
5. The project needs to be integrated and tested.
6. There needs to be a manager or team leader who represents the project to the rest of the company/your customers, and is responsible for managing the schedule, budget, staffing, equipment, requirements, bug fixes, etc.

With a small group like this, you shouldn't be using custom tools, so you shouldn't need a tools guy.

If you had a 10 person team - for example - there are some roles that are pretty clear cut:

1. You need 2-3 testers whose job is to test the end to end system. (item 5 above).
2. You need 1 team leader. (item 6 above).

The rest of the team (6-7 people) should be mostly writing code. Their specific assignments depend on their abilities.

Item 1 - architecture - can be handled by the team leader, by a senior developer with lots of credibility in the team, or by 2-3 senior developers.

Item 2 - build and smoke test - could be assigned to a tester, it could be assigned to a developer, or it could be rotated among developers.

Item 3 - UI design - this really has to be assigned to 1 person if you want a consistent UI. This shouldn't be a full time job with this size of team.

Item 4 - coding and unit test is the job of the 6-7 designers.