Lancer Kind

I’m a science fiction author and an Agile software development coach (a fancy computer consultant).  Recently, I’ve combined these worlds together with my book project, Agile Noir, a book that entertains and teaches about Agile software development.  I’m using an Agile process, Scrum, to write my Agile book.

Scrum’s predictive planning, and inspect and adapt process improvements can be applied to the production of pretty much anything.  I’ve used it to plan a party, develop a wind farm, create software applications, and now, to writing Agile Noir.  Here is how I applied Scurm to writing and how it allowed me to understand when I was going to finish my novel and how to set realistic goals.

Sprinting

We want to be able to measure our productivity, otherwise we won’t know if we are improving or getting worse.  Scrum standardizes its measurments (also referred to as metrics) around a unit of time during which we’re dedicating our efforts to producing a piece of product that is of the same high quality as the finished product we would give to a customer.  (A fancy way of saying the quality is high and no corners are cut.  Unfortunately in software, it’s common to cut corners until close to the ship date.)  A Sprint is fixed, meaning the same amount of time is always used for the duration of the product, like three hours, three days, a week, two weeks, a month, etc.  You can later adjust the size, but in order to produce usable productivity measurements (metrics) then you need to settle on one size ASAP.

When you start your Scrum project, your first couple Sprints are the least accurate, but you do you best, relying on experience, to get started so you can collect some metrics.

Pick a Sprint size (in my case, I started with one week sprints, and then later, when I was studying part-time, two weeks), create a rough Product Backlog, give each item a number representing the complexity and amount of time to do (called “the size” in Agile circles), and then select a subset of items from the Product Backlog that will become your backlog for Sprint one.  The sum of “the size” of the times is your best guess at what your think your Velocity is (how much work you can do each sprint).  And as with all Agile processes, you put up big visible project artifacts in your office.  During these first Sprints, we will get data on what our actual velocity and use that data to predict when the project will finish.

At the beginning of each Sprint, there is a planning meeting where I plan what I think I can achieve each Sprint.  Then the sprints starts and during that time I track my progress with the Sprint Burndown Chart,

and update the backlog items with status (those rust colored stickies are the items–the ones with a smiley face are done).  During each Sprint, you’ll develop a deeper understanding of what “Done” means.  For my writing project, I learned some things that should be done before considering any backlog item Done, or things that had to be completed before releasing a chapter to my external readers could be considered complete.  Having strict criteria for “Done” allowed me to have a consistent quality of work at the end of each Sprint.  And if I’ve done me job right, consistently high quality.

For example, my Revision List which I mention in my Definition of Done for a Release, which is specific for my writing project, was inspired by what Ken Rand describes in his book, The 10% Solution.  It’s a list I use to scour my manuscript for “problem words” and check that they are handled correctly.

You’ll also develop a Working Agreement, which is a list of things that you standardize around about how you operate.  You’ll know very little or none of these on Sprint One but you’ll develop these as you go.

At the end of each Sprint, I meet (with the PO, the Team, and the SM, all played by myself) and have a Sprint Review in which I review what work has been completed.  (For example, a revision task isn’t completed unless it meets the Definition of Done for a Revision–See Definitions of Done photo.)  For each backlog item that I’m done, I accumulate the points in the lower right hand of each item.  The sum of those points is my Velocity and that number is used to guide me to how much work I can complete in the next sprint, and to quantitatively measure the effects of process improvements.

Also at the end of each Sprint, a Retrospective is held, where the team (me) discusses the problems which occurred and how to solve them so the next Sprint goes better.

Then back to step one: Sprint Planning.  Do it again, start your Sprint again.  Each Sprint, try very hard to complete all the work you’ve put on the Sprint Backlog (stretch goals are a waste, they’ll wear you out, your wife will complain that she hasn’t seen you, and they aren’t a sustainable way to operate), and each Sprint you find ways to do your work better.  As you discover more work, add new items into the Product Backlog but don’t disturb your Sprint Backlog (that is verboten!) as that will also add turmoil to your Sprint metrics and everything takes a step closer to chaos.

Later, I’ll describe how I can predict the finish date of Agile Noir with the Velocity metric that I collect each Sprint.