How We Work

How I Used Agile to Create a Better Book

But I should caution that if you seek to plot out all your moves before you make them—if you put your faith in slow, deliberative planning in the hopes it will spare you failure down the line—well, you’re deluding yourself. For one thing, it’s easier to plan derivative work—things that copy or repeat something already out there. So if your primary goal is to have a fully worked out, set-in-stone plan, you are only upping your chances of being unoriginal.

—Ed Catmull, Creativity, Inc.: Overcoming the Unseen Forces That Stand in the Way of True Inspiration [Catmull and Wallace2014, p. 114]

The path of a hero is often a confusing one: it never leads straight to a specific goal, it is more a series of failures, a walk through a maze where sometimes it’s only by taking a wrong turn that you find your way. Sometimes we have to learn the wrong thing only to value the right thing, just like we sometimes value something only after it is lost.

Once the journey has started, the writer might wander off, discovering that the undiscovered path leads to places he or she did not plan to go. As such, the two possible approaches are to either change reality to fit your plan, or to change your own views. In this book series, I follow the latter idea: I let the discoveries I make along the way direct the path I will go.

In that regard, I have to admit that the Philosophy for Heroes series initially was planned and executed with everything but agile methodology, not even proper project management. It was an outgrowth of a hobby which turned into a book. Now that the first part is published, I have had the chance to examine the errata I received from readers and wonder, “How did that happen!?” I have shared the following curious example in a book about agile project management methodologies, Scrum Your Jira! Your Waterfall Organization Transformed Into Agile Multidisciplinary Teams :

Did Bilbo Sail to the West?

Was it Bilbo who sailed to the west? Reading Philosophy for Heroes: Knowledge [Lode2016], this seems to be the case. On page 5:

Did you know?

In the book series Lord of the Rings by J. R. R. Tolkien, the hero Bilbo undergoes a long journey to destroy evil once and for all. Through magical explanations, it is assumed that evil will not return once a magic ring is destroyed. In the story, after the heroic deed is done, the “resolution” for the hero is to sail away to another country and spend the rest of his life there. This idea of a final resolution of a problem is the traditional way of portraying a hero. But in reality, the real task would be only beginning: One would have to ask, how did the people turn evil in the first place? How can we educate them to prevent a similar disaster in the future? → Read more in Philosophy for Heroes: Epos [Lode2019]

Now, while the case could be made that Bilbo underwent a heroic transformation, that he fought evil, that he traveled to the west and might have used a boat at some point, the story sounds much more like Frodo’s story in Lord of the Rings. Myself, I am well versed in fantasy literature, and the amount of media related to the subject is anything but sparse. How could such an error happen?

My usual judgment on products (in this case, a book) is that they are a mirror of the company behind them. If you have a little bit of background information, reviewing a product can be like an archaeological dig. Philosophy for Heroes: Knowledge is a multi-layered book. First, it is part of a series. When writing the first book, the other three books had to be kept in mind. In addition, especially being the first book, it had to stand on its own despite its dealing with the basics (philosophy and language). You cannot sell a book called Philosophy for Heroes and then tell the reader to wait for part 4 to finally read about what heroism means. Second, it contains a variety of components: study questions, ideas summarizing a section, biographies adding a human element to sometimes abstract explanations, and real life examples. Skimming through the book, those components seem to be “added features” that—while adding value to the book—could just as well be removed. This points to an evolution of the book. Looking back, this is actually true, it underwent a number of transformations:

    1. A single, very large book
    2. A five-part series
    3. Then, a four-part series
    4. Then, a four-part series with the first book required to stand on its own
    5. Finally, a four-part series, the first book standing on its own, and additional components (study questions, ideas, biographies, examples, etc.)

As this evolution played out, the later changes underwent the least amount of review, while certain parts, that were already finished when devising the initial large book, had so many reviews, the time spent on dragging them along seemed like a waste. How does one write a book without having such a large variance of quality between its parts?

For this, we look at software development. A piece of software faces the same problem: it evolves, some parts are “fresh,” others have been looked at and tested for years. The solution people came up with is called “Agile” (with one variant being “Scrum”).

The best approach to writing something—anything—is to make sure that its pieces stand for themselves. The advantage of this approach is to have those pieces complete and ready, and you can publish each to get feedback and build an audience. Looking back, I should have published each section of the book separately. Sure, someone could piece all the sections together and then have a copy of the book for free. But that takes a lot of effort. Even if it is just half an hour of work, in that time one could have easily bought the book. Also, the final edit of a book surely connects the independent parts to a greater whole.

