4

I'm working in a big software company and I'm developing a big enterprise-level web-solution with a team of about 25 people (2 architects, ~15 developers, 5 QA engineers, couple BAs, project manager). We are following agile methodology and scrum and it seems to be pretty convenient for such big team in circumstances of frequent requirement changes.

I also have one pet project - I have basic idea and I've started development. Currently I'm working alone, but I plan to propose to couple of my friends participate in my project.

Some time ago I've faced with a problem of proper task-tracking and formalizing requirements. My first thought was to use agile methodology as we used it with my team at work. While it is very convenient for my job, I have found it too much time-consuming for team with 1-3 people.

Is there any software development methodologies for really small teams? Or I should overcome myself and formalize all my thoughts into user stories and tasks and use iterations?

I don't want my project become just another folder on my disk, but I'm also don't want to waste time on unnecessary formalizations.

Improve this question
4
  • In my experience, projects with 1-2 motivated engineers barely need development methodologies, particularly if one of the engineers is also the person with the idea.
    – Gort the Robot
    Jul 7, 2014 at 20:29
  • 1
    possible duplicate of Advice for solo programmer whose team will expand in the near future
    – gnat
    Jul 7, 2014 at 20:47
  • @gnat thank you for link, but it does not say much about methodology, just useful things for collaborative work.
    – Illia Ratkevych
    Jul 7, 2014 at 20:48
  • 1
    Do not conflate Scrum and Agile. Scrum is a particular (or peculiar) Agile framework. Keep in mind Agile is really about any methodology that embraces the Agile manifesto. Other implementations of Agile are very light weight.
    – snakehiss
    Jul 8, 2014 at 6:13

1 Answer 1

Reset to default
6

In scrum you have periodic retrospectives where you adjust your process. If your process doesn't evolve over time, or if it looks the same for every scrum team in a larger organization, you're not doing it right.

Likewise, with a small team, you should have periodic retrospectives and adjust your process as your needs change. There's no need to nail everything down at the beginning. Typically, the formality grows as the project grows. You can still call it "agile" if you're focusing on quick adaptation to customer needs and other agile principles. It won't and shouldn't look the same as a large multi-team project.

If you're asking more along the lines of tools and practices, my small projects start out with just a git repository. Once I can't keep track of all the tasks/bugs/user stories in my head anymore, I create a TODO.txt in the repository. As it grows, I add things like unit tests, documentation, packaging, etc. At a certain point, I put it up on bitbucket. Later on, I transfer my TODO.txt into bitbucket's simple issue tracker. You could keep going up to CMM level 5 that would rival a DoD contractor's process.

In other words, you add formality as the benefits for doing so start to outweigh the costs.

Improve this answer
1
  • 2
    I'm inclined to agree: add infrastructure only as you need it. Otherwise, you lose many of the benefits of being a small team.
    – Robert Harvey
    Jul 7, 2014 at 21:00

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.