tags:

views:

419

answers:

8

Looking for work at the moment, I'm seeing a lot of places asking for Agile experience, but until I get a job with a team that is using Agile, I suspect I'll never get the experience.

Is it possible to adopt Agile methodologies with just one person?

Sort of answering my own question, there's similar questions at :-

I guess I should get better at searching :-p

+2  A: 

Some aspects can be done alone: running a product backlog and using a task board come to mind. See what the secretGeek is doing.

Of course some cannot: pair programming, scrums etc...

Oded
Nice - I can put my home office whiteboard to good use rather than using the piece of A3 he suggests though.
Rob Cowell
+1 for the link if I had votes left... :)
Tor Valamo
+1  A: 

Definately. Agile is very flexible in terms of how many people are involved. Some methodologies, like Scrum, focus mostly on doing as much as possible in a limited time, like two weeks (sprints). That includes whatever you want it to. If your team requires QA, then that is part of it. As a loner, you decide what you want to include.

After the scrum sprint, you look at what you could have done differently to get more done, and move to the next one.

Some other methodologies focus more on getting features done in each iteration, say three small features developed, tested and refactored.

As you can see, there are tons of ways to apply agile to any project. You decide which aspects you want. Though obviously one integral part is doing things in small increments.

Tor Valamo
I guess this leads to a subsequent question then - How do I prove to a prospective employer I adopt such practices when I'm doing it solo?
Rob Cowell
Explain how your system works and how it helped you accomplish the task.
Tor Valamo
+4  A: 

Yes

Check out PXP or Personal Extreme Programming.

http://portal.acm.org/citation.cfm?id=1593127

Summary from the paper:

Personal Extreme Programming (PXP) is a software development process for a single person team. It is based on the values of Extreme Programming (XP) i.e. simplicity, communication, feedback, and courage. It works by keeping the important aspects of XP and refining the values so that they can fit in a lone programmer situation. PXP can still be refined and improved. It is in the tradition of XP practitioners to vary XP to encompass whatever works. We hope that PXP inherits these pragmatic roots, as well. Giving up XP tenets like pair programming is not necessarily a tragedy. We still believe that following XP strictly is a more effective way to pursue multi-person projects. But we are also convinced that many of the XP practices and methods can be applied to individual work. The PXP approach tries to balance between the "too heavy" and the "too light" methodologies. PXP will inject the right amount of rigor for the situation without overburdening the team with unnecessary bureaucracy.

Finglas
If you can't see the paper. Try Googling the term. Pair programming is natrually void, but everythig else works. I'm using it on a project now.
Finglas
Interesting concept - is there a way to actually see the paper without having an ACM member login though?
Rob Cowell
The comparison table is much bigger than I remembered, so instead I'll post the summary.
Finglas
+2  A: 

Pair programming would be hard this way :)

Let's check Agile Principles:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

You can do all of those things even while working on some personal project alone. You can use also GTD while working alone, you can develop your product through iterations, you can adopt timeboxing, you can ask some family members or friends to do usability tests with you (and this works really well).

As a conclusion, you can really get tons of Agile experiences alone. I strongly recommend you to read some books first tho, as some of principles can be easily misinterpreted.

Ondrej Slinták
+1  A: 

While some Agile practices are directly targeted at more than one person teams, they are just practices, they are just a mean, not an end. I mean, Agile is not about doing pair programming, stand up meetings, etc. Agile is about maximizing the customer value while minimizing waste to provide the most optimal ROI. Agile is business oriented, practices are just a way to achieve this goal in a given context. So, back to the initial question, it's definitely possible to adopt Agile practices (that make sense in your context) to maximize the delivered value: continuous planning, limiting Work In Progress, Stop-the-Line culture, time boxing, high quality, just enough specifications, just enough and just in time documentation, etc, etc.

Pascal Thivent
+1 Everyone seems to be focusing on Pair Programming, but as you point out this isn't the be all and end all to Agile - indeed, the main argument for PP seemed to be to to aid knowledge sharing where it is hampered by a lack of documentation elsewhere.
Zhaph - Ben Duguid
Pair programming comes more from XP (which is more prescriptive) than Agile/Scrum.
Greg K
Agile!=Scrum, Agile is just an umbrella term for many methods, Scrum and XP being some of them. And while Pair Programming is one of the XP practices (which captures many practices **as an indivisible set**), XP doesn't have the exclusivity of Pair Programming, you can use it outside of XP.
Pascal Thivent
A: 

Yes, if you have multiple personalities disorder :P

X-Istence
I've got some karma to burn (as they say on Reddit, and Slashdot). Hint: This was meant as a joke.
X-Istence
+4  A: 

You seem to be coming at this from a work experience point of view; if you are looking to build relevant experience to get you a job on an agile project I would probably think a little more laterally.

Firstly could you work with others, maybe on an open source project? That would be a good opportunity to try out agile methods with others who may have more experience.

Secondly, you could look at using some of the common techniques or tools, even if it's just to learn how the tools work - e.g. you could set up a continues integration server to run builds and unit tests when you check in code. If you are working on your own you won't gain much in terms of productivity by doing this but you would gain some skills and have something relevant to say to future employers which would indicate you are committed to the agile style.

Steve Haigh
I'm gonna mark this one as accepted, since you pick up on the work experience aspect and provide practical advice on how to demonstrate it to potential employers
Rob Cowell
While open source might be one way to get experience, due to its distributed nature and rarely meeting people face-to-face, I don't know how effective it would be vs commercial experience of from working in an office where it's easier to collaborate and share ideas with colleagues.
Greg K
@greg Sure. Things liek scrum or pair-programming aren't going to work, but other aspects might e.g. no reason not to do TDD or CI. Not sure if they are strictly under the definition of "agile" but I think there is useful experience to be had there.
Steve Haigh
+1  A: 

Yes - it is possible to do many agile practices as an individual.

If you already know how to do these, you can do them as a sole developer:

  • test-driven development - great place to start
  • refactoring
  • continuous integration
  • doing the simplest thing that could possibly work (and evolving it through refactoring)
  • automated deployment
  • planning meetings (a team of one plus customer)

Things you can't do on your own:

  • pair programming (... so you'd need to do code reviews...)
  • CRC/RRC workshops (... you'd have to talk to yourself quite a lot)
cartoonfox