Customer Reviews: The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
Automotive Deals HPCC Amazon Fashion Learn more Discover it $5 Albums Fire TV Stick Health, Household and Grocery Back to School Handmade school supplies Shop-by-Room Amazon Cash Back Offer angrybirds angrybirds angrybirds  Amazon Echo  Echo Dot  Amazon Tap  Echo Dot  Amazon Tap  Amazon Echo Starting at $49.99 All-New Kindle Oasis AutoRip in CDs & Vinyl Water Sports

Your rating(Clear)Rate this item

There was a problem filtering reviews right now. Please try again later.

on January 15, 2013
You've probably heard of Gene Kim, Kevin Behr and George Spafford before. They are the three amigos responsible for The Visible Ops Handbook, which can be found in the book pile of every good IT operator. Their new book, The Phoenix Project, follows the format of Eliyahu Goldratt's classic, The Goal, and I was lucky enough to be given an advance copy to review.

Told from the perspective of newly-minted VP of IT Operations Bill Palmer, it describes the turnaround of failing auto parts company Parts Unlimited. This is to be achieved through the delivery of the eponymous Phoenix Project, a classic "too big to fail" software project designed to build a system which will revive the fortunes of the company. To quote (p51):

"The plot is simple: First, you take an urgent date-driven project, where the shipment date cannot be delayed because of external commitments made to Wall Street or customers. Then you add a bunch of developers who use up all the time in the schedule, leaving no time for testing or operations deployment. And because no one is willing to slip the deployment date, everyone after Development has to take outrageous and unacceptable shortcuts to hit the date.

"The results are never pretty. Usually, the software product is so unstable and unusable that even the people who were screaming for it end up saying that it's not worth shipping. And it's always IT Operations who still has to stay up all night, rebooting servers hourly to compensate for crappy code, doing whatever heroics are required to hide from the rest of the world just how bad things really are."

Part One of the book describes in loving detail the enormous clusterf*** pie that is baked from these ingredients. The pie is spiced with an internal Sarbanes-Oxley audit which reveals 952 control deficiencies, an outage of the payroll processing system, and various other problems that conspire to deepen the woe of the operations group, all of which are clearly drawn from the deep well of the authors' real-life experiences.

Apart from the main characters - our hero Bill, his boss Steve, and the evil villain Sarah - The Phoenix Project features a delightful rogues' gallery which anyone working in an enterprise will recognize:

* Brent Geller, the boy wonder whose encyclopedic knowledge of the company's Byzantine IT systems ensures that everybody turns to him to get their work done.
* Patty McKee, the Director of Support who runs a change management process so bureaucratic that everybody bypasses it.
* John Pesche, the black binder wielding Chief Information Security Officer whose cack-handed attempts to improve security ensure that nobody can actually get anything done.

Part 2 details how the IT group is reborn from the ashes of the Phoenix Project into a high-performing organization that is a strategic partner to the business. This is achieved through the application of a heavy dose of lean thinking (including [...] ) administered by Erik, a mercurial IT and manufacturing guru Steve is courting to join the board. The book does an excellent job of showing - as well as telling - how to apply the concepts (and the effect of doing so) in an enterprise with plenty of technical debt. Perhaps the most eyebrow-raising part of this section is the way in which John has his soul mercilessly crushed to the point where he goes on a multi-day drinking spree before he is rehabilitated towards the end of the book (he is a phoenix too).

