How would you propose running a development team with 4 developers and 1 QA

We’ve already talked a bit about Agile Development, but it really is the best thing to happen to software development since the introduction of object oriented design. Indeed, a small team is particularly sensitive to the dangers of coding without proper analysis, design, testing, prototyping and feedback from the clients.

In a nutshell, Agile development ensures the early communication of problems, testing of potential bottlenecks early in the product life cycle and constant constructive criticism from the potential users. In other words, energy is directed primarily towards aspects of the product development that are relevant, rather than on tangents that lead nowhere.

I would also encourage everyone on the existing team to be involved in all aspects of the life cycle, since presumably they will form the core of a much larger team eventually. Therefore we want them to develop good habits and skills, which will allow them to mentor others later. In addition, it would be very important to emphasize the role of the QA person and eventually of the QA team.

It’s easy for keen developers to forget the critical importance of testing, starting with unit testing and peer-review of their own code. Fortunately, the Agile approach tends to naturally encourage the integration of testing and programming, since products are developed iteratively and mini releases occur every couple of weeks or so.

Encouraging an atmosphere that is open to new ideas is essential to creating an environment conducive to growth. That includes constantly looking elsewhere for new ideas and better ways to get things done. If the budget permits, occasionally sending team members off to conferences is an effective way to foster growth, confidence and innovation. The best run companies also tend to maintain a sense of family, even as they grow.

Finally, design and documentation remain an important part of the life cycle, although their role is somewhat diminished with Agile development. This is because both can become quickly obsolete when iterative application development leads to early testing of prototypes and rapid changes to the product, based on client feedback.

Nevertheless, all code must be documented by developers and the business requirements must

be translated into specs that the programmers can refer to. Furthermore, new personnel will need some guidelines to be available, as they try to learn how to integrate into the existing team.

However, people like me can handle a lot of that, in order to ensure that the analysis, design and development processes are recorded, but without constantly bogging down programmers with documentation requirements. The short, daily “scrum” meetings associated with Agile development are also a big part of this process. Ultimately, it’s just a question of remembering

to first “say what we do and then do what we say”