How to apply agile to personal projects?

Question

After learning about source control the first thing I did is do a project with svn. After learning about git I used it in a personal project. After learning about UML/Design Patterns/Design Principles/TDD I applied them to a personal project. How can I do the same to agile development? Is agile just for teams and big projects? How do I set up these iteration things?

Answer 1

It is going to be hard to do pair programming...

Answer 2

For example, don't be afraid to refactor your own code, even if it works, if the result is more flexible and robust.

Answer 3

It's hard to truly apply agile coding to one-man projects because many of its benefits are aimed at small teams where you can quickly collaborate on focussed areas.

That said, you can adopt some of the techniques:

• Release often
• Focus on your users' needs
• Feel free to deviate from major version plans - you can change direction whenever you feel the need
• Spend less time in setting up major frameworks and get something working as soon as possible. Then go back and refactor to accomplish your original needs (if they still apply)

Answer 4

Make list of tasks and features that you want in your application. Take those tasks and put them on a card wall.

You can't really have a meeting by yourself, but in the morning decide what you will do for the day and what you successfully did yesterday. Take those tasks, do them and then move to the next. Make sure at every point you are delivering continuously integrated, working software and you update your backlog. You might have "bug bash days" where you just fix bugs. That would be a one man scrum. :)

Answer 5

Is possible to use Scrum for one man projects.

• Create backlog
• Optimal time for one sprint is half day

At Friday create plan for next week and every half day update burndowns for each projects.

Answer 6

I think Agile is definitely not just for team projects. Agile advocates a set of values that apply equally well to many types of projects, even personal ones. I was in exactly your situation a while ago, trying to apply agile development to a personal university project, and learned a lot in the process. Some useful things that the agile mindset can give you include:

• Work on stuff that adds value to the final product. Make yourself a backlog of features and prioritize them as though you were the customer. Then discipline yourself to work on features based on their value to the product rather than what you want to do right now. This might save you from a lot of unnecessary, over-designed code that you won't use. If you have a deadline, it's even more important.

• Have an evolutionary design: start with The Simplest Thing That Could Possibly Work and Refactor Mercilessly.

• Postpone decisions until the Last Responsible Moment.

• Timebox yourself into sprints or iterations (VERY important on university projects).

• ...

If you go over some of the agile methodologies again, I think you'll find plenty of values and practices that you could apply by yourself.

While writing this answer, at least 3 other answers came up and beat me to it. I agree with all of them. :)

Answer 7

A few thoughts on this:

• Iterations are as long as you'd like them to be
• IPMs are still possible where you pick what you want to do over that length of time
• Demos at the end are still useful to see working functionality in a somewhat professional manner rather than your own little debugging area that may not be as clean or orderly
• Retrospectives are still useful to see what is and isn't working for yourself at a point where you can see the forest for the trees in a sense

It is quite possible to be Agile in a personal one-man project, IMO.

Answer 8

All of the advice here is good, but there is one important aspects of Agile that usually goes unmentioned: monitoring.

Agile asks you to take a look at what you have done, what you are doing, where you are going, and make appropriate course corrections if needed.

I think Big Visible charts and Burndown/Burnup charts are so useful, I wrote a program, Task Analytics, to make these charts easily. It's perfect for small or one man projects.

Good luck.

Answer 9

Other than pair developing, you can do the remainder of the practices if you are willing to play multiple roles. If you have someone who is willing to work with you, you can also do pair developing.

First you would build a product backlog. This would be a prioritized list of features or story cards you wish to develop. No card should be bigger than the work you can complete in a single iteration or sprint. If your sprints are a week or two, that will determine the size of the features or story cards on your prioritized product backlog. As the product owner, you can change the priority of the product backlog for each iteration. From the product backlog, you could build your iteration and release plans.

Since you are playing multiple roles, you will need to allow time for you to author the story card. The story card should sketch the GUI, describe the primary and secondary workflows and most importantly have acceptance criteria.

Once you sign off the written story card, you can begin development on the card. You would use TDD (test driven development) to write the test first, then the code. You would repeat until the card is done. The acceptance criteria would help you decide what unit tests to write.

Once the developed of the card is done, you would write the automated functional tests. You could use Quick Test Pro, FIT, Cucumber or some other favorite automated unit test tool. I would stay away from any play and record features as that can drive up rework in the future as you refactor.

Once the unit test is completed and the card passes, it can be added to all other automated functional test and can be run at least daily if not at every check in.

At the end of the iteration and prior to moving your working software to production, you can perform the User Acceptance Testing.

As the developer you should use continuous integration, automated builds kicked off with each of the frequent check in to your source code control system.

After the story card has been written and prior to developing the cards for the iteration, you can task them out (i.e,. provide estimates for each of the tasks required to develop the card). You can determine if any refactoring needed can be completed within your estimate or if you need to create a new story card that captures the technical debt you identified.

As you can see, you can take a single member agile team very far. Given that the agile management practices help collaboration and identify what is important, you can benefit from those practices also. Given that the engineering (XP) practices enable the code to remain healthy thus supports sustainable pace, you code will remain flexible, contain a strong unit and functional automated test harness and allow you to continue development at a sustainable pace indefinitely.