John's narrative arc is just one example of how the book also succeeds as a novel. It's gripping, with moments of drama and high emotion, as well as some great one-liners. There was even one point when I teared up (bear in mind that I also cried during Forrest Gump - unlike the book's central characters, I did not serve in the armed forces).

Nobody who has read The Goal will miss The Phoenix Project's similarity in terms of style and plot. Perhaps my favourite thing about the book's pedagogical style is the way Erik (like Jonah in The Goal) uses the Socratic Method to give Bill the tools to solve his problems by himself. Of course this learning process is fictional, but it means you get to see Bill struggling with the questions and trying things out.

It remains to be seen whether readers of the book will be able to apply these techniques as successfully as Bill without a real Erik to guide them. But of course, this is a limitation of any book. If I had one criticism it's that unlike real life, there aren't many experiments in the book that end up making things worse, and it's this process of failing fast, learning from your failures, and coming up with new experiments that is instrumental to a real learning culture.

Overall, The Phoenix Project is a fantastic read. It's entertaining, cathartic, inspirational and informative. If, like me, you have an enormous backlog of books (and more work in process than you'd like) I suggest giving yourself a break and putting this one to the top of your list. It'll only take you a couple of days, and despite its conceptual density it will leave you feeling refreshed and energized with a bunch of new ideas to try out. The Phoenix Project deserves to be read by everyone who works in - or with - IT.
22 comments| 97 people found this helpful. Was this review helpful to you?YesNoReport abuse
on March 11, 2013
I am a SysAdmin and have just finished "The Phoenix Project." I've reviewed this book on my blog, so if this sounds familiar perhaps that's where you read this text. However, I would also like to share it here for future readers that purchase the book through Amazon.

*The TL;DR Review*

The book is a fictional account of a director of IT at a large enterprise; an enterprise that has a deeply flawed IT organization that is dragging the company into destruction. He is quickly turned into acting VP of Operations after the sudden departure of the last VP. Bill has 90 days to turn the IT department around or face the dual threat of a total IT outsourcing and the failing company being split apart by an aggressive and impatient board of directors.

The storytelling is poor. The concepts themselves are great, however not explained to the depth that you would expect from a 300 page book. If you have a genuine interest in doing better as an IT person in general, pick the book up and see if it excites your interest in the various operational methods to getting things done for the business using IT. This is not a management book. This is not a developer book. This is not an operations, sysadmin, cloud, ITIL, infrastructure, or $buzzword book. This is about workflow management done from a factory background that can be applied to anyone's work. If you're skeptical of the so-called DevOps movement, don't be afraid of this book.

I'd give it 3.5 out of five stars if Amazon allowed me to give half stars, however when I pressed myself to fall on a solid number, I chose three rather than four.

*The Long Review*

The story centers around Bill Palmer, a late-thirties former marine with a wife and two kids. He starts the story as the Director of Midrange Technology Operations. Side note: I have no idea what "midrange technology operations" is, nor did I figure it out after some Googling.

He is quickly thrust into the position of VP of IT Operations to fill a sudden vacancy. He and his entire department is thrust under the intense scrutiny, skepticism and frustration of a hard nosed CEO, board of directors, and SVP of Retail Operations. It's fix or fail time, and he's got everyone working towards failure.

Before we go any further, let's get the bad parts out of the way

*The Bad*

The storytelling is awful. The book is not intended to weave a masterful tale, so I'm not terribly disappointed. However, there came a point about halfway into the book that the writing became grating to read and was an obstacle to the subject matter.

There is virtually no character development, and what little development can be seen is either banal (Bill Palmers, toughened Marine, fighting back tears while telling about his bad father at a team building session) or bizarre (late devops adopter security-guy-John disappearing for weeks in a drunken haze without being fired, then suddenly reappears with a shaved head and GQ clothes and now he "gets it"). Neither dramatic occurrence helped move the story along, and in fact the sudden addition of drama looked garish standing in such obvious contrast to the rest of the vanilla story.

Adding to the lack of character development, is that each character reads like every other character. There were many times in the book when a character would be delivering two or three consecutive paragraphs of dialog and halfway through I would lose all notion of who was speaking. Was it Wes? Patty? Bill? John?

