Agile Methods Specifically taylored to working solo?

Most Agile Methodologies I'm reading about speak volumes about how best to keep communication bottle necks within a team to a minimum. When working as a solo developer, most of these don't really apply. Stand up meetings are "interesting" when done alone for example. :)

My question is, when working solo, from what particular methodology would a solo developer extract the most value?

From stackoverflow

• http://c2.com/xp/ExtremeProgrammingForOne.html

• Instead of choosing a particular methodology, I would look around at the practices in different methodologies and adopt those that help you be agile. For example, I use stories, though I keep them in a wiki instead of on story cards. The wiki works better for me since my customers aren't co-located and putting story cards up on a wall for just myself to see doesn't add enough value. I also use TDD, two-week iterations, and monthly release cycles. It ry to get the customer involved in writing my stories as possible and specifically talk to them about developing small units of functionality that I can deliver early and often.

• I recommend one-man scrum, 'pomodoro'.

  http://blog.crisp.se/henrikkniberg/2009/01/19/1232358360000.html http://www.tecnicadelpomodoro.it/docs/francesco-cirillo/2007/ThePomodoroTechnique_v1-3.pdf

  Marnix van Valen : I tried the pomodoro technique this week and it really helps to keep focus. Great tip!

  CAD bloke : The PDF and other resources are now at http://www.pomodorotechnique.com/resources.html

• At least two possible approaches:

  • Scrum - use a personal task board whether with a physical whiteboard/corkboard, or an electronic version (I'm using scrumy.com and its very nice).
  • Kanban - I haven't tried it yet myself, but I intend to try it within a few weeks. The main idea here is that you don't manage iterations, you manage the flow of tasks/stories from the backlog to completion, with attention on not juggling too much at once. Kanban is great for allowing you to focus, avoiding too much multi-tasking, and is very light-weight in nature. a physical kanban board is very easy to use. (see http://www.infoq.com/articles/agile-kanban-boards). specifically the portable kanban mentioned ni http://www.infoq.com/articles/hiranabe-lean-agile-kanban sounds like a nice idea for an individual.

  PS If anyone is aware of a good SaaS web-based electronic personal kanban (like scrumy.com is for Scrum) please let me know!

  Michał Drozdowicz : Have a look at http://agilezen.com/

• Aside from the other great advice - keep a teddy bear at your desk. Every time you're struggling with a problem, explain it to the bear. Usually about half way through the explanation the problem will become apparent.

  tooleb : and if he starts talking back or interrupts too much - TAKE A BREAK!

  projecktzero : Sounds like the rubber duck method of debugging: http://lists.ethernal.org/oldarchives/cantlug-0211/msg00174.html

  kdmurray : This totally works. If you don't have a teddy bear try explaining it to your non-technical spouse or other family member. :)

• I've been working on small solo projects for years and recently one of them has grown into a moderately large project. So I've been facing this same challenge.

  Simply by virtue of being solo, you'll be able to adapt what is the fundamental advantage of agile project management - the ability to change requirements on short notice.

  The other good thing about the agile method is it encourages you to have something 'buildable' / usable after each set period of time, say a week. Not that it necessarily does something useful, but you never have your app in an unstable state.

  The point is, that being solo, you have the flexibility to take the best parts of the various methodologies and adapt them to your needs. As long as you keep your self organized - try a free project & task manager , and a personal wiki, you'll benefit. No methodology by itself will help much if you're disorganized, or simply following it because it's the PM flavour of the year and not based on it's merits for your particular situation.

• You need to consider Project Managers, Owners, Stakeholders, and Users as part of the team. I've actually been able to sit down with users while developing (esp. GUI, reports, workflow, logic, etc.).

• The two agile practices that I get the most benefit from when working solo are

  • Keeping a prioritized backlog of work, and working through that list one, and only one, item at a time
  • Writing tests as I go (test-first when possible, test-last otherwise), and only checking in work when all tests pass

  The former keep me from losing focus and finding myself off in the weeds. The latter helps me move quickly and gives me a safety net for trying risky things.

  For one-shot, scratch-an-itch projects, I'll sometimes skimp on tests to little ill effect, but taking things multiple steps at a time is a sure recipe for burning up time.