I’ve touched upon some of the difficulties in expanding Scrum to very large projects. I don’t believe that the Scrum of Scrums approach really works. It helps solve the management problem but the system engineering problem is left untouched. Not good.
That issue aside, I’ve been thinking about the opposite problem. Can a lone software developer use Scrum? Assume there is no Scrum Master. A Product Owner (or at least a small group of people that ultimately own the software) exists. There is no dedicated QA support but the end users are glad to test the code and provide feedback.
Does Scrum add value or does it just add overhead?
Product Backlog
Any software project (except for extremely small initiatives) will have a list of features and functions to be implemented. That list may consist of ten or so epics or it may be much, much longer. Regardless, the list should be described, sized and prioritized. Having a prioritized to-do list is simply good practice in any non-trivial endeavor.
Sprint Backlog
For a single developer, sprint duration and keeping sprints to a fixed length are of less importance than for a larger team. A lone developer is likely to be interrupted often and is also likely to have production support issues to handle making sprint timing erratic.
What’s most important is to discuss the contents of the Product Backlog with the business folks. Jointly select the epics to be implemented in the next sprint. If an epic is very large (e.g. requires several calendar weeks to implement), it is wise to split it into two or more epics.
The chosen epic(s) must be split into stories that are estimated in greater detail and reviewed with the business. I strongly recommend being able to demonstrate weekly progress to the business users. This aspect of the development will be simpler than trying to do weekly demonstrations when the team is larger.
Daily Stand-Up
Okay, meeting in the team room in front of the Scrum board each day when you are a lone developer is a bit silly. However, you need some way of tracking progress and a Scrum board (or Scrum spreadsheet) may work for you. It’s also a good idea to go through the 3 famous Scrum questions. They will help organize your thoughts and plan your day (interruptions aside). If you see an impediment, escalate the issue to management or the business immediately.
Automated Builds and Testing
Anything you can do to automate repetitive tasks will only help you get more done and deliver better results. Whether or not to automate builds and regression tests is a judgement call. You are likely to find that some aspects of the development process benefit greatly from automation while other parts can just as easily be done manually.
Definition of Done
A checklist showing all the major steps that have to be completed before the software can be turned over to the users is always a good idea. It doesn’t have to be as rigorous as a formal definition of done but it will help organize your thoughts and workload.
Burndown Chart
A burndown chart is probably not needed by a lone developer. It may be interesting to look at but adds little value.
Is it really Scrum or is it another Scrum wannabe?
Honestly, it’s not Scrum simply because it does not meet a few of the essential characteristics — there is no Scrum Master and there is no Team. Regardless, following a structured approach to software development will improve your workflow and your deliverables no matter what you call it.
The discipline you instill in yourself will help your career as you advance to larger and more complex projects. What do you think?