Every project has its challenges. Sometimes the challenges are technical, such as unfamiliar or immature technologies, and sometimes the challenges come from the business, such as people, schedule, or money. Over the past year or so, I’ve finished a couple of projects where the challenges were small size, short timelimes, and limited budgets. I’d like to share some of the lessons learned from that work. These lessons come from projects with initial development phases in the range of 3 – 6 person-weeks.
h2. Lesson One: Agile still works
The basic agile principles of frequent feedback from short iterations, good estimation and tracking, and strong automation all still work. It may not always be obvious exactly how to apply agile practices, but it is worth figuring it out.
Some technical practices may not be good fits: pair programming is obviously not an option if there is only one programmer. However, it is still important not to abandon the others. You can still ensure quality through other agile practices including effective automation and solid testing practices.
On the management side it may not seem like there is enough scope to warrant practices like a backlog and project backbone. These are still valuable, as you still want to have a good idea how close you are to being done and whether you will be on time or late.
Decompose your stories into smaller tasks so that you don’t have just a couple of items in your backlog. Break down each task into many very small tasks. Remember that a four person-day task is a less than 20% of your iteration on a five person team, but on a small project that might be your entire iteration. You’ll find your burndowns are more meaningful if you have a more consistent velocity, rather than two or three iterations with zero points followed by one with fifteen.
h2. Lesson Two: Keep in touch
An accessible and engaged customer is always important, but that is particularly true on smaller projects. When your deliverable has a limited featureset, you might not have any other tasks to do while you wait for information, paperwork, servers, or anything else from your customer. Projects this size are rarely large or complex enough to support multiple threads of development. You need to keep an eye on the next few tasks in the queue to make sure your dependencies are going to be ready, and your customer needs to be available for feedback and assistance. Without that, you can easily be left dead in the water, burning money and time with no work to do.
Ensure a minimum amount of communication with your customer with regular and short iterations. Avoid two week or month-long iterations. Prefer to iterate weekly or more often. It is foolish to spend half your budget without hearing customer feedback. Track your budget burn daily and always be ready to have a discussion about scope. Effective, disciplined tracking is even more valuable on smaller projects because you do not have the breathing room in the budget or schedule to absorb any slippage.
h2. Lesson Three: Plan for UX & design – and more of it than you might expect
Customers on these small projects (and large projects too, sadly) will often deprioritize research, design, and planning tasks. This is a always a bad idea, regardless of project scope, but it’s particularly dangerous on smaller projects because you don’t have the budget to build an unnecessary or poorly thought out feature even once, so a short and focused discovery session can be a big risk reduction. Additionally, polished workflows and aesthetics have an enormous impact on user satisfaction, even if some of it may be unconscious.
There is a caveat here: discovery and design cannot be scaled down below a certain minimum effort. Plan to spend anywhere from two to four person-days on discovery, wireframes, and actually cutting HTML and CSS (or whatever the brick and mortar of your platform may be). While a few days or weeks of design time on a large project might work out to just a few hours per page, a small project will still need all the foundational work (such as building the basic page template and styles) and that setup time can’t effectively be reduced.
If you acknowledge this impact then you can plan for it. Reserve a part of your budget for planning. Meet with a very small number of real users (you can’t serve more than one persona in a project this size – so don’t burn budget trying). Don’t try to research any workflows outside of your initial mandate – discover the core problem and go deep, not wide. Focus on understanding the problem, solving it with paper prototypes and low-fi wireframes, and then move on. You can come back for another round of research after you wow your customer with your first release.
h2. Lesson Four: If you’re part time, allocate that time strictly – and stick to it
Sometimes you’re stuck working part time on a project. Perhaps you’re allocated as little as two to three days a week. Maintaining the discipline to keep things moving in this situation can be difficult. There’s a very natural tendency to jump from one project to another as soon as you hear exciting news (perhaps the purchase of that server you’ve been waiting for went through) or as soon as you get blocked (such as needing data from Jim in HR).
I find it best in these circumstances to commit to working specific days (e.g. Monday and Tuesday) on a particular project. This way, if you get blocked, you are forced to work to get unblocked rather than just moving onto a project with more momentum. This prevents having a perpetually blocked project.
h2. Take care
Any time you’re under pressure and on your own on a project it can be very tempting to sit down immediately and cowboy up some code to show off. It’s always worth resisting this temptation and taking the time to do things right. Don’t forget how you ran that big project last year – take those lessons and apply them here, even if at first glance it seems excessive. It’s always worth doing it right.