Each character is gruff, cold, worn out, and mildly bitter. I wanted to punch Erik, the supposedly sage-like purveyor of factory Zen, at about the book's halfway point. I wanted to lock him in his precious heat-treat oven by the end. I was genuinley surprised at some of the raw language. I don't flinch much at cursing, and certainly in the real world some meetings can have blue streaks pour out from under the doors. That's life. However, I found the sheer number of "goddamn"s and "s***"s distracting to the book, not an addition of realism. It seemed like it was trying too hard to be one of the cool kids, and as a result there are a not insignificant amount of people who will find that to be a distracting irritant to the core of the book.

The story is also a bit sing-songy at times with the usual tropes of total chaos being turned around. Skeptics are silenced. The tough guy shows his soft side. There is a self-seeking back stabber, and they get their comeuppance (sort of?). There's an irreverent hippy who sticks it to the man. Someone has a hidden special forces background. To complete the cycle, it just needed a dragon slain by a cowboy who gets the girl and rides off into the sunset singing a love song.

I think the storyline was unrealisticly biased in favor of the concepts. I do not think it is possible to have turned around such a large company as Parts Unlimited that was as deeply flawed in its operations, company structure, workflows, and personalities in the just over four months. I do not think it is realistic at all to have so many changed hearts and minds in so short a time. From years of bitterness, frustration and institutionalized failure to suddenly, in four months, most people "get it" well enough to be embracing, adopting, and successfully practising such drastic changes. Is it possible? Yes. Possible in that amount of time? No.

Keep in mind that the characters and storyline are mere vehicles to transport much larger concepts to the reader. It's an overgrown parable that has expanded a bit too large to comfortably carry such weighty topics on such a weak skeleton. You will gain the most if you can discard the storytelling and focus on the concepts.

*The Okay*

Fortunately the parts of the book that could truly be called "bad" aren't directly tied to what the book is actually about. The book is about how to get IT, from infrastructure to development, from management to security, to work closely together with eachother and the other business units while using workflow management methods that have been vetted on factory floors for generations.

What's merely "okay" is that the book doesn't do justice to the core concepts that it intends to teach. Seemingly every chapter introduces a new manufacturing term, plant management buzz phrase, or factory concept. From "takt time vs cycle time" to the difference between bill of goods and, I believe, "bill of resources." Oh, and during one dialog, the book refers to "single-minute exchange of die" as a legendary concept. Okay - I'll take their word for it. However, these concepts and terms are thrown at the reader in clusters that can be overwhelming. They are explained well enough to get you through that dialog and whet your appetite, however at times they are dropped unceremoniously into the reader's lap for them to stare at and search for the meaning.
Terms like "kanban", "katas", "The three ways" and references to Toyota's manufacturing prowess are woven throughout the book, however they are mere allusions and foreshadowing. However, the foreshadowing doesn't blossom into an actual in-depth explanation of any of them. Certainly those concepts and tools are large and themselves need many books to be fully developed, however I think a few pages of focused explanation should have been given to them. I still don't know what a "kata" is precisely and what "The Three Ways" are in any concrete way.

In spite of all the above, the book did excite an interest in these things. You instinctively understand that there are many large concepts that are being introduced, each of them mere tips to multiple icebergs. That conveys a sense of forgiveness to the lack of clear explanations for some factory terms and processes. Even the character Bill Palmer has to write down a few words and phrases for later review, which leads me to believe the authors knew what was happening with the flood of factory-think. However, it only works if you later unravel the knot you hand someone, and it's merely loosened by the book's end. The deeper concepts that inspired the book seem near to only one or two characters in the book, but kept at a distance from the reader.

*The Good*

I started this review with the negative so that I could end on a positive note. With all of the above said, you might think I hated the book. I didn't hate it. I didn't love it either. I liked it - and want to like it more than I do. I think it deserves a re-read once I take in some of the works that represent the larger body of knowledge that this books rests on.

For example, I'm planning on reading Dr. Eliyahu Goldratt's book, "The Goal: A Process Of Ongoing Improvement". I want to learn more about "The Toyota Way" and look into Jez Humble and David Farley's book "Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation." I'm interested in the concepts behind agile and lean manufacturing as applied to software development, but also on a larger scale of IT project delivery.

