Scrum for One

I have, over the past few years (and few companies), found myself on a number of "teams" made up of just one member. For those having trouble with the math: yeah, it's just me. There are plenty of books out there that can help software folks manage their teams and their software development process. But I see very little written about the topic of managing the single-person team. So I'll get the party started by providing a handful of tips for developers working solo. I'm an Agile devotee with a preference for Scrum, so I'll illustrate my points using Scrum-specific terminology. But the lessons are the same no matter what your methodology. Adjust accordingly. 

Process Matters

Intra-team communication is an important facet of any software development methodology. On a solo team that communication with other team members is all in your head. But that's no reason to drop the methodologies altogether. In fact, following a strict (albeit modified) process can provide numerous benefits. 

Scrum, for example, creates a framework for setting expectations with your clients. They will know, based on your adoption of Scrum, that they can expect to meet with you before and after each sprint to plan and review your progress. They will know when and where their input is expected. And they will know what sort of reporting to expect.

Scrum also helps you organize the requirements for your project into a manageable task list. It helps you and your clients prioritize your tasks. And it helps you keep track of what you need to do, and when you need to have it done by. These things are all very easy to lose track of when you are working alone.

The daily scrum meeting, though intended to be a discussion amongst team members, remains important on the solo project. Go over the three points you would on a larger team. Put them on a white board or in a notebook. What have you done since yesterday? What will you do today? What is getting in the way of your progress? Now you've got a framework for your day's work.

The Testing Challenge

The biggest challenge for a solo developer is testing your software adequately. The fact is, you can't do it alone. You need outside help. If you're in a solo situation, the decision has already been made: you're the tester. Your software will suffer because of it. So you have to come up with a mitigation strategy. My advice: strengthen your unit testing, and recruit your client's resources for user acceptance testing.

Your unit testing should follow a test-driven-development plan. Write your tests before you write any code. Do not write any code that is not specifically designed to pass your tests. Automate your tests to run with every compilation. Your code should emerge fully tested by the time your development is completed.

User acceptance testing should, in an ideal situation, be the last step in your development process. But without actual testers on the team, you have to get your users involved earlier. Show them your progress during development, so they can provide feedback early. Then recruit anyone who is providing input to the project (graphic designers, writers, etc.) to test your implementation of their input. Recruit random non-experts from your client's organization to try out your software from a a non-technical perspective. Help them help you: provide a test plan that explains what they should cover in their testing, and how they should go about it.

Reporting & Visibility

Scrum proscribes a specific set of reports that you should be providing to your clients: the sprint burndown and product burndown reports. Use these to their fullest extent: publish the reports somewhere where your clients can view them on a daily basis to get updates on your progress. Teach your clients the meaning of the line on the graph: as you make progress, the line slopes down toward the bottom of the graph. I've found that using Microsoft's TFS with the Scrum module installed automates the updates on that report, and provides a trend line that gives my clients an idea of whether or not I'm on target for delivery.

Keep your product and sprint backlogs up-to-date, so they are always useful to your clients. Again, publish them where your clients can get to the latest version. Your clients will appreciate the visibility into your project, and can use the information in those documents for reporting to others within their organization.

Presentation & Planning

Be diligent about your sprint review and sprint planning meetings. Set expectations with your clients about what will happen in each of these meetings. Make sure that your clients understand their roles, and who should be attending these meetings.

Put together a clear presentation for your sprint review. Highlight what you have accomplished. Provide a visual representation of all of your work, even work that has no user interface component. Use Visio to make a diagram if you have to. Give your clients something to see, rather than just something to read about.

Srum On!

Use Scrum (or whatever development methodology you have chosen) to its fullest. Don't be discouraged by the parts of your methodology that don't translate to the single-person team. Most of the components of any good methodology will be just as valid for you working alone as they are for a larger team.

Ss.