

Ask HN: Agile for a team of 2? - cuchoperl

We are a team of two (developer + UX/UI designer) working in a web app. We are just starting and we are looking for a way to work seamlessly.<p>What Agile practices would you recommend us to start with?<p>Thanks
======
dirtyaura
Don't bother too much about how to split work, how to manage schedules, how
not to step on each other toes (I actually recommend doing it). This all comes
naturally.

Worry mostly about focusing and decision-making, how to cut unimportant stuff
early enough. With 2 guys, that's the big challenge.

------
xd
It's not "agile" but very much suited to your situation, MVC, as a developer
you would maintain the Model and Controllers. The UX/UI designer sticks to the
Views. Apply agile methods around this. As to which, you will need to
experiment and see what works for you.

And take the time to learn each others skill sets and talk about the reasons
why you do things the way you do. Most of all challenge each other on a daily
basis.

Oh, and have fun.

~~~
haploid
This. Hopefully you've selected a component or mvc web framework that enables
clear separation of roles, to minimize integration bottlenecks.

As for processes, Scrum methodologies such as the daily stand up meeting and
weekly defined iterations would probably be beneficial. But take that with a
grain of salt, since some teams simply don't work well with such fixed
parameters. Give it a try, but don't stick to it out of obligation. Stick to
it if it works.

------
dennyabraham
From working in extremely small things myself, I can recommend a few things:

1\. Write tests around everything you have the time to.

2\. Communicate frequently.

3\. Try to write things in vertical (shippable) slices.

4\. Work in short iterations.

5\. Keep what works, drop what doesn't

Ultimately, the most important element to reap the benefits of 'agile' was #5.

------
stewiecat
I did a pseudo-agile process for a project where I was the solo developer. A
lot of agile practices scale down quite nicely: defined scope, sprints, unit
testing, etc. The key is to keep everything small: short sprints, small
features or small parts of large features. ALWAYS deliver a shippable product
at the end of each sprint, even if its just for morale purposes.

------
dcaldwell
We're a team of three working on a web app and we use Pivotal Tracker. We use
it more as an agile-y way to do project management instead of something like
Basecamp.

------
jonezy
in that small of a team i would say focus on one to two day sprints with
releases to production at the end of day two.

unit testing is NOT agile (it's extrememe programming) but you should still do
it.

be sure to continually evaluate whether what your doing makes sense, if it
doesn't drop it/change it.

------
kiriappeee
Depends on what the app is as well and how you can split the work up into
stages. Are the features clearly defined? Can you work on small feature driven
iterations? Or is it better to work on goal based sprints? One general piece
of advice I can offer is that since you are a team of two you might not need
to take an approach which has a large review based section in it. This is
again purely situational. If you are doing usability testing then this can
change. Also are you two working in the same location or is it remote? In the
end the methodology has to suit your needs. Consider the above stuff and if
you can hit us back with a bit more details I'm sure there'll be more specific
answers.

As for specifics... Look into FDD. Feature driven development.

Oh and good luck with the work :)

Edit: by less review I don't mean testing and stuff. I mean formal and rigid
sort of meetings every week. Sure have a proper review at regular intervals
but most of the reviewing should be happening automatically with every
feature/sprint completed.