To be fair, I was gaining more and more interest in those concepts before this book, however The Phoenix Project wrapped up many of these concepts, and in conjunction with the the book's blog gave interesting backstory and history to them. As a result I think it does a good job of encapsulating very complex topics into a primer in the form of a fictional case study. I think the storytelling being as poor as it is does get in the way at times, but if you can ignore that, the book has a good chance at exciting you over the possibilities that an IT department has if monolithic thinking is let go in favor of a more holistic, business-centered approach.

One of the most fantastic elements to the book is that it isn't at all focused on the tactics involved. No specific technologies are talked about, no vendors, no task management styles, not ITIL. It seems that there was great effort spent to not mention any vendor for any reason. For a book over 300 pages long about IT, there are hardly any references to what they're using to deliver the services. It's mentioned briefly that one of the ops teams manages 1,000 Windows servers. Another time a reference is made to an Oracle database. That's about it. No specific mention of any vendor is made. No language, no hardware, no software. The closest thing to an endorsement is a few references to the various IT teams using open source tools to quickly create a solution, and that's about as specific as it gets. Literally, it's just about three sentences scattered around the book that basically say "the team used some open source tools to create a solution for..."
The Phoenix Project is about the strategic understanding of work. Not just IT work. Not just project management. Not operations. Not development. Just work. The concepts can be applied to any work wether it's making fences from driftwood on the shores of a Madagascar to the most complex operating environemnt in the most web 2.5 trendy-kewl devop shop you can imagine. It very wisely and deftly avoids any vendor bias.

It also avoids departmental bias. SysAdmins, security, development, management - they're not intentionally pitted against eachother. Bill, the protagonist, comes from an infrastructure background and his character has the typical negative mindset towards developers as being only in the business of crashing production systems and the security guys as only wanting to halt all projects with inane restrictions. The mindset is eye-rollingly stereotypical, however it shows each department's conversion to a belief in a larger concept that just their small team's goals. If any team got short shrift in the book, it was security, but I'm willing to admin that my understanding of how and why security was treated like it was is a bit foggy. I think there are larger concepts and business processes that I'm not familiar with that would explain what happened and why. (I won't spoil anything - read it for yourself and if you figure it out, let me know! =) )
On a more nuts-and-bolts level, the book is presented in a very clean fashion. There's no table of contents. There are no chapter titles save for having a date printed beneath the chapter number. There are 35 chapters spread across 338 pages making the story flow in small, manageable chunks. I like this format for this book since it makes less of an emphasis on story development and more on getting the reader to consume concepts in small bites. Had I not been multitasking so hard for a week, it could have been finished in two evenings. One Saturday if you've got nothing to do on the weekend.

*The Background and Foreground*

This book is apparently the first fruits of the digestion and practice of an enormous body of work and decades of combined life/work experience among the authors. Much of the material that this book is founded upon is listed in the IT Revolution Press blog post "Where to Learn More About Concepts In The Phoenix Project".

These four authors have worked together before with the book "The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps" and "Visible Ops Security: Achieving Common Security and IT Operations Objectives in 4 Practical Steps".

There is a second book on the horizon for IT Revolution Press called "The Devops Cookbook." In fact, there is a very transparent pitch for this book that is woven into the final pages of the story. (Side note: I found the setup for "The Devops Cookbook" to be the most gag inducing part of the book, but by the time I made it to the last few pages I had gained a startling ability to quickly suspend my distaste for the storytelling and take the bumbling attempts at using various literary devices out of the equation.)

I'm somewhat critical of devops on a broad scale. Or rather, what is sometimes passed off as devops (what is poked fun of by @DevopsBorat on Twitter). Devops itself is a nebulous term that is in its infancy and still has no strict definition, so anyone can call anything "devops" and be nearly as right as the next person. However with an author lineup like John Allspaw, Patrick Debois, Damon Edwards, Jes Humble, Gene Kim, Mike Orzen, and John Willis, you know this will be the real deal. Not "I know ruby, installed puppet and now know everything about network management" which is what much of "devops" appears to be these days.

