Is Agile Skub?

On a long wall at work, there's a glass board (probably 40 feet or so wide) on which our CIO will ask questions and anyone passing by can answer using dry erase markers. The question most recently posed is something to the effect of "What are you doing to be more Agile?".

I found it interesting that somebody wrote "Pro Skub" on one end of the board and "Anti Skub" at the other end. What is Skub, you ask? It's a reference to a Perry Bible Fellowship comic, penned by Nicholas Gurewitch.

This raises an interesting question for me: is Agile nothing more than a meaningless buzzword that arouses passion on the fringes that comes across as absurd to everyone else? To at least one person in my organization, it would seem the answer is "Yes!"

To me, this is an indicator of the "Trough of Disillusionment" on they Hype Curve. It reminded me of an article titled "The End of Agile: Death by Over-Simplification". To me, the points made by this article and others that it references indicate an over-emphasis on practices or principles in silos. In other words, teams will focus on one specific principle, practice, or approach under the banner of Agile and claim that it will solve all of their problems. Of course it doesn't, and when it doesn't it leads to disillusionment and cynicism.

It is so crucially important that we take a step back and look at the whole Agile Manifesto, with all of its Principles, along with complementary principles and approaches (such as Lean and Flow). Practices, approaches, and methodologies are all tools, and none of them sacred, in an attempt to align more with the Lean|Agile paradigm that will drive successful teams.

A(nother) Response to SAFe Criticisms: Part 1

Full Disclosure: I am a certified Scaled Agile Framework (SAFe) Program Consultant (SPC).

Before you continue reading this somewhat lengthy, multi-part blog post, let me lay out the prerequisites. Well, really just the one. If you are not already at least somewhat familiar with Dean Leffingwell’s Scaled Agile Framework (SAFe) then this post is not going to be as meaningful to you. The official website for SAFe is http://scaledagileframework.com, although there are others out there (Andrew Blain, for example) who have done a good job of explaining what SAFe is.

Last year Dean Leffingwell (and SAFe in general) had a significant presence at Agile2013. In response, Ken Schwaber wrote a provocative blog post entitled “unSAFe at any speed”. What Ken failed to accomplish was to produce criticism that was any more founded than your run-of-the-mill angsty hearsay. He did, however, manage to set off a civil war within the Agile community over whether or not SAFe should be allowed in the Agile club or beaten until silenced or killed. I have been rather surprised at how many “Agilists” have chosen the latter.

Agile has always appealed to my inclusive nature. The goal is outlined in the Agile Manifesto and its 12 Principles. Anything that strives to deliver within the paradigm of the Manifesto and its Principles can be considered Agile. All approaches have strengths and weaknesses, and all approaches focus more on some aspects than others. In the end, though, all approaches are well-intentioned efforts to elevate teams to their potential. I think that’s beautiful, I really do.

A roadblock that has existed for years is that of large organizations who are not already Agile. Getting these behemoths to shift the way they work, much less the way they think, is no easy task. Many have taken the “All or Nothing” approach – either adopt an existing Agile approach in its purest form, wholesale, with no alterations, or surrender yourself to your competition, wither away, and die. Neither of these options is particularly appealing to most of these organizations, so they ignore Agile and continue their status quo.

Along comes Dean Leffingwell and SAFe and, all of the sudden, you have an Agile approach that the organization can use to become Agile. Of course it looks different from the other options currently available, but that’s kind of the point. It aims to establish Agile Principles and Lean Thinking in larger enterprises in increments that are actually realistic. Just as every Scrum team is different, every organization that adopts SAFe does so in its own way. And, just like Scrum, a lot of the implementation details cannot be neatly outlined in a guide or abstract for anyone to pick up and repeat without putting in any of the effort.

The reality of the situation makes the Purists out there really uncomfortable. A lot of criticism has been published. I am going to attempt to address some of this criticism. My intent here is not to get everyone out there to use SAFe. Heck, I don’t even intend for everyone to like it. My intent is to clarify a few misconceptions, first and foremost the one that SAFe is not Agile.

I’ll be publishing my response in multiple parts in order to accomplish this intent. The number of parts depends, at least partially, on you. I want to know what criticisms or misunderstandings of SAFe you would like me to respond to. I would further ask that you communicate with me as a respectful professional (and I’ll do the same). I’ve seen this topic get out of control without ever getting to root cause. Not that I have delusions of grandeur or anything, but I’d like to think that I can help find and address the root cause of these criticisms without it turning into a shouting match. I guess we’ll find out.

