Software development process for small teams

Question

I might be an exception here but I have never worked on a team with more than three developers and / or five people. Still we could manage to get the job done (somehow).

Is there a software development process which fits this "extreme" scenario? And, if you work as a standalone programmer is there something you can adapt to your daily life to make it more predicatable, coherent, documented and still get the job done?

Answer 1

The agile methodologies are a good starting point because, imho, they are better suited for small groups.

As for keeping your personal working pace I'd recommend a method based on TODO lists and some tool like Task2Gather. You might want to look at GTD, too.

Things I would never give up even for a team of me:

• source version control
• backups
• TODO
• unit testing/TDD
• code documentation
• refactoring/code reviews

Answer 2

Most of the agile methodologies fit your profile.

The most popular is currently SCRUM. It's designed for productivity in small teams, and it's fans claim that development times are 5-10 times better than the traditional waterfall methodologies.

I recommend the Headfirst Software Development book if you want to get started on some reading

Answer 3

I'd recommend the Crystal Clear method

The Seven Properties

• Frequent delivery/integration using time-boxed iterations
• Reflect and improve, criticise and fix
• Osmotic (passive) knowledge acquisition and communication through office organisation and open channels
• Personal Safety, safe to be honest, confidence to court criticism
• Stay focused, clear tasks, priorities on work, limit the workload
• Access to expert users, fast, quality feedback
• The usual agile stuff: automated testing, CM, continuous integration

Answer 4

Let the mighty SecretGeeek teach you how to be a standalone programmer. Enjoy :)

   intellisense 
        ||
        \/
       code >>> compile >>>>> run >>>> success >>>> profit ;-)
        /\         ||          ||         
        ^^         \/          \/
        ^^      errors       errors 
        ^^          \\       //
        ^^           \\     //
        ^^             google
        ^^              ||
        \\              \/
         \<<<<<<<  copy N paste

Answer 5

TODO driven development

A serious suggestion from SecretGeek.

Set up your development environment or editor to automatically list all lines with TODO tags - Visual Studio does this by default.

Step 1

• Write Class or method outlines (ie, 'Public Class ...' or 'Public Sub...' with no code inside.)
• Include rough logic
• Add pseudo code preprended with "TODO:"
• Only write the very trivial code -- anything else just add a TODO

Step 2

• Repeat step 1 until the whole application is roughed out
• You've now got a big list of 'TODO' tasks
• Check for completeness (breadth)
• See what can be removed.
• See what can be simplified (eg, two similar todo comments: can they be made identical?

Step 3

• Replace TODO's with calls to non-existant classes, methods etc... (For test driven development, create exhaustive tests for each of these methods/classes)

Step 4

• Fix One Compilation error at a time by:
  • writing shells of classes, methods etc,
  • Adding TODO: pseudo code to each of these as you go.
  • (Also Add 'HACK: ' comments and explanations where appropriate, if pressed for time)
  • Where appropriate, replace TODO's with the trivial code required

Step 5

• Repeat Step 4 until there are no compilation errors left.
• If there are TODO's left, then Go back to step 3.

(There's also a lot of prior planning, paper prototyping, customer meetings, discussion, procrastination, database design, coffee-drinking, code-generation for sprocs and crud-sproc calls, import of re-usable DAL's, PAG block usage, go PAG!, back-and-forth debates prior to document sign-off, arguments, late-nights, frustration, chatting with friends, sifting through email, scratching in visio, printing things out and leaving them in a heap, scrounging for staples, catching buses, doing back and neck stretches etc., but that's all been left out for simplicity...)

(MarkJ again) A bit like the pseudo-code programming process from Code Complete. And we all agree everyone should read Code Complete, right?

Answer 6

Development processes are basically created for large teams to avoid possible chaos. If you're trying to do large projects by yourself, you will fail no matter what development process you use, as you'll need large numbers to accomplish what's needed in time.

If you work on small projects, then any Agile method should do. GTD is no method, it's a method wannabe. It's like me patenting my brain process.

Answer 7

Not a direct answer to your question, but Steve McConnell has an article named Less is More written more than a decade ago about why small teams are more productive.

Answer 8

Continuous Integration is the first thing I always try to get set up on teams I work on as I believe it is the foundation of good development practices i.e. Integrate often, automated build/release, self testing build, easy for anyone to get latest.

Read more about it here: http://martinfowler.com/articles/continuousIntegration.html