It is interesting to note that while the book is, of course, fiction, it does have an interesting way of blending reality into the story here and there. Mostly to make mention of certain names and books like Rother, Ohno, "The Game" and references to Toyota in the 1950s. In chapter 30, the 2009 Velocity Conference where John Allspaw and Paul Hammond delivered their "Ten Deployments Per Day" talk is referenced and takes the focal point for a few chapters as characters are aghast at the thought of that many deployments.

*Final Words*

On the back of the book's dust jacket, Adrian Cockroft is quoted as saying the book is an "IT swamp draining manual for anyone who is neck deep in alligators." It isn't. It's an introduction course on wetland management written by a few brilliant professors that didn't earn stellar marks in literature class.

The book feels like someone has overturned a box full or Erector Set parts in front of you and provided a few wrenches and torn instructions. You have a great sense of potential at what you see laying before you. The instructions give opaque guidance on the ultimate value that could be created with them. But you know you need more resources to draw on and time to think in order to pull it together a high degree of skill and success.

(Note: Apparently the book had a name change from "When IT Failts" to "The Phoenix Project." This can be a bit confusing when researching the book itself. Even in the acknowledgements section at the end of the book, one of the authors refers to the book as "When IT fails." Thanks to whoever was the catalyst behind changing the title from what would have been one of the most ill conceived book titles in the history of publishing to something compelling and worthy of the book's awesome cover art. Thank you.)

If you can get past the story telling, and ignore the tropes and unrealistic outcome (or rather, the unrealistic timetable that the outcome developed over) then I think you can be fired up to probe deeper into this realm of plant management, katas, kanbans, and other means of managing projects. I think anyone looking to learn more about what IT can bring to a business, not just geeking out on fun technologies, this book will be a good tool to get your feet wet in some pretty large topics and give you a diving board into much deeper waters.
66 comments| 177 people found this helpful. Was this review helpful to you?YesNoReport abuse
on January 13, 2013
The Phoenix Project belongs to that rare category of books: a business novel. It's written as fiction but it teaches us something serious. The most well known book in this category is The Goal: A Process of Ongoing Improvement by Dr. Eliyahu M. Goldratt. The Goal is a long-term best selling business book and required reading for nearly every MBA student for the last twenty-five years.

What The Goal did for lean manufacturing, The Phoenix Project will do for managing IT.

Bill Palmer is the reluctant protagonist who is thrust into managing IT Operations. He inherits a world of hurt: new business innovation projects are so far behind that the corporation's ability to remain competitive is threatened; standard business functions like payroll, data storage, and point of sale systems suffer from recurrent outages like lights flickering during a storm; and the whole IT organization is so buried firefighting that critical maintenance is neglected.

I immediately resonated with the situation. In fact, if you work in a business of any size, in IT or not, you'll quickly find similarities.

In my day job, over the years I've found myself wondering why small startups can outcompete two hundred person strong development teams, why certain deployments are multi-day affairs that nearly always fail, why we must wait months for to release software, why the releases that do get to the light of day are nearly always missing key features, and why we seem incapable of fixing bugs so awful that we drive our customers away.

In The Phoenix Project, the protagonist Bill Palmer encounters all of this and more. It's written as a fast-paced business thriller (I couldn't put it down and spent much of Christmas day hiding from my kids to read -- in fact, once I hit the halfway point, I literally did not stop reading it except for bathroom breaks.) But it's also a serious business book about managing IT.

Through an enigmatic board member, Bill is forced to question his assumptions about IT. What is the role of IT Operations, and even all of IT? What are the four kinds of work that IT must do? What's the silent killer of all planned work? What does the business need?