Series Posts:
Part 2: 25% Scrum Master
Part 3: HIP Sprints

Agile Complements

I was recently asked to explain the relationship between Agile and Innovation. I was intrigued by the question as I've never really tied the two together. In thinking about it, I've concluded that Agile complements many things, but it doesn't necessarily drive any of them.

The Role of Practices

The Agile Manifesto clearly states that one who considers themselves Agile values "Individuals and Interactions over Processes and Tools". However, we know that there is some value inherent in Processes and Tools, primarily in the behaviors that they reinforce. Given it's popularity, let's take Scrum as an example. Scrum has a highly prescriptive process that still manages to leave a lot up to the team. Sprint Planning reinforces commitments and transparency; the Daily Scrum reinforces face-to-face communication and self-managing teams; Sprint Reviews reinforce feedback loops within the team, as well as with stakeholders and customers; Sprint Retrospectives reinforce continuous improvement; the Sprints themselves reinforce small time-boxes; and on and on and on.

If you want to reinforce something positive at work, whether it be innovation, elimination of waste, any of the items listed below, or pretty much anything else, you can find an Agile process, tool, or practice that will reinforce it. With Innovation, you can take the practices of Capacity Allocation and Spikes to explicitly include time and effort for innovation into your process. This is assuming we're talking about developing innovative things, in addition to a Retrospective or other feedback mechanism for innovating the process and team themselves.

However, it is possible - and happens all too frequently - that teams adopt these processes, tools, and practices superficially, thus obtaining little, if any, of the intended benefit. In order to effectively reinforce behaviors, those behaviors have to already exist as part of your culture.

The Role of Culture

I've blogged multiple times about the difference between doing Agile things and "Being Agile" ("Agile: The Book vs. The Movie", "Understanding the 'Why?'", "Descriptive versus Prescriptive", "I Madge I'll - Agile Posers", etc). To deliver the best results possible, your team has to be Agile - they can't just superficially adopt an Agile implementation. When asked to explain Agile, they should go to the manifesto first and the day-to-day second. At the risk of getting too theological, Agility is a state of being and influences all aspects of a person's life (at least at work). Simply put, you have to establish a culture of Agility, where the principles are embedded in your company's DNA.

The same is true of Innovation or anything else. When people think of innovative companies they think of companies that have a culture of Innovation. Innovating isn't something you do as much as it's part of who you are. Of course their processes, tools, and practices reinforce Innovation, but that's a byproduct of something deeper.

As I said before, you can use tools from the Agile toolbox to help drive Innovation, but it can't just be lip service. If your company was built on Innovation (and it probably was) then get back to your roots and tell that story; remind people where they came from. Make Innovating seem natural, like coming home and eating comfort food.

No Silver Bullet

I'm going to be going more in-depth in the coming months on the idea that no one Agile implementation should be seen as a Silver Bullet. Before you implement anything, ask yourself "Why?"; what result or behavior are you hoping to get from it? Understand that different Agile processes, practices, and tools have their own strengths and weaknesses. Sometimes you'll have to blend different solutions to make something new that fits your needs. Sometimes you'll have to invent something that hasn't been done before. Most importantly, you will always have to examine what you're doing and ask what you need to change to be better. Keep the mantra "Never Perfect; Always Better".

Can Agile help drive Innovation? Sure. But some approaches will do that better than others. Begin with the end in mind, but remember that this is a journey and you don't know what you don't know. Be willing to adapt, but don't lose sight of your vision. If it sounds hard, that's because it is; if this were easy then we wouldn't be having this conversation!

What do you think?

Seriously, what do you think? Please tell me! I really don't like the "thought leader in a vacuum" setup. What I've shared here is the result of my learning and experience, but I recognize I don't know everything. I crave the perspectives of others. I want your insights, suggestions, criticisms, reinforcements - all of it. Leave a comment or tweet me @MLCarey321.

Muscle Memory vs. Muscle Confusion

