Agile Processes for the Solo Developer
Is it possible to take advantage of Agile Processes such as Scrum or Kanban as a solo developer? That became my focus recently as I was working on the specifications for a website re-write. Instead of creating detailed specifications, I started writing a collection of User Stories to define the functionality. I already knew the basics of what the website should look like since it already exists. The new version would add some additional functionality such as allowing for on-line payments and user notifications by email under certain conditions.
The more I learned about Agile Processes, the more I envisioned how I could apply them to my own way of working. As anyone who has read my other posts knows, I’ve been on the search for some time for a project management method that works for the solo developer. After all this research, I’m thinking that utilizing Scrum and/or Kanban can accommodate the majority of my development and maintenance project management needs.
The reason I’m looking at using both Scrum and Kanban is for their differences. Scrum is an iteration-based, incremental framework more for long-term ongoing development whereas Kanban is a simpler methodology with an emphasis on just-in-time delivery. Kanban lends itself, at least in my world of development, to some ongoing development or maintenance projects as well as some small new development projects, none of which generally take more than few weeks to complete. Scrum can also be used for maintenance development, but is more oriented to long-term repetitive-release type of projects.
Let’s explore two of my recent projects, one using Scrum and one Kanban to better illustrate the differences.
The Kanban Project
For Kanban, I have a web translation project, let’s call it Japanese Web Site for reference. This project involves taking an existing site of four web pages/PHP scripts used for data gathering and converting them to a new layout and also translating them to Japanese. The translation content is being provided by the client as is the design of the new version. Initially, I created the following collection of user stories:
- As the Client, I want to see the Web Site in my native language (Japanese) so my visitors are better able to use it.
- As the Client, I want to see the Web Site in the same format as my corporate site so my visitors think it’s part of my company.
- As the User, I want to see my data entry validation on the same page as the form so I don’t have to go back a page to make corrections.
That’s it, not a whole lot to it, is there? From a Scrum standpoint, it would be pretty difficult to force iterations on this kind of development. That’s why Kanban fits better. Initially, only one story made it to Work-In-Progress, the translation from English to Japanese. I took the existing pages, replaced the English text with Japanese and generated a new user story because I also had some error messages that needed to be translated. I continued this process over a period of two days until, moving one story at a time from the BackLog to Work-In-Progress to Completed. This generated a few more translations as I added error messages or changed old messages.
For each User Story, I created tasks for the individual pages that needed to be modified. In the case of the data entry validation story, it required modifications to only one page which was reflected in the tasks for that story. The translating to Japanese story and the matching layout story resulted in tasks for all four pages.
At the end of my two days of development, I ended up with two new stories:
- As a user, I want to see all messages display in my native language (Japanese) so I can better understand what I need to correct.
- As a user, if I choose to go back from Page 3, I want all of my data entry to be retained so I don’t have to enter it again.
The first story has only two tasks: 1) Email Client list of error messages to be translated and 2) Replace all error messages with Japanese language versions. The second story also had two tasks: 1) Add Form and hidden fields to Page 3 “Back” button to save data values and 2) Add PHP code to display saved values if returning from Page 3.
The second story was then processed through Kanban, leaving me waiting for the translations before I could finish work on the site and allow the customer to begin testing. Again, I really don’t see how I could have done this using Scrum without incurring a lot more work from a project management standpoint.
My Kanban process is a bit simpler than the standard, I skipped having an Analysis phase, everything went from Backlog (or Next depending on your terminolgy) straight to Development-WIP, then Development-Done upon completion. I didn’t bother running each individual story through Acceptance, but instead generated new Stories to document any defects discovered by the client.
The Scrum Project
My other project is ongoing maintenance of a fairly complicated desktop application developed in Clarion. This application has been in production for a number of years and is continuously undergoing updates as regulations change and new requirements/features are dreamed up by the users. Of course, there is also the occasional bug discovered that has gone unnoticed all this time, or that no one has bothered informing me it existed in the first place.
This project is a better fit for managing using a Scrum Process. First off, all requests from users are translated into User Story type format, such as:
- As a User, the new import format from a provider needs to be supported so I don’t have to manually enter their data after 10/1/2011.
- As a Manager, I need to be able to see a log of successful and failed emails sent from within the system so I can research customer complaints that they were never notified.
- As a Customer, I need to see your company contact information on all reports so I don’t have to look up your phone number.
- As a User, I need to be able to extend a selection of Employees in order to meet regulatory requirements.
- etc.
As you can see from the above list, this type of development management can easily fit within an iteration methodology. I decided to set a goal of publishing a release every two weeks consisting of two one-week Sprints. Each release would consist of those user stories deemed most important by my client I feel I can accomplish in one week of development with one or two minor bug fixes thrown in just in case I have the time. The first Sprint would be to complete as many of the stories as possible, then using the second Sprint to finish anything left over along with any bugs that may have cropped up in testing.
For the first Sprint using Scrum, I selected the first three stories from the Backlog, assigned them to the next Release and moved them to the first Sprint. I then created the development tasks I would need to complete to meet the requirements of each story. After completing these tasks and testing the results of the Sprint in-house, I then moved on to the second Sprint which consisted of correcting a few bugs from the first Sprint and finishing development work on the third user story of adding address/phone number information missing from some user reports. I was able to complete this Sprint, including testing and debugging, in four days instead of five and sent out the release one day ahead of schedule.
Instead of moving directly into another Release Iteration, I held off one week to make sure there were no missed defects in the changes and to continue collecting user stories for some old back-burner requests. Towards the end of the week, I held a development meeting with my client to review the backlog, including a few newly discovered defects and determine what would be most important to have completed for the next release with the understanding that all work would need to be accomplished in only a two week time frame. The reason I held off was to give the users plenty of time to make sure everything was working as intended and allow me the flexibility to execute a short-term iteration in case something needed to be fixed quickly.
Conclusion
So far, I’m finding that dividing my development projects into one of two processes (Kanban or Scrum) is actually making it easier for me to management development requirements. For short-term or simple projects that don’t make sense forcing into iterations, Kanban works perfectly. For the bigger ones that involve much more interaction with the client and would benefit from frequent releases over a long period of time, Scrum fills the need nicely.
Of course, this required the search for a software solution that would allow me to manage both types of projects easily. What I found and how I’m implementing it will have to wait for the next post.