Through comparisons with how work is managed in a factory and examples from The Goal, authors Gene Kim, Kevin Behr, and George Spafford show how the time tested techniques of lean manufacturing (also the Toyota Production System) apply to IT work. By applying these principles, Bill Palmer is able to:
- Speed up the time it takes from implementation to deployment by reducing work in progress
- Increase the amount of useful work completed by reducing dependencies on key resource bottlenecks, whether those are people, hardware, or systems
- Reduce outages by addressing technical debt on fragile IT systems (such as old databases, tricky routers, etc.)
- Increase the IT contribution to the business by gaining a better understand of the business requirements, and focusing effort on those features that make the largest beneficial impact to the business.

One of the authors, Gene Kim, is the original creator of Tripwire, a widely used tool for managing IT changes; cofounder of the company by the same name; and author of The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps. I've seen him give talks on these concepts to a packed audience and receive a standing ovation.

For years, I've wanted to be able to bring these types of ideas back to my company because I'm convinced we could be ten or a hundred times more effective and delight our customers if only we could overcome our IT dysfunctions.

I'm thrilled to see them now in written form. If there was one book I'd want every employee of my company to read, it would be this one.
0Comment| 10 people found this helpful. Was this review helpful to you?YesNoReport abuse
on January 11, 2013
I was lucky enough to receive an early copy of "The Phoenix Project" from Gene.

Initially I was surprised to find myself reading about DevOps and IT systems management in novel format. By the end of the book the genius of using story telling and "specification by example" had hit me.

What Gene, Kevin and George have achieved here is significant. They are educating readers on a huge range of complex topics - IT Service Management, Lean, Systems Thinking, Business and IT Operations, Agile, The Toyota Way - and have done so by providing a real world example in a fictional novel.

But, of course none of this is fiction. If you work in IT Operations, Development or as a business leader you will immediately identify with one of the main characters in this book. Are you a Bill or a Steve. Possibly you are a Brent.

You will then read about these characters facing the same struggles that you do with your organisation. IT is too slow, IT is impacting the business, Developers don't care about operational issues. Business leaders want change and feel held to ransom.

I honestly believe that this novel will be a turning point for anyone that picks it up. We will probably look back in years to come and point to this novel where thousands of people "got it" and started to turn their IT organisations into something very different.
0Comment| 14 people found this helpful. Was this review helpful to you?YesNoReport abuse
on March 3, 2015
I wanted to like this book. However, what I found were oversimplifications, generalizations and stereotypes. The Phoenix Project is a blatant rip-off of The Goal by Eliyahu Goldratt. To be fair, The Phoenix Project does directly reference Goldratt's work, and the storyline and characters follow The Goal exactly. The only difference is manufacturing vs. technology. The characters even map: Herbie => Brent; Jonah => Erik; Alex => Bill; Lou=>Dick; Julie=>Paige. Overall, a big disappointment.
0Comment| 4 people found this helpful. Was this review helpful to you?YesNoReport abuse
on January 14, 2013
I had the pleasure of meeting Gene Kim in October of 2011 at the Security B-Sides conference in Portland, OR. He had just presented on the concept for his novel, and I was immediately intrigued. It seemed like he intended to bring the concept of the business parable to IT management. I joked it looked like a Who Moved My Cheese? for the ITIL crowd.

In speaking with Gene following his presentation, I thanked him in person for The Visible Ops Handbook: Implementing ITIL in 4 Practical and Auditable Steps (which I maintain is still the best $20 I ever spent). Through our conversation, he flagged me as the type of "boundary spanner" who would benefit from a more thorough reading of his new effort, and he nailed that assessment. I didn't want to put it down. The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win reads like a techo-thriller. I found it very engaging and definitely wanted to read the whole thing all in one sprint. I hadn't found myself that thoroughly engrossed in a read in quite some time.

The cast is spot-on. Each is clearly meant to represent a specific organizational perspective or archetype. If you aren't one of these characters, you at least know someone who is. A few may seem a little exaggerated or caricatured, but that is more from a sense of literary license and less in any manner to offend. The roles are readily identifiable and it is easy to see oneself as any member of the cast. If this causes the reader any discomfort, one should perhaps take the hint.