The most popular Agile methodology in practice today is Scrum, which relies heavily on ceremonies. Any decent Agile coach working with a new Scrum team will drill these ceremonies into them in an effort to get the most out of the framework. They drive cadence, alignment, continuous improvement, transparency, etc. One of the big benefits of doing this is that it becomes a part of their routine. They no longer have to figure out how they're going to align on a daily basis; plan their work; communicate with their customer; inspect and adapt; etc. All of those things are "baked in" to the framework. Because there's so little prescribed, it's easy to pick up and repeat forever. By making those things rote, you develop a sort of Agile "muscle memory".

Wax on, wax off, stand up for 15 minutes

Muscle memory is a condition where a task is repeated so frequently that it can be performed unconsciously. Just think of Mr. Miagi and Daniel-san in The Karate Kid. Mr. Miagi had a lot of landscaping work to be done, and Daniel wanted to learn Karate. As luck would have it, the motions required of a Karate black belt are the same as sanding decks, staining fences, and washing cars - who knew? Right as Daniel is ready to throw in the towel, Mr. Miagi attacks him Daniel's muscle memory kicks in to save himself from being pounded by a Karate master. Likewise, those Scrum ceremonies become reflexive and help new Agile practitioners focus on the hard task of developing new software instead of thinking about how they're going to go about "Being Agile".

However, too much of a good thing can be bad. Once that muscle memory kicks in, it makes it harder for our Agile "muscles" to grow. The body has optimized how to do the repetitive thing, and doing it more doesn't really result in any added strength. This is a problem that strength trainers and body builders are familiar with. Your workout routine can't be too routine or you'll plateau. You have to introduce what's called "muscle confusion".

Muscle confusion is the concept of varying the types of exercises you do, as well as the number of sets and reps of those exercises, to avoid muscle memory and keep building muscle by tearing it and letting it repair stronger. If muscle memory kicks in then it becomes harder to tear the muscles. You see this concept manifest in workout regimens such as P90X and Cross Fit. One of the difficult things to get right, though, is the right amount of muscle confusion. Switching 100% of your exercises 100% of the time won't get you optimal performance.

I liken muscle confusion to a Kaizen mindset in Agile. You have to have an urgency about change, but it has to be small, incremental change in order to be effective. Change too little and muscle memory sets in - boring scrums, useless retros, tedious planning, etc. Change too much and the disruption causes everything to start falling apart.

P90X and Cross Fit are not for everyone. You will have to determine as a team how much change you can handle on a sprint by sprint basis. Some will change almost daily, others will be lucky to successfully adapt on one thing per sprint. As long as you're being honest with yourselves, that's fine. Just beware of muscle memory and muscle confusion. Optimize the change, and there are no limits to how much you can grow your Agile strength.

I Madge I'll - Agile Posers

When I meet someone who wants to talk about Agile I start by asking, "What do you know about Agile?" Most of the time I begin to hear those key buzzwords the newly indoctrinated are so proud to spout off: "It's where, instead of Waterfall," said with a grin and a wink, "your scrum has sprints and they stand up and there's no requirements and you demo and it's amazing!" I often think to myself, "Seriously? Why do these people think this?" So recently I decided to apply Occam's Razor and ask what the simplest answer is. My conclusion? Somebody told them this.

Consultant Speak*

Okay, so I don't think anyone told them something quite so incoherent as what I put, but they definitely started out with 1) a specific methodology in mind, almost certainly Scrum, and 2) an unholy amount of buzzwords and Agile vocabulary to accentuate just how different Agile is from the dreaded Waterfall. I get it - you're probably (relatively) new to Scrum and you're super excited about it and want the whole world to know how it changed your life. Unless, of course, you're a consultant who's trying to confuse a potential client into throwing money at you to turn their IT shop around. Tsk, tsk.

"...It's Not What You SAY, It's What You HEAR!"

The problem is these people don't know what Agile is. They don't fully understand what it is they're saying. All they know is that if they keep saying certain words with enough conviction then people will think they know what they're talking about. It reminds me of the game "Mad Gab". In case you're not familiar, players in the game read words on a card that don't really make any sense. They're not supposed to. The words on the cards, said with the correct inflection and pacing, are supposed to sound just like a commonplace phrase that your team is trying to guess. For example, these new, hopeful, and largely ignorant future Agilists are saying "I Madge I'll" in hopes that you'll hear "I'm Agile"! The problem is they aren't.

Agile Posers

