Project methodology for small teams

Question

We're usually 1-4 developers / art directors / copywriters on each project at my firm, what methodology would you recommend use to use? Agile? XP? Scrum? Something else? (I know they are all variations of essentially the same concept, yes)

Answer 1

I don't think there's a general answer for it, the question is too broad, and you can't just "adopt a methodology" as if it were a product that you take out of the box, it's something that you evolve over time...but in any case I highly recommend you getting a copy of this book: Head First Software Development

Then you adapt the ideas you like into your project. Don't worry about names and buzzwords, they will be all "passé" next year anyway. Keep it simple at first, adopt the ideas that make more sense and give the most bang for buck, and don't try to solve problems that don't exist yet. It will be a very good start.

Answer 2

For pair programming, at least, it's best to have an even number of programmers... ;P

One of the good things about small teams is that you don't need a lot of support systems to communicate internally (a bugtracker becomes more or less a todo list for yourself, but it's good to have anyway). If having a meeting with the whole team just involves turning around your charir and say "Hey, Bob and Carl, take a look at this!", you don't really need all formal rules of a methology anyway. But agile methods in general is quite well suited to small and medium sized teams, but they require self-motivated team members.

I'll say pick whatever ideas you like from the different methologies, they can be considered suggestions anyway.

Answer 3

They are very close to business side which is bad thing because programmers often do not understand well implications of accounting, time or risk management, etc. Even if they think they do. They see business as another attractive opportunity to improve their sophisticated technical skills. As company is small it is may be overkill to implement complex methodologies inside development team. They can handle technical questions easily themselves. What they cannot handle is understanding that if they are close to business environment does not mean they are not programmers anymore.

I suggest to implement some simple policies which would ensure discipline and focus on technical side rather then talking with customers about technical topics which is what some programmers like so much.

Answer 4

The answer is, proverbially, it depends...

Each team is a blend of personalities and abilities, and each team member is different. Rather than focusing on finding a "methodology" per se, I would recommend that you concentrate on what each team member needs in order to succeed and couple that with what the project needs to succeed. You'll find the right methodology and mix of processes between those two considerations.

As an example, I have been leading a small team (three full-time developers plus some part-time UI designers) for the past seven months. I've found that the following practices/procedures work well for us...

• Adopting short (60-90 day), well-defined spirals, which keep the team focused and delivery-oriented and helps us minimize risk.
• Adopting an iterative lifecycle, in which we make a few incremental deliveries to the client during the course of a spiral and discuss what we've done. Doing so allows us and the client to ensure that we are addressing their needs.
• Tailoring tasking and direction for each team member. For example, one team member is a more junior developer, while the other team member is a very good developer but doesn't handle open-ended tasks well. They require different approaches.

Naturally, I've also tailored CM processes and testing practices to suit the project and the team's needs.

Answer 5

For such small teams, I would definitely look at an Agile approach to software development. Personally, I'd probably use a blend of XP, Scrum and Lean, because I know those best. Especially if you are new to Agile, XP provides a good starting point from which you then can find your project-specific adaption. I highly recommend the book "The Art of Agile Development".