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?
How can a single developer make use of Agile Methods?
agile;scrum;solo development
The goal of Agile is to...minimize all feedback loops as much as possibleminimize 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: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 possibleknow what you are working on next and confirm those are the features they actually want given what they already see as being completedSpend 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.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 optionConsider 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.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.