I was recently working with a fellow Agile Coach (I know, I don't care for the term, either, but I'm not sure what else to call him) and we were collaboratively taking notes via Google Docs. On occasion we would have an impromptu discussion in the document due to a tangent that our notes took us on. One such tangential conversation was about Agile Posers. It went a little something like this:

"‘how to spot an agile poser’ (consultant-speak?)

1.one who pretends to be someone who's not. 2. who tries to fit in but with exaggeration
urban dictionaryl33t speakpwned you, you poser

'5. Someone whos acts like someone they’re not,but not realizing that there being fake, basically a loser trying to fit in.' - UrbanDictionary.com

'6. A poser is someone who tries hard to be something they arent. Usually, posers call other people posers because they are jealous that the person they called a poser is more skater/stoner/goth/punk/rocker/grunge/Agile/etc. than they will ever be.' - UrbanDictionary.com

posers often fool themselves first.  they aren't always (deliberately) not

ask probing questions.  why do you like it, what was good, test their belief."

On the off-chance any of my readers are Trekkies...

Our conversation went on to include things such as mining for conflict and Open Space sessions as means to help draw out and coach Agile posers. Take another look at definition #5. These are the people I'm talking about here. Those who want to be Agile, who hear about it and crave to belong. They'll ask anyone who claims to be Agile what that means and they'll cling to whatever they're told. So what's the take-away here? Tell them the right thing!

Being Agile vs. Doing Scrum

When people ask me what Agile is, I always go to the Manifesto and backing Principles first. I emphasize over and again that Agile is a way of thinking, a paradigm, a perspective, an approach. Yes, there are implementations and yes, Scrum is the most popular by far and yes, there are those who will tell you that the definition of Agile is Scrum. I'm here to tell you that it's not.

So what's the harm in people thinking Agile is just Scrum? Scrum's not all that bad. Of course it's not. I love Scrum, it's helped my organization tremendously. The problem with believing that Agile is just Scrum is it sends you on a quest to be the best implementer of a set of practices. Your Retros will eventually dry up because you can't get any more Scrum-like. But you'll keep doing them because "that's Scrum." You have to understand why Scrum is set up the way it is. Why you're asked to perform certain ceremonies. You have to know in what direction to Adapt when you Inspect in your Retros. And, most importantly, you have to be willing to break the rules like an artist once you've mastered them. You have to be willing to try things that are not in the Scrum Guide. You need Kaizen!

I'm Right!.. Am I Right?

As per usual, I don't have much to go on here other than my experiences and the stories I hear from others. So I want to know: What does being an "Agile Poser" mean to you? Have you experienced those "Mad Gab" Agile enthusiasts? Have I hit the mark on being Agile versus doing Scrum, or am I way off base? I want to know what you think, and I want to use your ideas to make myself better (being completely transparent here). Please leave a comment or shoot me a message on LinkedIn. I'd love to hear from you.



* I received some feedback that this post was offensive to consultants. I would like to clarify that I am not trying to group all consultants together and say that they are all this way. I am basing this on conversations I've had with people who were introduced to Agile by these types of consultants; observations from a friend who is a former consultant; and my first-hand experience with sub-par consultants. I know there are amazing consultants out there - I've met them, too, and admire the work they do - but there are an alarming number of consultants out there who do fit this bill.

Conversation

Many Scrum practitioners don't realize that Scrum did not invent the idea of User Stories - XP (eXtreme Programming) did. They are, however, often familiar with Ron Jeffries' "3 C's of a User Story", namely Card, Conversation, and Confirmation. The more I train teams on User Stories, the more convinced I am that the Conversation aspect is the most important of the three, and it is applicable to all things Agile, not just User Stories.

I recently facilitated PSI Planning for my area's Agile Release Train (Potentially Shippable Increment). I’ve noticed that, with each new PSI, the teams become more concerned with extensive pre-planning. They try to get more out of the meeting by doing as much of the actual planning before arriving at the meeting. Unfortunately, they do not understand that the primary reason for PSI Planning is not to generate a plan as much as it is to have conversations. Teams must communicate and align with each other and their customers. They must examine their work to determine what dependencies and risks are inherent in the work so that they can communicate, manage, and mitigate them as much as possible. This process happens to produce a better plan, which is why we do it. However, those who come to the event with pre-determined plans often find they must be reworked or scrapped altogether.

