I will be doing a part time University project soon and the time frame for it is around 8 months with approximately 10-15 hours a week spent working on it, with a review by a tutor each quarter.

My question is what software development process would you recommend using when the course requires you to work on your own in order to manage yourself as well as the project?

I wanted to use a weekly or bi-weekly iterative approach to my work but a lot of the processes seem tailored to teams of people.

I am looking at XP (Extreme Programming) OR Scrum as something that is less than the norm for University work but again Scrum I don't know a lot about yet, and a question I have is; can you say you are doing XP without pair-programming? because my tutor seems to think that I have to stick to all the practices otherwise I can't do it (nevermind if I am working alone).

We can have external user input as well but due to the small timescales with part time work it may be more beneficial for myself to be the user as well, which is not what I prefer considering how I can get lost in the design.


3 Answers 3


The first principle of the Agile Manifesto is to have a preference for team colaboration over processes. What this means for you is don't get caught up with XP or Scrum or some other named process, but do something for your specific needs. Some approaches that can really help:

  • User stories to track requirements/features and estimation (story points). It provides enough structure to figure out the high level design without getting too bogged down in the details.
  • BDD or TDD, all the more important because you are working by yourself. Without a dedicated testor, you have two hats to wear. If you code your tests, they will help you discover when you accidentally break something.
  • Version control. Use it, it will save your hide--even if you are only one person. Better yet, use an externally hosted solution that has regular backups. There's several options like GitHub or some equivalent that allow you to have private repositories. Nothing worse than the sinking feeling before d-day (delivery day) and you just realized you went down a rabit hole that had a bottomless pit. The repository will let you go back to a sane version and choose a different route.
  • Short iterations. No more often than one a week, but no less often than once every two weeks. You need constant feedback, and the weekly iteration can work really well. At every iteration you should have something that works, albeit with more features. If you iterate too often you will be spinning your wheels and not getting enough done. If you don't iterate often enough it will be too long without feedback (i.e. your testing cycle) and the problems become more troublesome to fix.
  • This is very much the approach I want to take, I think my problem is more to do with Academia and I am in a situation where I need to find a way to take my own approach, pulling from the good bits I need, rather than a "software development process", to do that I probably have to comment on the processes I did not pick and explain the benefits of doing it my own way, while drawing on my previous studies.. and then pray they give me marks for it.
    – Pricey
    Commented Jan 18, 2011 at 14:28
  • The industry term for the process is called process "tailoring". Basically, it starts from a known software process, and describes the differences to suit your project. So if you have a tailoring document referring to a known standard process, you can get that approved by you instructor. Commented Jan 18, 2011 at 14:52
  • Just do a Google search on "Process Tailoring" and you'll see a lot of links. I got the term from the CMMI process framework (typically associated with heavier processes), although it is not unique to that. Most of the training I've had was on the job, so no links for that part. Commented Jan 19, 2011 at 11:14

There's nothing to stop you using an agile process with only one developer, though some like XP require pair programming so you'd have to use a different methodology.

It has been argued that XP is a particularly fragile form of Agile development. In XP Refactored the authors point out that if you don't adopt just one of the features of XP the whole thing can fail quite badly.

You can't do daily standups - unless your tutor/supervisor is available at the same time every day. So you will have to pick and choose the features you use.

The short iteration cycles will help and you can use your weekly(?) tutorials to discuss the progress made in the last week and what you hope to achieve in the next week.


For my personal projects I use Personal Kanban for overall process visualization.

...Unlike other personal productivity tools, Personal Kanban is a pattern – it is not an edict. You can mold it into whatever shape or form works best for you at the time. Personal Kanban is also scalable – it can work with just you, or with your family, or even with work groups.

There are only two real rules with Personal Kanban:

  1. Visualize your work
  2. Limit your work-in-progress

It’s just that simple. After you’ve used this “introductory’ kanban for a little while, your understanding of the nature of your work will evolve. As it does, your kanban will likewise evolve...


  • ok thanks for this i'll check it out, I take it this is similar to www.agilezen.com ? I can see this process as a good way to manage my work load but is it more of a project management process than a software development process? considering my course is asking specifically for that, which I think they need to ask for both considering I am managing myself and they want me to reflect on how that went too.
    – Pricey
    Commented Jan 19, 2011 at 9:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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