There’s no reason a lone developer implementing Agile can’t continue to do (and benefit from) some or all of the following:
- Create clearly defined, small chunks of work (i.e., user stores)
- Work in short code sprints and have frequent, incremental product releases
- Keep a backlog of user stories and possibly a (Scrum) board to track progress
- Hold daily “standups” before starting work each day (i.e., review what was completed the day before, what issues there were and what needs to be done today)
- Keep track of how long it takes you to do tasks and how many tasks get completed in a sprint (burndown rate/velocity); this is key to accurately estimating how long future tasks will take and future sprint planning
- Do test driven development (i.e., create automated/unit tests before writing code)
- Refactor code regularly
- Conduct retrospectives
- Communicate frequently with the client, to provide regular updates and product releases and solicit feedback and input
One issue that can be a common problem for developers working alone (regardless whether s/he uses Agile) is not having another coder around to help with problems. One common solution is Rubber Ducking: having a rubber duck (or a teddy bear or anything really) nearby to describe your problem to. Many developers find that simply having to clearly state your problem out loud - or in writing, for example to an online forum - can help reveal the solution.
In the end, though, there’s no reason to think that Agile, or some portions of it, can’t be used by developers working alone. As many suggest, one of the key tenets of Agile is flexibility, so find which parts of Agile work best for you and apply them. In general, using a formal methodology (Agile or otherwise) can help to provide structure and process to those developing alone.
Just remember, if you work alone, that’s no reason not to wear pants.
Are you a solo developer using Agile? Please share your experience in the comments.