Rework manifests itself as delay, and delay indicates waste. Agilists hate waste. In fact, an Agilist’s views on waste and rework can be found in the 10^th principle that accompanies the Agile Manifesto: “Simplicity – the art of maximizing the amount of work not done – is essential.” How do conversations help prevent rework? If we talk before acting then we get a better sense of the truth, established in an environment of shared context. Conversations mean multiple perspectives, which bring difficult questions and challenge our assumptions. They force us to produce something as a group that is better than could ever be produced in a silo. They reinforce the paradigm of “just enough, just in time” instead of “big up-front”.

Once I realized that conversations are integral to Agile, I began to review the tools and practices within Agile, specifically Scrum, for conversations. All of the prescribed ceremonies – Daily Scrum, Sprint Review, Sprint Retrospective, and Sprint Planning – center on team conversations. Pair Programming and Test-Driven Development are XP practices that rely heavily on communication, both within the development team as well as between the developers, testers, and customers. A good Scrum Master helps the team most by facilitating conversations, and the Product Owner’s backlog is meaningless if they don’t ensure the team understands the work. There are conversations baked into literally every aspect of Scrum!

Conversations are often overlooked because people do not view simply having the conversation as an objective in most cases. They focus on the stated outputs: plans; acceptance criteria; status updates; confirmation of stories completed; etc. Consequently, it is not uncommon for teams to find alternative means to deliver these results without the “overhead” of the conversations. They rely heavily on tools and individual efforts to maximize their time without hindering the team with human interaction. They may, at first, feel an increase in productivity as the perceived burden is lifted. Yet, inevitably, they find themselves struggling to deliver quality quickly and do not understand how Agile could betray them so. Hopefully they have a good Scrum Master or Agile Coach watching them adapt in the wrong direction that can have them take a step back so they can see the error of their ways. If not, it becomes easy to blame their frustration on Agile and revert back to their comfort zone of more “traditional” methodologies.

As a safeguard, I recommend teams, and especially Scrum Masters, go back to their roots frequently to make sure they’re staying true to the founding principles that make Agile methodologies so great. Remember that “business people and developers must work together daily throughout the project,” and that “the most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Don’t just blindly follow a framework or practice; instead, try to understand why you are asked to do things a certain way. If the purpose that you perceive is not aligned with the Agile manifesto and its accompanying principles, you’re probably wrong. Acknowledge your failure, “Fail Fast”, and change your approach so that it fits the Agile paradigm. It may seem counter-intuitive at first, but it will pay off in the long run.

People vs. Process ... vs. Principles

“Be firm on principle but flexible on method.”

-- Zig Ziglar

Until recently, I have observed the difficulties and issues manifested in the work environment and debated, both with myself and with peers, whether the root cause was the people being unskilled or unmotivated or the lack of a quality process. It was not until recently that I have come to realize that it is the founding principles on which we operate that makes the biggest difference in how successful we are.

When debating people versus process, the argument for people is that good people seem capable of producing amazing results regardless of process. However, I’ve seen great people time and again be suppressed by poor process, being forced into inefficiency for the sake of policy. In grass-roots meetings and informal conversations, both within my company and in conversations with others across the industry, I hear complaints of red tape, write-only documents, and wasteful tools and bureaucracy that dishearten and discourage talented people. At best, people are being forced to work below their capabilities. At worst, people are lost to another company that doesn’t include such roadblocks.

On the other hand, a good process can, ideally, bring a team to a hyper-performing state quickly and keep them there, while poor processes seem to only be good for shielding people from the ugly truth. Processes, policies, methodologies, and frameworks that emphasize value and seek to eliminate waste tend to bring out the best in people. The downside is that the best processes expose weaknesses within the team and force them to confront their demons. If the problem is the people are not skilled or committed enough then they may not be willing to put in the effort required to get the team to where they need to be. The best case scenario is the team members who are unwilling to change leave to free up the rest of the team to reach their potential, while the worst case is they stay and cause the team to drag and stagnate.

Neither of these seems to get to root cause, so let us consider the principles that form the foundation for people’s decisions and behaviors. When considering founding principles as the root cause, it is necessary to start with two assumptions. The first is that the people doing the work are genuinely doing the best they can with what they have. It may be somewhat altruistic, but I believe it is true for most people. The next assumption is that these same people are working with a process and in an environment that allows for and even encourages continuous improvement. Whether it’s explicit or not, people tend to adapt the way they work over time, based on their experiences and their guiding principles.

