As enterprise Agile coaches in PM Power, we have seen many degrees of Agile adoption in customer organizations – from “doing Agile” going all the way up to “being Agile”. There are varying degrees of adoption even in software development – a domain in which Agile approaches have been around for over two decades. But how about degrees of Agile adoption in other domains – in writing a book for instance?
We have some experiences to share. First, a little bit of context…
One of our colleagues Ananth had developed a project health assessment framework called ProHealth – a very comprehensive one comprising six “Vital Signs”, thirty odd “Components” and 200+ “Manifestations”. It helped us to develop and deploy a service for customers to examine their projects and develop actions for improvement. Another colleague at PM Power, Paramu Kurumathur came up with the idea of writing a book about the thinking that had done into evolving the health framework. It was going to be a business novel set in Mahabharata times.
PM Power was also caught up in the idea as a means of promoting its branding and agreed to sponsor it and in the process naming me as the “Product Owner”.
Although terms like PO create a whiff of Agile, the question is how Agile such a project could really be given that it is primarily a creative effort. You may ask isn’t software development also not a creative endeavor and yet very amenable to Agile? My take is that in software development, there are two distinct aspects – the creative aspect and the implementation aspect, the implementation aspect being the more amenable part of Agile adoption. The creative aspect leads the implementation aspect but the two are woven together in sprints and releases. In writing a book, the two aspects are so close together that it is hard to separate. I believe this sets a bound of sorts for the degree of Agile adoption possible.
Here is a summary comparison between a typical Agile application and what we experienced in the book-writing project:
| Agile in software development | Agile in writing a book |
| The product being developed is driven by a business need, product vision and a product roadmap. | The vision was that the book would build the organization brand, perhaps not measurable as typical business goals. But, there was a clear product vision – the author (Paramu) conceived the product to be a business novel, set in an epic context rather than, say, a textbook. |
| A high-level product backlog is identified early and progressively refined to guide the development. | The product backlog was present at a high level – for example, chapters for explaining each Vital Sign, Component and Manifestation in the health framework. So, in essence, the high-level already existed in the form of the health framework. There was no need felt for this backlog to be progressively refined as an input for writing the chapters.
However, we did develop a backlog of characters and scenarios for the artist to develop the book illustrations; this backlog was refined in sessions between the artist, the author and the PO; this was a big help in conveying our “stories” to the artist not very familiar with the subject matter of the book. |
| The product is realized through a series of releases which are deployed. | We really targeted only one major and final release. There were other releases prior to that – one to be released for internal review and another for external reviewers and endorsers. But these were not really “shippable” releases. |
| Estimating and planning using epic and story points, planning poker etc. Multiple levels of planning: release level, sprint level and daily stand-up. | The estimate of effort and duration for the release was based largely on the judgement of the author who had written an earlier novel. There was only one level of planning. |
| Each release comprises fixed-length sprints producing potentially shippable product increments. | There was no concept of sprints. If anything, author’s effort was in bursts covering some aspects of the framework in each burst; these varying-length effort bursts could be considered sprint equivalents even though the output was shippable only to internal reviewers. |
| There are defined roles: Scrum Master, Product Owner and the team. | The roles were only loosely defined; there were only two primary members in the team: the author and the “product owner”; there were no formal Scrum ceremonies and guidance needed from an SM type of role; if there was any facilitation needed, it was done by the PO. The PO did not fully “own” the product but provided inputs as a reviewer when solicited and when PM Power’s (as the sponsor) interests had to be addressed. The other aspect of the PO role was as a facilitator, coordinating with external folks like the illustrator and the publisher and preventing undue distractions to the author. |
| Continuous integration (CI) and continuous delivery (CD) are hallmarks of good Agile adoption. | CI was practised as the book chapters were written; at any point, we had the integrated whole as of that date; however, we did require a “hardening sprint” for internal and external reviewers and another hardening sprint coming up with the illustrator and the publisher. |
| Agile artifacts: product backlog, sprint backlog and product increment. | We had only a high-level product backlog and product increments. |
| Agile ceremonies: Daily stand-up, Sprint planning, Reviews and Retrospectives. | We had no Stand-up’s and Sprint Planning but we frequently had “pair programming” with the author and the PO; this was very beneficial in quickly addressing issues – internal and those arising from external inputs from reviewers. |
| Tracking using burndown charts, task boards and tools. | The “tracking” was a function of the overall plan which was kind of high level; the tracking and reporting by the PO was largely an assessment of remaining work and forecasting book launch date. |
In summary, the most useful “Agile” aspects for us were:
- “Pair-programming” (author-PO) during development and “bug-fixing” cycles
- Continuous integration of chapters as and when they were completed
- Periodic reviews / demos for internal reviewers / sponsors
- Illustrations backlog for coordination between the author, the artist and the PO
As for the degree of Agile adoption in such projects, my take is that, at the end of the day, if the stakeholders are satisfied with the project schedule, cost and quality and if the book promoted our organization branding – the primary objective – that’s the bottom line.
In general, the degree of Agile adoption depends on fitment to your context and the choices & preferences of the project team. If the team makes those consciously, then there is nothing to regret or worry about what if’s! Hope this would be of help if you are getting into projects – software and otherwise – which inherently have a high degree of creative content/research orientation.
