Take the 2-minute tour ×

This question already has an answer here:

I am a freelancer and work as a single developer. In all cases, I am the person wearing different hats. I am the Scrum Master and I am the only person in the development. What I am not is the Product Owner?

Are there any Agile Methods and free tools that a freelancer can make use of?

share|improve this question

marked as duplicate by gnat, Bart van Ingen Schenau, Kilian Foth, Jalayn, Joris Timmermans May 23 '13 at 12:57


+1 - Keep in mind that many parts of Agile development models are about keeping the whole team in the loop, so to speak. If you're going solo obviously those parts of those models may be omitted. –  Billy ONeal Mar 28 '12 at 5:53
Several closely related (possibly duplicate) questions exist already - see programmers.stackexchange.com/questions/tagged/… –  Péter Török Mar 28 '12 at 7:27
Develop a multiple personality disorder. –  Mathew Foscarini May 23 '13 at 14:10

4 Answers 4

up vote 19 down vote accepted

The goal of Agile is to...

  1. minimize all feedback loops as much as possible

  2. minimize project overhead in terms of documents/forms produced and replace it with much higher bandwidth medium, which is real-time (preferably face-to-face) communications among team members.

If you do more research about agile, a lot of it will talk about teams and the interaction between members. That's because with every Nth member, number of lines of communications within the goes up by N. As N goes up, you face additional challenges such as training/knowledge dissemination, coordination of effort...

A lot of the problems that an agile team would face, you would definitely not need to worry about, but the main area where I would focus is (1) - minimizing feedback loops. Even as a single developer this comes in very handy because the sooner you identify problems (whether it is requirements, design or implementation) the less expensive it will be to fix those problems.

This is what I would do:

  1. Make it a point to meet with your customers on regular basis and make sure they...

    • know exactly what you've done and provide you feedback as soon as possible
    • know what you are working on next and confirm those are the features they actually want given what they already see as being completed
  2. Spend some time on ironing out deployment/packaging. A little of upfront cost will ensure that with one button click you can roll out a fully deployable version of your application which can be instantly tested. I'm not sure how much continuous integration server would benefit a one-person team - curious what other's would say about that.

  3. You can manage your product backlog much the same way agile teams do it. However, since you are working by yourself, I would skip using any type of fancy software and even whiteboard with posted notes and go right to a text file (maybe excel sheet) that lists work items. Prioritize them and regularly review them to make sure that you are not missing anything and that the important things are taken care of first. If you want to try something a little fancier, Trello, might be a good option

  4. Consider moving over to TDD. A year ago I was a bit skeptical and considered TDD only useful for low-level utilities that have no dependencies on anything else. But in the last year, I've tried the approach several times and each time was extremely surprised at the results. Yes, it is a hefty chunk of upfront cost, but it seems that the benefits from having your code easily testable/verifiable ends up paying you back crazy fast.

    • TDD will instantly tell you if you made a mistake in the code and you can easily verify that your classes/functions behave properly in boundary conditions. Alternative is typically to "do your best", but you end up finding bugs during testing and then you end up spending hours isolating and debugging the problem.
    • With unit tests in place, you won't be nearly as scared about refactoring and significantly altering the design as new features are added. I noticed without TDD, most people tend to be scared of touching code that's already been tested (and rightfully so). In a lot of cases, they keep adding on more and more, while afraid to alter what's already there and the code ends up looking like a legacy spaghetti mess even before v1.0 is shipped.
    • With tests in place and being able to refactor at will, also gives you the advantage that you don't need to stress as much about getting the design right the first time since it becomes that much easier to alter the design as needed later on.
  5. Carry out your own retrospectives. One of the key messages of agile is that change should be welcomed and that we should never settle into a rhythm where the same thing is being done over an over. Periodically evaluate what you are doing and try to identify areas were you feel different approach could make your more efficient. Don't be afraid to adjust the process (or sometimes drastically change something, if for now other reason, then just to see what would happen) and tailor your practices to your specific situation.