If my assumptions hold true, and my experience tells me they do, then those guiding principles that determine in which direction the process evolves are the most important factor in driving productivity, efficiency, and morale. The founders of the Agile Manifesto understood this. They came from various backgrounds exercising various forms of what are now considered Agile Methodologies. They did not define any specific process for success – instead, they defined a mindset, a paradigm, for approaching Software Development. They backed this manifesto with 12 principles, only one of which pertains to the type of people that are needed to be successful:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

The only qualification they state is that the individuals be motivated. Surely some people are inherently more driven than others, but, for the most part, motivation is something that can be fostered by the culture and environment that the individual is operating in. The other 11 principles provide great insight into how those people should work as well as what should be done to support those people in their pursuit of high quality Software Delivery. If people have learned and accepted these principles then they will recognize how important and urgent it is for them to improve individually, not just as a team. It is not a character flaw to admit imperfection – indeed; it is the manifestation of character that one can admit to room for improvement.

The Agile Manifesto is not the only source of correct principles. There are many books and courses in existence that focus on this very subject. The whole premise of Lean Six Sigma is there are solid principles that can be applied in any situation to eliminate waste and reduce delay. I think Lean, Agile, and Product Development Flow principles are the most crucial to our combined success, but I recognize that there are others. What I would like for you to ask yourself is, “What are my guiding principles? When things get uncomfortable, how do I evolve the way I work?”

Why is this important? Because too often we pick up a new process hoping it will be our Silver Bullet, the solution for all our problems, the answer to all our prayers. But we adopt these processes without taking the time to understand the principles on which they were founded. As a result, we bend the process to fit what we are comfortable with and lose much, if not all, of the benefit the process could have afforded us. This mistake of adopting a process without adopting its defining principles is what I’ve referred to previously as the “Movie Version” of that process as opposed to the “Book Version”, and the book is always better than the movie.

Only by taking the time to understand correct principles will we be able to govern ourselves most effectively. As Blaine Lee said, “The principles you live by create the world you live in; if you change the principles you live by, you will change your world.”

Agile: The Book vs. The Movie

I’ll be the first to admit that I’m a pretty big bookworm. I also love to go to the movies, which is less and less frequently now with young children at home. It’s an all too often occurrence for me to read a book and, as I see the images play out in my mind, think, “This would make a great movie!” Of course, that sentiment occasionally becomes reality and I find myself leaving the theater thinking, “The book was so much better than the movie!” The movie may even be good. It may be the best movie I see that year. But the book is invariably better.

I see teams, both inside my company and out, that struggle with making Agile work. Too often they get some basic knowledge, get really excited, and start forging onward without taking the time to continually research Agile best practices and innovations. It’s a stripped-down version of Agile, usually built on the roles and ceremonies only and not the principles on which Agile is founded. They’re taking all the action, but cutting out sub-plots and character development. It’s the movie version of Agile.

Over the past year, I’ve had several people express how impressed they are with how “by-the-book” my area is running Agile. And it’s true; we stay very true to the published recommendations that are widely accepted by the industry. We’re able to do this because the team has changed the way they approach software development. They have changed their mindset to one that aligns with Lean and Agile principles. They are flexible and embrace change because they know if something doesn’t work they can dump it after 2 weeks when the Sprint ends. This paradigm shift is essential for teams to be successful with Agile. It’s also the Scrum Master’s greatest challenge.

A team can run Scrum without a dedicated Scrum Master, but they are largely secretarial. They ensure the ceremonies are held and time-boxes are respected, but not much else. A dedicated Scrum Master is also a mentor and coach, with much of their time spent removing impediments; resolving conflict, hopefully in a productive way that results in learning and compromise; evangelizing Lean and Agile principles; and advocating XP and other technical excellence practices. This helps the team obtain and retain their “High Performing” status indefinitely. This is all made possible not in spite of all the change that is inherent in Agile, but because of it.

When it comes to Agile, I’ve “read the book” and “seen the movie” and, as with all other cases, the book provides a much richer experience. It might take longer to get through; it might take some imagination; and you might have to read it more than once. But the book is invariably better.