Ask HN: Agile for a team of 2?
10 comments
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.
Worry mostly about focusing and decision-making, how to cut unimportant stuff early enough. With 2 guys, that's the big challenge.
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.
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.
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.
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.
[deleted]
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.
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.
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.
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.
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.
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.
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.
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.
What Agile practices would you recommend us to start with?
Thanks