The advice I provided is based on the type of work I've done, which mainly involves working on an application sold as a product. We work on the same code base and keep extending/improving the same application with each new release. Advice might be different if your primary source of income is coding as a service (i.e. write some code, sell it, never see it again). The impression I'm getting is that developers in the services area, tend to skip TDD and many other practices since extendable/maintainable code is not their priority. Instead, they focus on time to completion (i.e. minimizing costs) and making sure that v1.0 (which is the first and last version) passes customer's acceptance criteria.

share|improve this answer

Regarding tooling, have a look at https://www.flying-donut.com. It is a new online product, and I've used it for my solo projects and team projects with great deal of success. It is inspired by scrum and could easily host any iterative project. In Flying Donut you are working on iterations and items. Items are then broken down into tasks.There is a nice way of organising your backlog and its GUI is clean with quick response times.

Regarding the methodology I think that scrum is suitable to freelancers since the methodology has a clear communication path to the client. And yes you will be the product owner. The product owner is the one that makes sure that the client gets what he wants. And you will be the team that is delivering functional code. And finally you will be the scrum master to make sure you are on schedule and remove any impediments the team (you) has. It sounds harder that it is. The iterative mode comes to the rescue. If you do weekly or biweekly sprints and have a clear communication path with the client and the client sees what he is getting then you can quickly respond to potential emerging requirements the client never thought of.


share|improve this answer
would you mind explaining more on what it does and why do you recommend it as answering the question asked? –  gnat May 23 '13 at 14:44
I revised the the answer after gnat's comment to a more complete one, as I should have done from the beginning –  Ioannis Tzikas May 23 '13 at 19:54

Maybe Personal eXtreme Programming might be something you might want to take a look at?


It's a method that is a combination between extreme programming practices and the practices of the Personal Software Process(PSP) devised by Watts S. Humphrey of Carnegie Mellon University. PSP is quite rigid in its approach and not agile. PXP is a more agile adaptation of personal software development. PXP isn't really something you'd call mainstream, but I've used it in the past, and it has worked for me. I've adapted a PXP approach based on some papers I've read on the topic:


PXP involves the following PSP practices:

•Time Recording: Basically your time sheet. This is useful to determine your rate of progress.

• Size Measurement: You have to have some kind of metric to measure the amount of work you've done. Usually this boils down to Lines of Code (LoC)

• Defect Type Standard: A list with which you catagorize the types of bugs you encounter.

• Process Improvement Proposal: You have to have some kind of plan to improve your own process. Basically you'll need to plan some activities for self evaluation and review. You'll have to make a plan before implementing it. (And review the plan once in a while to tweak it)

• Defect Recording: You have to keep track of the bugs you found so you can analyse your behaviour afterwards.

• Code Reviews: This is a bit tricky, but somehow you have to review your code. I din't find this particularly interesting until I managed to mentally detach myself from my own work. Still you usually don't spot your own faults as easily as others do.

There area also some XP related activities:

• Continuous Integration: PXP includes the practices of source control versioning, automated builds, automated test executions, and automated defect submitting. I find this practice very usefull. (I prefer the gated check-in approach, but that requires some scripting to set up, you might find that to be too much trouble)

• Simple Design: KISS! You probably know what I'm talking about. (if not, google it)

• Small releases: Make the milestones in your sprints small enough to keep things in perspective and not run the risk of spending a huge amount of time on features you've committed to, but can't deliver on in time.

• Refactoring: Standard agile practice, really.

• Test Driven Development: This too shouldn't be too unfamiliar.

• Spike Solutions: if you have a problem that you're new to, or that is hard to solve, take a step back and try to solve it in a stand alone setting before you try to integrate it in your big project.

TL;DR: it boils down to the tracking rigor present in the PSP/TSP (CMMi) style combined with common practices of XP minus the team efforts that are required for XP style processes.

share|improve this answer

As of tools you can make use of, you may want to try Pivotal Tracker.

share|improve this answer
