Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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...

share|improve this question
45  
I just tried to adopt pair programming as a solo developer, and it improved the quality of my work! –  Lorenzo Sep 1 '10 at 22:04
1  
+1 Awesome question! –  Walter Sep 1 '10 at 23:10
3  
I lol'd at Lorenzo's comment. Good question btw. Been wondering about this myself. +1 –  Terence Ponce Sep 16 '10 at 7:36
add comment

6 Answers

up vote 37 down vote accepted
  • 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.

share|improve this answer
12  
I would strongly disagree with the assertion that "Cowboy" development is Agile, even for a solo developer –  Travis Christian Dec 14 '11 at 15:58
    
@a.brookshollar: Please leave your comment as a comment, not as an edit to the answer. –  pdr Nov 14 '12 at 15:48
1  
@TravisChristian - It's more Lone Ranger. –  JeffO Nov 14 '12 at 15:49
3  
Here is a link to the thesis, which @a.brookshollar tried to leave as an edit. –  Scott Whitlock Nov 14 '12 at 16:05
    
I'll wager that neither Travis nor the 11 people who voted his comment up has read the thesis in question. The full title is "Cowboy: An Agile Programming Methodology For a Solo Programmer" and, while a bit dated, it is worth a read. –  Brien Malone Nov 26 '13 at 19:06
show 1 more comment

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.
share|improve this answer
    
Product backlog, burndown, relative estimation (story points) and velocity are all essential agile practices. None of them is specific to the solo practitioner situation. –  azheglov Sep 24 '10 at 3:19
3  
... as are TDD, sprints, and customer contact... –  Damovisa Sep 28 '10 at 0:08
4  
would be good if you also told what all this lingo means. I'm as clueless as I was before i read this answer.. –  Click Upvote Apr 13 '11 at 15:10
    
@ClickUpvote: that's because none of this lingo answers the question ;-) –  azheglov Dec 14 '11 at 0:58
1  
@azheglov Wow, didn't need to cause offense. I was highlighting which parts of Scrum I think are most useful in a solo developer scenario rather than how to apply them. None of these techniques should change at all for a solo vs team, so they'd be applied in exactly the same way. To mirror your words - there's nothing in these techniques that is specific to the micro-scale. –  Damovisa Dec 15 '11 at 7:23
show 5 more comments
  • 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

share|improve this answer
add comment
  • 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."

share|improve this answer
add comment

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.

share|improve this answer
4  
That's MOST of the value I get from somewhere like stackoverflow. I can't tell you how many questions I've typed out and then not hit submit on. –  Dan Ray Sep 23 '10 at 18:24
4  
Related: c2.com/cgi/wiki?RubberDucking –  Jo Liss Jan 27 '11 at 11:04
    
Rubber ducking is great concept (discussed in relevant questions here) but how does this answer the question asked? "How would someone implement Agile process concepts as a solo developer?" –  gnat May 23 '13 at 14:47
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.