How we manage our work
Posted on January 21st, 2012 in business, development | No Comments »
I have wanted to write a blog post about how we work on our client projects for a while now. I’m proud of our team and how we manage our work but I don’t want to stop there. Writing out our steps might help me to see any areas that could be improved. I’d also love to learn how other similar businesses manage their work too, so if you have any comments or suggestions, please get in touch. This blog post could also be a useful introduction to how we work to potential future clients.
Our team
We are currently a team of 3 talented software developers which include me (Gordon), Alex and Paco. Each of us works from home in different countries, luckily with very little time difference to contend with.
We build web applications using PHP and MySQL, often with a mix of other languages such Javascript and Python. Codeigniter is our PHP framework of choice.
The applications we create are often built from scratch for other businesses to resell to their clients. We’re very lucky to have happy customers in Ireland, England and the US. In the near future we’re going to add some blog posts highlighting some of the work we have done for customers.
The tools we use, Basecamp, Springloops and Dediserve.
http://basecamp.com, http://springloops.com and http://dediserve.com/
Basecamp is a project management tool and Springloops is an SVN code repository. I prefer Springloops version 1, not the newer version 2, there are too many things in v2 that I don’t need.
Basecamp and Springloops work very well together. Springloops can connect to the Basecamp API allowing to-do items assigned to you to show up in a ‘To Do’ tab in Springloops where client code is stored, specific to each user.
In Springloops each item is given a number and when some code is committed, one or more item numbers can be added to the commit comments which will cross off the appropriate items in Basecamp. (It would be cool if the commit comments would add comments to Basecamp but it doesn’t unfortunately.)
On top of this, we use the Basecamp comments and we email each other a heck of a lot. I try to keep the emails to during work hours so that we’re not all working all hours of the day but I don’t always succeed.
We are using Dediserve more and more over the past 6 months to host sites. Its a great service allowing us to create or modify the servers we need to suit the project.
All projects we develop have a Test site and a Live site. All code commits are automatically deployed to the Test site for testing online. Our clients can use the Test site any time they like, knowing its a sandbox and could be broken at any time or showing debug information.
We don’t phone, skype or IM each other much but those options are there if needed. Writing items down in Basecamp or emails allows us to keep track of everything and refer back to them.
I’d highly recommend the combination of Basecamp, Springloops and Dediserve to any developers creating software for their clients.
Customer communication
When meeting a customer face to face or else over the phone, I take as many notes as I can in my notebook. Right after the meeting I write them all in to Basecamp in a new list usually with a title along the lines of ‘meeting notes dd/mm/yy’. I type them up as quickly as I can after the meeting so that I hopefully don’t forget anything between my notes and what I remember myself. Sometimes I have meetings back to back which can be a bummer for remembering everything.
Once everything is added to Basecamp I use the ‘Print’ option in Basecamp to give a clean list of notes and I email this to the client and ask them if I have noted everything. I usually get it all right (or else it’s not read at all! )
Clients can access Basecamp too and add/edit to-do lists, most prefer phone or face to face meetings though.
From here we work away on the to-do items added to the list. Usually we would get in contact with the client when the items are all finished and we have deployed the changes Live.
Sometimes the list can be quite long and we should contact the owner more often to let them know how we’re getting on. There is room for improvement here on my part; I sometimes don’t get in touch with a client as often as I should.
In my mind I’d prefer to get in touch when I have everything completed and deployed or ready to deploy. This could leave the client wondering where we are though if it has been a while since last contact. The clients can always get in touch by email or phone but it can put things on a bad footing.
I should be contacting them first with a progress update. This happened at most when it was just me. With 3 of us on the team now there is room for me to communicate more, daily if possible but that’s not always practical, especially across several client projects. I’d spend all my day talking if I contacted people daily and I wouldn’t get any programming done. We’re hired to programme, first and foremost.
Deploying completed work
One process we have that I’m very happy with is what I call a ‘deploy list’. I’m not sure when this started but when a list of to-do items are coming to an end we create a deploy list for a certain date. In this list there are usually the same steps listed below. The intention is to put all recent changes Live to a client’s application in a responsible way. A handy feature of Basecamp is that it allows to you create a To Do list template, rather than typing out the same list every time.
A typical deployment list:
- Back up Live database (When this step is completed, a comment is added showing the backup file name or database location if backed up to another database. We have automatic backups too but this is a very up to date snapshot.
- Any specific SQL queries. (This could hold specific sql queries to change data in some tables, such as deleting a bunch or records)
- Sync Test database structure to Live database. (This allows me to synchronise items such as new tables, new fields and new field types from the test database to the live site. The data in the database isn’t copied.)
- Note current Live revision (This means to take note of the current revision in which is deployed to the Live site at the moment. If things go bad, I can revert to this revision very quickly thanks to Springloops.
- Deploy the Latest revision (This means to use Springloops to deploy any recent work to the live site. The new current revision number is noted in a comment)
- Any file or folder permissions (This usually means setting Write permissions to new images folder)
- Test live site (This would be a test of any of the items that have been added or changed. It usually goes hand in hand with the next item, I write the email to the owner as I test each item)
- Update the owner. (I usually email the owner with the subject ‘Application updated’ showing a list of all items recently fixed or added)
If after testing there are any bugs found, these are given a list of their own which needs to be worked on immediately because these bugs could be visible to the client or their customers. It’s possible at this stage to revert back to an earlier release and get back to the drawing board.
Thankfully any few bugs that do pop up are usually small and are related to Live customer data so reverting back wouldn’t allow us to see them easily in the Test environment again. If reverting back, we’d might copy all data from the Live site to the Test site to try to simulate the problem in the Text environment.
Once it’s all deployed and tested, I usually talk to the client about what they need next if needed.
Overall, I’m very happy with our current team. Our 3rd member is new to the team and we’re all working together very well so far.
I don’t know if these steps are comparable to Scrum or other work methods. Hopefully as I read more about them I might learn some new methods to add to our process. Right now though, I’m very happy with our team and our process. From some recent conversations, our clients are too!