As I joined Bill Palmer, the story's main protagonist, on his odyssey as he deals with "late projects, chronic outages, massive audit findings and the imminent threat of outsourcing" and - having lived that adventure myself - I thought, "Been there. Done that." It is well known that projects, and corresponding confidence in IT, fail in predictable and repeatable ways. So, it is both disheartening and reassuring to see us doing things so perfectly wrong. Even more important is the illumination of a clear path out of that death spiral of angst and despair.

Also of considerable use is the extensive bibliography of business literature from which Gene & co. have drawn. The reader is introduced to key concepts, from the Theory of Constraints outlined in Eli Goldratt's parable, The Goal: A Process of Ongoing Improvement, to the agile management techniques of David J. Anderson's Kanban and the leadership and team-building dynamics found in Patrick Lencioni's The Five Dysfunctions of a Team: A Leadership Fable without being hit over the head. The story informs, educates and provides a jumping-off point for those seeking additional knowledge in the fields of Lean IT and Agile Management.

I believe The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win is already sold to my colleagues working in or managing IT operations. It will also be of interest to those IT professionals who are inclined to think outside of their silos and concern themselves with bigger picture issues relevant to the entire business. I see this becoming mandatory reading for executive staff and other enterprise stakeholders being enabled or constrained by their own IT processes. I will certainly attempt to influence that outcome in my own organization.
0Comment| 31 people found this helpful. Was this review helpful to you?YesNoReport abuse
on January 20, 2016
Interesting way to run an it and dev team. Book was however vague in how things actually worked and of course nothing ever failed to work perfectly under the new business model.

Also side nit pick, main character is a Marine, yet he refers to protecting his soldiers at one point in the book. Docked a star for that. If you're going to ram his military past down my throat at least get it right.
0Comment| 3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on April 15, 2013
I can't say enough good things about this book. If you have been struggling with articulating the problems endemic in many large organizations with how business processes around IT and Software Development are broken, this is your book. Not only is it educational, it is fun to read. The authors do a great job building a set of characters and business problems that are realistic and that many in our industry can relate to. If all you get from this book is an understanding of how queued work and wait-times in highly variable systems behave it will be well worth it. This understanding alone can completely change how managers and executives book resources and arrange workers to accomplish business goals. IT work is physically invisible and this makes it deadly to ignore the real physics involved. Phoenix walks you and the characters through some surprising discoveries and illustrates some solutions to the IT bottleneck. Readers from IT and software will identify with the scenarios, people and dysfunctions explored.

I have been gifting copies to co-workers. It is the best $10 gift that will have an astronomical payback. This book will help lead a revolution around Lean Thinking, Continuous Delivery and simply getting more out of software and the valuable resources that build our systems that are running the world.
0Comment| 5 people found this helpful. Was this review helpful to you?YesNoReport abuse
on February 21, 2013
Many "management" books come and go but this one is different. Written as a "novel" instead of a "guide" this is a genuinely interesting story of a fictional company and their path from typical IT madness to success. Along the way you learn about having IT Security (my particular field) become part of the SOLUTION instead of part of the perceived problem.

I've read (or been forced to read) many a "flavor of the month" management guides, both IT specific and general business oriented, but this one hit home. If you don't see you own situations in at least one, if not several of the sub-plots in this book, you haven't been in the business long enough. The fantastic thing is their business model for selling this book is to release the entire first half as a free PDF. Within 30 minutes of starting it I was off to Amazon to purchase and load up the E-Book.
0Comment| 3 people found this helpful. Was this review helpful to you?YesNoReport abuse
on June 24, 2013
I found this too preachy to really be good to read. It presents itself almost as a case study, but comes off very contrived and unrealistic in terms of people's reactions. Characters remind me Atlas Shrugged character archetypes.
0Comment| 8 people found this helpful. Was this review helpful to you?YesNoReport abuse