In any case, if I had followed the Agile approach, it would have been Frodo, not Bilbo, throwing the ring into the fire and traveling to the West.

Lesson learned.

Essential Steps in Implementing Agile Technologies

The Agile movement provides alternatives to traditional project management. Agile approaches help teams respond to unpredictability with incremental, iterative work cadences and empirical feedback. Agilists propose alternatives to Waterfall, or traditional sequential development.

 The Agile Movement (edited) [cf. AgileMethodology2008]

Scrum is an Agile software development model based on multiple small teams working in an intensive and interdependent manner. The term is named for the scrum (or scrummage) formation in rugby, which is used to restart the game after an event that causes play to stop, such as an infringement.

 What is Scrum? [cf. TechTarget2007]

When clients ask me to help with implementation of Agile techniques by using Scrum, my first question is: “What do you mean by ‘Scrum’?” Usually, I then hear that the company has its own special version of Scrum (or other Agile technique) because, according to the people with whom I’m meeting, their company is a special case.

First, yes, your company is a special case. Each company is unique and in a special market niche. Second, if you followed the evolutionary approach of improvements in small increments, you have adapted your process to the environment of the company. No two companies are alike. Hence your need for an external consultant to examine the special conditions in your company.

Introducing (and running) Scrum means that you want to change your company according to proven methods. You can’t have your cake (Scrum) and eat it, too (changing Scrum to suit your company)—you can’t improve your company by adapting the Scrum process to your company.

As a consequence, the reality I see all too often is that the company hires a Scrum Master who merely acts as a supporting firefighter, accompanying the former project manager (now “product owner”) and running around the company putting out fires. This kind of extra resource is justified to upper management by pointing to “Agile” and its use in other companies…

WATERFALL ·  Waterfall is a project management method where a product moves through a number of phases before a final version is finished for release. Compared to Agile, the problem with this method is that it requires additional communication channels between the individual phases and that the time until a team or company gets feedback from a customer is generally much longer.

SCRUM ·  Scrum is a set of management tools that focuses a project back on the team level and uncovers internal and external impediments of the production process. By reducing communication paths through small, multidisciplinary teams, as well as frequent releases to the customer for review, the probability for project success can be improved even if the scope is not clear from the start. In addition, work is divided into units of fixed lengths (sprints) which helps to plan future sprints with your team working at a sustainable speed.

SPRINT ·  A sprint is a timespan of one to four weeks within which a certain selection of stories should be finished by the team. Given the fact that the whole team spends 10 percent of the time (depending on the sprint length) planning and reviewing each sprint, the goal is to reach 100 percent completion of all stories while meeting the project’s quality standards and without overtime. Like a marathon runner needs to carefully plan her energy, planning a sprint requires very good estimation skills by the teams.

SCRUM MASTER ·  The Scrum Master controls the Scrum process. Besides proactively identifying and removing impediments to the process, the Scrum Master also supports the team in meetings as a moderator and individually in personal talks. The Scrum Master also stands up against outside influence on the process, ideally by propagating the Agile idea throughout the organizations and by explaining why certain restrictions are necessary for the overall project success.

PRODUCT OWNER ·  The product owner is part of the Scrum team and represents the stakeholders. The main task is stakeholder management as well as having a deep understanding of what the project is about and being able to make decisions. A product owner fills and prioritizes the backlog, keeping the complexity estimations of the team in mind. The product owner should have full authority and the final say about the prioritization of the backlog. During the sprint, the product owner answers questions from the team about the scope of the project, as well as gives feedback about finished (but not necessarily done!) tasks, but otherwise does not interfere in how the team manages its work.

Looking at the actual causes of problems

One of the techniques used in project management is to find the cause of an issue. Digging deeper, my next set of questions to the client usually focuses on the greater picture or vision of the company. Instead of telling me about their mission, they typically respond that they want to “test” Agile and then implement it in other parts of the company.

Besides noting the obvious misunderstanding of Agile as the new (local!) management technique, questions arise: What would success look like? What would failure look like? What are the concrete, measurable business objectives of the project of introducing Agile?

I am convinced that introducing Agile itself should be managed with modern project management techniques, PMBOK being my favorite. Managing Agile goes far beyond the scope of this chapter, but you certainly must have an idea about where you are going with it and what you want to achieve.

PMBOK® ·  PMBOK stands for Project Management Body of Knowledge and describes a generic system of workflows within a project. While it is mainly applied to Waterfall projects, many of its parts can also be used in an Agile project, like defining how the team communicates with the outside world, defining the vision and scope of the project, or defining why one would want to use Scrum at all. [PMI2013]

