At a Glance
This past week I got nothing done. I had lots of “reasons” (read excuses) but in the end it comes down to the fact I didn’t set myself up for success this week. My wife and I work best when we have a set of goals to achieve and a plan to get them done. Yea, we didn’t do that this week. Hell, I almost talked myself out of writing this blog because “I did nothing so I have nothing to say.” Instead I gave it some thought and realized I can describe what we do to track and manage our work. So without any fanfare at all here we go.
We Need Guidelines, Not Rules
Over the last almost 30 years I have used a ton of different approaches to my software projects. I used Waterfall, Agile, Scrum, Rapid Application Development (RAD), Prototyping, and the wild-wild-west style (shoot from the hip and keep on going). I have always favored an Agile approach as I found it affords the most flexibility and adaptability, assuming that the organization actually implements Agile correctly (which is ohhh so rare!). Whenever I get a choice in the matter I pick a customized version of Scrum. I find Scrum mostly fit my needs, however, like Capt Barbossa said, the Scrum “code is more what you’d call ‘guidelines’ than actual rules.”
My customizations allow for more flexibility that Scrum natively allows. In my opinion Scrum flips the first Agile Value and favors the process over the individuals and interactions. Here are the four values that make up Agile.
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
Many people misinterpret the values to mean “don’t have a process” or “don’t do documentation” or whatever else (yeehaw – wild west here we come!). I view those values as a sliding scale weighted towards the left. I need processes and tools to create software, however, I need to value my colleagues over following the process. I need to document my design, especially in a team environment, however, if the game doesn’t run and I have perfect documentation then I haven’t done my job. All those items are important, however, which are more the most impactful to software development.
Drawing upon my 15 years of Agile experience I created a “cherry-picked” version of Scrum that my wife and I use for our business. My wife does graphic design and illustration work, some of which support game dev. We needed our process flexible enough to accommodate her artistic needs as well as my game dev needs. In January, we crafted our process and have improved it every (well almost) week since.
We Be Agile Now
We don’t have a Product Owner or do daily scrums as it’s just the two of us for now. Over the years we experimented with different sprint lengths and settled on a week, running from Sunday to Saturday. During longer sprints we would drift off target and rationalize it as “well I have next week, so…”. In early January we picked a week and we love it, well as long as we actually plan our work. 🙂
We needed a healthy backlog of tasks to make this work, and I knew the perfect tool to use, Trello. I love Trello and have converted many of my friends to use it (side note: if you want to know more about Trello just ask!). We already had a team setup so I created two new boards, Backlog and Work Cycle, to manage our process. The Backlog board uses a column for each project we’re working, and the Work Cycle board uses the columns Ready, In Progress, Blocked, and Woot! to manage our sprint.
Every Wednesday night we have a “grooming meeting” where we spend about two hours creating tasks and refining the overall backlog. A healthy backlog has three to seven sprints worth of work stored in it. It took us about a month to get to that point.
We work best when we have a set of goals or a plan, and this is where we faltered last week, we never did our planning meeting. However, most weeks we sit down on Sunday and spend two hours planning out our week. I created a Daily Planner sheet that allowed us to track our projected hours for work and still account for our normal lives.
Finally, at the end of every week we set aside 30 minutes to do our retrospective, a discussion of all that went well, what could be better, and then decide on what we want to improve about our process. Honestly, for the first two months we didn’t do this meeting, it was only the two of us and we updated our processes in the moment as opposed to waiting till the end of the week. We still set aside time for the meeting but the focus of the meeting may change in the future.
And that is what we do, at least at a high-level.
Keep on Questing!
We’ve tried a variety of different management approaches over the years and this works the best for us, well at least when we do our planning meeting. What process do you use to manage your game dev process?
I plan to accomplish the work I should have done last week, namely flesh out my game design document, and better define my coding tasks. Join me next week to find out how I did.