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?

Manrico Corazzi · Accepted Answer · 2008-10-03T12:54:18.327

23

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

edited Oct 03 '08 at 12:54

answered Oct 03 '08 at 10:26

Manrico Corazzi

11,299
10
48
62

1

@Manrico: As a team of 1 (me) also, I do source control, backups and have todos but not unit testing (apart from just trying my web apps manually through a few common scenarios) and code reviews. Do you have any advice on how I can start to add these? A blog about your process would be awesome! ;) – Sprogz Oct 03 '08 at 11:26
@Sprogz: here you are (it's just a draft) http://babilsenior.blogspot.com/2008/10/test-driven-development1-eng.html – Manrico Corazzi Oct 03 '08 at 12:35
@Manrico: Thanks very much! I've read a number of texts about the theory of TDD but I'm really missing hands-on examples of how ordinary developers are using it to help their development process. Your blog post was helpful and I'm very interested to read more! Nice work. I'll bookmark your blog. – Sprogz Oct 04 '08 at 14:03
I really think "Staffing" is not a factor...Agile is to minimise cost, not incur. It is a style, not rule. 5 or 500, agile can always be good :) for all the engineers involved. You can have a tailored-Agile (i.e. not all the practices are required for your purpose) but still maintain good programming practice for your final product. – ha9u63a7 Jun 20 '13 at 08:20

MarkJ · Answer 2 · 2009-10-20T09:06:46.483

6

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

edited Oct 20 '09 at 09:06

answered Feb 28 '09 at 21:15

MarkJ

30,070
5
68
111

1

Change the last part to "success >>>> ? >>>> profit" and I'm sold. – Robert Groves Dec 31 '09 at 05:57
1

I guess that's why not all developers are rich... I'm still looking for that bridge between success in development and profit. – rshimoda Sep 09 '10 at 13:27

score 5 · Answer 3 · edited May 23 '17 at 12:00

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?

This is really straightforward and, even though it seems to be rather clunky, it works when developing alone a huge project where you can no longer remember what is missing — rshimoda, Oct 20 '09 at 19:07

score 4 · Answer 4 · answered Oct 03 '08 at 10:30

4

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

answered Oct 03 '08 at 10:30

s3v1

2,923
2
33
25

Scrum is what I'm currently doing with my team. I admit some of its tenets are a bit theatrical, but we're getting better at it. Now that you mention it... WE FORGOT OUR DAILY MEETING! :O – Manrico Corazzi Oct 03 '08 at 10:38

score 4 · Answer 5 · answered Oct 03 '08 at 10:43

4

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

answered Oct 03 '08 at 10:43

epatel

45,805
17
110
144

For a split second I thought you were suggesting this: http://thedailywtf.com/Articles/FrontAhead-Design.aspx :D :D – Manrico Corazzi Oct 03 '08 at 13:24
Crystal clear worked for me even better than Scrum did (and I'm a CSM) – rshimoda Oct 20 '09 at 19:05

score 2 · Answer 6 · answered Oct 20 '09 at 08:49

2

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.

answered Oct 20 '09 at 08:49

Milani Milivoj

21
1

There has to be an accepable (amount of work)/(number of people in team) ratio, for sure. – rshimoda Sep 09 '10 at 13:24

score 1 · Answer 7 · answered Oct 20 '09 at 10:05

1

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.

answered Oct 20 '09 at 10:05

Martin Liversage

104,481
22
209
256

Quite a nice article but really away from the main theme of the question. Currently working on a 11 people team and finding it very demanding in terms of communication. – rshimoda Sep 09 '10 at 13:23

score 1 · Answer 8 · answered Oct 20 '09 at 10:10

1

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

answered Oct 20 '09 at 10:10

Burt

7,680
18
71
127

You know, continuous integration is something the whole company could benefit from, but I can't see it saving a lot of work for tiny teams - from 1 to 5 people - as long as they communicate a lot - at least not as much work as it takes to get it up and running. – rshimoda Sep 09 '10 at 13:26
There are tools out there that take the work out of setting it up (teamcity). It is up to you whether you choose to implement it but it is one of the first things I try to get set up when working with a large project as I think it is vital. Having a one click build that builds everything including iinstallers and maybe even deploys has saved me countless times, there is nothing more embarressing than releasing a product only for human error to have caused it not to install. CI removes human error. – Burt Sep 13 '10 at 10:35