Can Authors Use Agile Methods?

Posted by Mark Levison on Sep 11, 2008

Sections

Process & Practices

Topics

Collaboration ,

Teamwork ,

Agile

Share |

RELATED Research

Can Agile methods be used to write a book? For a growing number of authors (Lisa Crispin, Janet Gregory, Alistair Cockburn, James Shore, Shane Warden and Jurgen Appelo) the answer is resounding yes.

Lisa Crispin and Janet Gregory, authors of the forthcoming book Agile Testing, used a number of Agile Techniques. They started work on the book a year ago by mind mapping the contents of the book (a release plan). Working in two week iterations they mind mapped the contents of two chapters at the start of each iteration (iteration planning). At the end of each iteration they sent chapters out to the reviewers (iteration review with stakeholders/customers).

When asked about pairing and test first, Lisa said:

We paired to draw the mind map of the whole book, for example. We IM'd each other a bunch as we wrote, with questions and discussing feedback, but we didn't actually sit and write anything as a pair. Instead we used lots of really short iterations of passing each chapter back and forth, reviewing each others' changes and adding our own. This helped also with getting the book in one "voice".

...

We did do a kind of test first. At Agile 2007, we held a Conference Within a Conference session to find out what problems and issues testers and their teams face, especially in transitioning to agile development. We wanted the book to address all of these issues and questions that were raised.

On the question of Retrospectives, Janet said: "We did not hold formal retrospectives as there was only 2 of us, but we did look at the feedback and discuss what we should do. If we found something wasn't working, we discussed and changed it."

In his book Agile Software Development: The Cooperative Game (2nd Edition), Alistair Cockburn describes the efforts behind the first edition of that book:

• He choose people living in Salt Lake City to work on the book. Not co-location but everyone could meet physically as required.
• Incremental delivery - most editors like to work on paper and edit the manuscript in a single pass.
• Final layout was done with several people meeting at the page layout person's house. Working as a group they were able to rework awkward column breaks on the spot.

Incremental work had the additional benefit of reducing the amount of work for both Alistair and the copy editor: "I met with the copyeditor after she marked up each of the first several chapters, so we could synchronize the style and nature of the changes. As we formed agreement on what counted as a mistake versus what to leave as author's style, the number of marks she had to make got smaller, and the number of corrections I had to make to her corrections got smaller".

The overall gain for Alistair - reducing production time from four months to three weeks. However is often discovered in many agile transitions not everyone is comfortable with the changes.

RelatedVendorContent

The Agile Tester

Improving Software Delivery Cycles: Pre-requisites and Inhibitors

Adopting Git for the Enterprise: Risks and Considerations

Branching & Merging Efficiently: A Guide to Using Process-Based Promotional Patterns

Combining Inspections, Static Analysis, Testing to Achieve >95% Defect Removal Efficiency

Related Sponsor

In today’s hyper-competitive world, later may be too late to adopt Agile development and this Roadmap for Success will help you get started. Download "Agile Development: A Manager's Roadmap for Success" now!

1. Back to top

   Update from Lisa

   by Mark Levison

   One more thing I just remembered. At Tom Poppendieck's suggestion, we wrote the "back cover blurb" very on in our process. That helped us get a good sense of what we wanted the book to be, so that was definitely test-first!

   Reply

2. Back to top

   If we can do it for specs, they can do it for books...

   by Angelo Hulshout

   Nice little article, and a confirmation of what I've seen in practise. I've used an approach based on RaPID-7 on multiple occasions. Sometimes in groups of up to 10 stakeholders for requiremnts specifications, sometimes in teams of 2-3 to work out the details of an architectural design.
   If that works, of course the approach you describe works for books.

   Reply

3. Back to top

   Big Visible Charts in Authoring

   by Gerard Meszaros

   When I wrote my book xUnit Test Patterns - Refactoring Test Code, I used a number of agile techniques. I delivered continuously by publishing the draft material to my web site every couple of weeks. Early in the process the "stories" mapped to first (very rough) drafts of individual patterns, smells or narratives. Later, stories were to apply particular improvements to many chapters. To keep track of what I had left to do I created a Big Visible Chart in MS Excel that had the Chapters/Patterns/Smells as the rows and various generic tasks to be done each one as the columns. I coloured in the cells with yellow when I started them and green when I finished them. So the chart was both a Done-Done Checklist and my story/task board. This was especially useful during the endgame where there were a number of newly discovered tasks that I had to do to every chapter in the book. It helped me keep my sanity even though I was the sole author so it was only communicating current status to me! We are applying the same technique on the book I'm currently working on.
   
   Gerard Meszaros
   www.gerardmeszaros.com
   xunitpatterns.com

   Reply