Project methodology for small teams [closed]

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)

Garrygarson

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.

Felucca

Update: It is the year 2012 and Scrum and Agile are not yet passé. – Legge

Update: 2016 now, still not passé – Eiten

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.

Brazell

In my experience, Agile approaches, if implemented well, create self-motivated team members. – Latashalatashia

Answer 3

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".

Oraliaoralie

Answer 4

My 3 developer team simply uses Kanban + continuous deployments and it keeps us moving rapidly. I've looked at Scrum and others and there's too much overhead for our small team.

Anthropomorphism

Answer 5

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.

Haire

Well, I'd say that exactly because programmers don't understand the business side very well, they should work close together with those who don't. A well run project needs the business side and the technical side to be in line. Agile approaches accomplish that. – Latashalatashia

What is Agile? A magic wand? =) Developers do not know what business is about and clients do not know what programming is about. Direct contact between them only brings misunderstanding and bad practices – Haire

Answer 6

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.

Entrance