Recently I have had a lot of meetings and presentations with non-technical executive management where I describe the agile mindset. A core agile principle of this agile mindset is fast feedback.
In my presentations to technical people, I use technical examples to illustrate the two economic benefits of fast feedback: the ability to prune bad paths quickly, and the ability to exploit emergent opportunities faster. See Chapter 3 of Essential Scrum for a deeper discussion.
However, it has always felt wrong for me to use technical examples with business people. So, I decided when addressing business people to start using a non-technical example to illustrate the benefits of fast feedback.
Writing of the Essential Scrum Book
I am the author of Essential Scrum: A Practical Guide to the Most Popular Agile Process. I began writing the book in 2009 and it was published in August of 2012. When addressing business people, I now use my approach to writing this book as my example of fast feedback.
Below I describe this example, which illustrates the difference between slow and fast feedback. I start by showing what the slow, late-feedback approach to writing a book would be. Then, I compare that with a book-writing approach where the workflow is organized for fast feedback.
Slow, Late-Feedback Approach to Book Writing
The image below illustrates what a slow, late feedback approach to writing my book would have looked like. (I didn’t do it this way!)
This approach is similar to traditional sequential, phased-based development, where important feedback arrives very late.
For example, I could have written all of the chapters first and then sent the entire manuscript to all of the reviewers at once. But what if the feedback that came back from those reviewers indicated that they hated my content, tone, style, and/or delivery? What if many people commented: “Hey, your writing style is really formal. You should write in a style more similar to how you teach – using a more friendly and familiar tone!”
Yikes, it would be very expensive to learn this feedback after I had already written all of the chapters. I would have major editing to do on a lot of pages, or worse yet, an outright total rewrite. And, of course, I would then have to repeat the entire review cycle again, possibly revealing new problems with my adjusted style or tone.
Using this approach, I would have failed to get either of the benefits of fast feedback. I would not have pruned a bad path quickly. On the contrary, I would have kept running fast done the wrong path, writing chapters that were too formal, until I got to the end (a completed manuscript). Only then would I have learned I had been going down the wrong path.
Second, any important feedback that I could have gotten earlier, such as the importance of having graphics in the book, might not have been exploited. As a note, the Essential Scrum book has over 200 highly impactful graphics (which, by the way, are available for download as part of the Visual AGILExicon™).
What if I originally had felt that graphics weren’t an important part of the book yet, once the first draft of the full manuscript was finished, many reviewers made comments like: “It would be very helpful if you would illustrate this concept with a picture.” By the time that feedback would have arrived it would have been difficult for me to embrace the idea of making graphics a fundamental part of the book, since so much of the text would need to be adjusted to make reference to and explain the various graphics.
To summarize, this approach to writing a book would be an excellent example of how to avoid getting and acting on fast feedback. So, let’s turn our attention to a more agile-like way of writing a book—one that embraces fast feedback.
Fast-Feedback Approach To Book Writing
The image below illustrates the fast-feedback approach I actually used when writing my Essential Scrum book.
I am sure we can all appreciate that when I first started writing my book I really had the least possible knowledge of what the final book would look like. So rather than trying to “boil the ocean” up front and write the entire book when I had only unvalidated assumptions about content, tone, style, and delivery, I instead wrote a single chapter.
Prior to starting the project, I also hired a professional editor (Rebecca Traeger) to act as my personal editor for the book. She reviewed each chapter before it was released to a broader community for feedback.
Also prior to sending out any chapters I established the broader review community by soliciting people who were interested in reviewing the book chapters as they became available. From the people who expressed interest I selected and established a strong, complementary, and small-sized review community.
So, after I made edits to a chapter based on Rebecca’s feedback I would release the chapter for community review. The early feedback I received on the first chapter did change how I wrote future chapters. The example I showed earlier, “Hey, your writing style is really formal. You should write in a style more similar to how you teach – using a more friendly and familiar tone!” was actually some of the feedback that I received on the first chapter. Not only did I rewrite that first chapter, it fundamentally changed how I wrote the subsequent chapters.
By the time the “final” manuscript was completed, I had written and rewritten each of the chapters several times as I received feedback and as my understanding of how I wanted to communicate a topic improved. In addition, topics that I thought would originally be in the book ended up not being included, whereas topics that were not in the original table of contents I sent to the publisher did get included.
I credit the constant stream of fast-feedback for allowing me to write the book that the industry actually wanted (Essential Scrum has been an Amazon #1 Best Seller in Agile Project Management for the past 6 years), not the one I thought they wanted when I first started writing.
Summary
If you find yourself in a position of working with non-technical management on adopting an agile mindset, feel free to use this example as a way of illustrating not only the benefits of fast feedback, but also how iterative and incremental development enables fast feedback.