To illustrate this further, I recommend reading Ayn Rand’s introduction to philosophy that looks at the example of an astronaut stranded on a planet:

Suppose that you are an astronaut whose spaceship loses control and crashes on an unknown planet. When you regain consciousness and find that you are not badly hurt, the first three questions on your mind would be: Where am I? How can I find out? What should I do?

You see unfamiliar vegetation outside, and there is air to breathe; the sunlight seems paler than you remember it and colder. You turn to look at the sky, but stop. You are struck by a sudden feeling: if you don’t look, you won’t have to know that you are, perhaps, too far from Earth and no return is possible. So long as you don’t know it, you are free to believe what you wish—and you experience a foggy, pleasant, but somehow guilty, kind of hope.

You turn to your instruments: they may be damaged, you don’t know how seriously. But you stop, struck by a sudden fear: how can you trust these instruments? How can you be sure that they won’t mislead you? How can you know whether they will work in a different world? You turn away from the instruments.

Now you begin to wonder why you have no desire to do anything. It seems so much safer just to wait for something to turn up somehow; it is better, you tell yourself, not to rock the spaceship. Far in the distance, you see some sort of living creatures approaching; you don’t know whether they are human, but they walk on two feet. They, you decide, will tell you what to do.
You are never heard from again.

This is fantasy, you say? You would not act like that and no astronaut ever would? Perhaps not. But this is the way most men live their lives, here, on Earth.

—Ayn Rand, Address to the Graduating Class of the United States Military Academy at West Point New York (adapted) [cf. Rand1974]

In terms of a company, your immediate goal is of course to survive the next month. But then, you have to establish where you are on the map. You have to open your eyes, look at the sky, and check your instruments.

In terms of Agile, I recommend to my clients that they run it like a project. We know what works from hundreds of studies, and we can create a list of items that are implemented in Scrum. In that list, we simply mark the current state of the process. Often, even in non-Agile companies, some processes have already been implemented because the people who are managing projects notice which processes work. A simple approach is to check again the Principles Behind the Agile Manifesto [cf. Beck2001]:

  • Welcome changing requirements.
  • Trust and motivate individuals on your team and other teams in the company.
  • Developers and non-developers (e.g., marketers, salespeople) must work together daily.
  • Face-to-face is the most efficient and effective method of getting things done.
  • Progress is measured in terms of working software.
  • The entire team must promote sustainable development, they should be able to maintain a constant pace indefinitely.
  • The entire team must work together to continuously improve technical excellence and to enhance agility.
  • Keep in mind that simplicity is valuable; simplicity is the art of maximizing the amount of work not done.
  • The best solutions emerge from self-organizing teams.
  • Effective teams reflect regularly on how to become more effective.
  • An Agile company satisfies customers through early, frequent, and continuous delivery.

Together with the client, for each point, I detail how this is implemented in the company—this is the first step of documenting the current process. If I can’t explain how it is implemented or if we find that it is not implemented, I focus on those points and try to find explanations for each: why the company is not able or not willing to fulfill this part of the Agile process. And I do not just ask, “Why?” I ask, “Why why why why why…?” until I find out the actual reasons something has not been implemented. [cf. Ohno2006]

And at this point, the real work starts: addressing those issues that hinder the Agile process on a daily basis.

Lessons Applied

With the mistakes of Philosophy for Heroes: Knowledge in mind, this book was created as a series of regular articles, to be released on the website. This kept each section limited in complexity and scope, kept me and my editor focused on the task, kept any perfectionism in check, and most importantly, we got feedback. After both chapters were written and released, we combined them into a whole book, and re-edited them to fit together. We decided that it is OK to release articles to the web as early as possible. Early adopters can read them online for free, and anyone who wanted a polished version could wait for the final book. Another great advantage we found is that global design issues—like capitalization of certain words, adding a glossary, and generally streamlining the technical terms—could be tackled later. Lastly, it reduced the urgency toward the end. The chapters were already online and “working” in terms of garnering interest. People got curious about the book while we were still writing it. That, I think, is the power of Agile applied. To summarize, we incorporated:

  • bi-weekly chats
  • early releases for feedback
  • keep perfectionism in check
  • keep complexity in check
  • market while still writing
  • focus on global issues later

And, perhaps the most important point, enjoying a feeling of accomplishment.

Of course, this did not always work as planned, given some of the complexity of the subjects and my own tendency to write more when I really like a certain topic. But compared to the time we needed for the first book, it was a huge improvement. And if applied more consistently, the third book will be even better and be completed even faster. Ultimately, of course, it is up to you to judge: which of both books did you like more?