As you may already know Scrum is a methodology for iterative and incremental software development that can improve both your product development cycle and its results. I first heard about it about one year ago, in Jessica Kahn's talk for the spring 2009 edition of the well deservedly famous iPhone Application Programming course that Stanford publishes in iTunesU, and since then I have applied it to all my software projects with very satisfying results. However, I had to do several adaptations because Scrum is really meant for a group of people and I develop software by myself.
Please be my guest and get to know how I apply Scrum for one.
What you need to know about Scrum
The main idea behind Scrum, the one that pushed me to adopt it, is that, instead of developing all the features of your product at once, so it becomes the Perfect Thing™ that you have in mind, you go through development sprints and at the end of each one you have ready-to-use product, that you could (more or less) ship.
The sprints can range from one week long, because less is meaningless for iteration, to a month, because more pushes you into too complicated features that render your product into an un-compilable state forever.
The features that you implement in each sprint come from a list, called backlog, that is the result of the design phase plus the constant input from the stake holders, as represented by the Product Owner and agreed with the Scrum Master (i.e. project manager).
Each spring is preceded by a meeting that is used for deciding the goals for the next sprint and followed by another one to review the accomplishments and the lessons learned. Also, in order to gather everybody's status the team holds the daily scrum meeting that shouldn't last more than 15 min.
The adaptation for one
As an indy you might be tempted to avoid implementing some of the features of the methodology. Rightly so. The most obvious one would be the meetings, but I don't recommend you to do so. Don't get me wrong. I am not suggesting that you present your slides with the desired functions of the product to yourself. However, if you are a GTD practitioner, the sprint review fits nicely in the weekly review, especially if you do sprint cycles that last a whole number of weeks. Also it is very helpful to dedicate 5 minutes a day, when you start your product development tasks, to refresh your current status. And finally you have the Scrum planning meeting.
After having done your initial design, that you have reflected into a mind-map. You dump all this features into a backlog. While as a GTD defender I reject to prioritize my actions with the ABC system because of its dynamic nature, I believe that it makes a lot of sense for features. You can classify your features in Must have, Desired features and Nice to have. So after the sprint review that happens during the weekly review, you should dedicate some time to plan what you will do in your next sprint cycle. That is the sprint kick off.
By now, you are probably thinking that this is a lot of management and not too much programming progress. So let me also talk a little bit about how I work on the features (and bug fixing) that are included in the sprint. I usually do one week sprints and manage all these changes using Git. I use a branch that is called NextVersion that holds all the changes that I plan to include in the next version of the product. From this branch I create a branch for each sprint. And from the sprint branch, I create a branch for each of the features. Once a feature is implemented and tested, I merge it to the sprint branch. And if the sprint is considered successful and I like what I have implemented, I merge the sprint branch into the NextVersion.
You might think "So what? I already try to do that." But as put by Diego Piacentini (Amazon) in the November 3rd talk for Stanford's ETL these are good intentions and what you really need is a process. Hope this process matches your needs. It works for me, indeed.
As always your comments are more than welcome. Let me know if you like this kind of content and share your experiences if you like.