Agile for the Solo Developer

Question

How would someone implement Agile process concepts as a solo developer? Agile seems useful for getting applications developed at a faster pace, but it also seems very team oriented...

Answer 1

• By doing test-driven development
• By developing in small sprints
• By having a lot of contact with the customer

I remember reading a thesis about Cowboy Development, that is essentialy Agile for solo developers, but I can't remember where I found it.

Answer 2

Further to the answer from klez (all good suggestions), I'd suggest the following:

• Keeping a product backlog
  A product backlog is basically a list of all items you intend to complete at some stage for this product.
• Maintaining a sprint burndown and a product burndown
  A sprint burndown starts with a list of all tasks you've decided to complete in this sprint (a subset of your product backlog to be completed over a set period of time - e.g. 2 weeks) along with the estimate of the work required. As you mark things off, you mark them as done; thereby reducing (or burning down) the remaining work for that sprint.
  Similarly, a product burndown tracks the remaining work for the whole product backlog
• Adopting the concepts of relative estimation and velocity
  Relative estimation is an estimation technique that uses the other tasks (or stories) as a guide. For example, if you know task A is easier than task B and about as twice as complex as task C, you'd make sure the "points" for task A were correct relative to those expectations.
  The emphasis is not on correctly guessing the amount of work required, but keeping estimates consistent with each other.
  Velocity is a measure of how many "points" you get done in a sprint. If your relative estimation is ensuring consistency, this velocity can be used to estimate which tasks you're likely to get done in the upcoming sprints. Note though that velocity should be constantly revised.

Answer 3

• Limit work in progress (in addition to time-boxing). Even if you use an iterative method (as opposed to Kanban), let's say your velocity is 8 points per iteration. Don't start working on all 8 at once. Limiting WIP by either the number of stories or story points is fine.
• Have automated acceptance tests for all of your user stories. Automate as much as you can in general.
• Err on the side of making user stories too small. As a rule of thumb, make the ratio of biggest to smallest story 3:1. If you underestimate a story in Scrum and it turns out too big, multiple developers can swarm it to get it back on track. But you don't have enough people.
• If, in a regular-sized-team context, you would hesitate whether to split a spike off a user story - in the solo or small-team context, do the spike without hesitation. This helps to keep stories smaller and more predictable.
• Retrospectives are important in agile in general, so Kanban (that would be Personal Kanban) scores extra points here, because its retrospective process is more data-driven. It's hard to play Triple Nickels when you don't have enough people.

These things apply probably to both solo and small-team (2 or 3 developers) situations.

ADDED: sometime after I wrote this answer, I found this conference talk and was very impressed: Personal Kanban: Optimizing the Individual Coder

Answer 4

• Either work to well defined sprints, or deliberately choose a Kanban approach. Don't accidentally end up in Kanban
• Bugs first, features second.
• Still keep a focus on Value vs. feature bloat. (YAGNI over Gold Plating)
• Retrospectives are just as valuable. And just as importantly, make process changes in small chunks. Don't decide that today you're going start to go TDD, Mock and IoC in one shot unless you really have no external features to deliver ATM. Bring one in at a time.

Ultimately, I define Agile really as "doing what makes sense for your team and customer and not adhering to old practices because they happened to look like they worked in the past."

Answer 5

Wow. I'd try to keep a friend on the hook that I could call when I was in trouble - and talk through the coding problem. You know what I mean... just the act of explaining a problem out loud brings a solution to my mind 90% of the time.

Answer 6

Agile works just as well for individuals as it does for teams. It's about finding a process that works for you, and allowing you to adapt to changing circumstances once your project has already started. It's also about delivering value to your customer regularly, regardless of whether or not the software is actually "finished".

Agile processes are highly iterative. Work is done in short TimeBoxes/sprints/cycles/iterations. Some design work may be required up front, but can be refactored as you learn more about what it is you need a system to do. Unit testing is the backbone of nearly all Agile development methods, giving you an indication of whether your software is working, and if additions/changes to your software will break the existing code base.

If you adhere to BDD/TDD, allow your requirements to change with the wind and can adjust your feature priorities accordingly, if you build your entire system and run all of the tests often, and if you deliver working code at the end of each sprint, you are already Agile.