One Man SCRUM

My first job as a freshly minted computer engineer was working as a real-time embedded developer with a defense contractor. When I was there everything lived and died by The Master Schedule - put together by some poor systems engineer who worked on it for hours. The venerable schedule was so detailed I wonder what percentage of time was used to simply develop the thing compared to the time to actually implement the project.



But the schedule very much dictated a rigid waterfall approach to development. On one of my solo projects I proposed to the program manager that I would be implementing the software using an iterative approach called SCRUM. He looked at me as if I suddenly decided to start speaking Japanese.




Suffice to say there really wasn't any drive to go beyond a waterfall approach. But I knew there were other ways to develop software and I wanted to try them.



My second, and current, job threw me into the world of enterprise-level software development. Managing and integrating enormous amounts of data. It was an entirely different universe from programming registers and writing hardware drivers. But it was also a SCRUM world. And I thrived.



Since I moonlight as an indie iOS developer, my team consists of me and sometimes a particularly delicious IPA (always a valuable member of the team). So I'm trying to scale down the SCRUM process to see how it works with a single developer who also happens to be the tester and the customer.



It has worked OK so far, but there certainly is room to optimize. To begin with, this is only my second backlog that I have created; only the first with epics. I think I'm doing it right only because it looks similar to the backlog that I interact with at work. Writing stories I'm pretty confident with since I do that fairly regularly at my day job.



My sprints are all over the place. Looking at my Git check-in history I can have a period of rapid-fire development and also long periods where I do absolutely nothing. So my sprints have ranged anywhere from 1 to 3 months (the longest). This I need to improve.



But with a kid to raise and a household to attempt to help manage, sometimes I just want to lay on my couch and watch terrible Bigfoot-hunting shows instead of working on code. I'm not going to beat myself up too much over my irregular sprint iterations.



Not only have I attempted to implement SCRUM, but I also decided to be extra rigorous and use test-driven development. Talk about discipline.



At first the unit tests were taking up nearly all of my development time. I had never done unit testing from within Xcode so I had to learn the framework. Secondly, I was unit testing Core Data based code, which required much more overhead on its own.



So I really had to grit my teeth in order to stay committed to the cause. But a few months down the line I realized that if I was going to get this app published within the next five years, I was going to have to be less rigorous with the TDD. I still run my unit tests and they cover nearly all of my Core Data functionality. And, yes, they do give me an awesome warm and fuzzy; but I only have a finite amount of precious time available to me and I have to decide how I am going to use it best.



Sprint 6 begins tonight.
Full Post