3 of 4 people found the following review helpful
Curate's egg: good in parts but missed many things,
Amazon Verified Purchase(What is this?)
This review is from: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win (Kindle Edition)
Bill can't remember how to spell his wife's name (Mostly "Paige", sometimes "Page").
He is so out-of-touch at the start he has no inkling that there is a BAU problem.
By page 100 he still doesn't realise he needs Portfolio Management and major redocumentation.
I like the way the motormouth marketing woman is set up as all-purpose Bad Girl. I'm sure we all know people like her.
The fact we know in advance that his moronic boss is slated for the chop is a great relief.
Testing is mentioned 21 times, coverage once and then only in relation to code. Feature coverage doesn't get mentioned despite being one way in which release readiness is assessed. There is no mention of any attempt to assess the readiness of any release. On page 278 we learn that "it took three hours to get the Phoenix project into the test environment and get all the tests to pass". This is evidence that none of the authors is a test manager or has ever worked closely with one.
There is no mention of any project plan or test process for the Phoenix project. Bill evidently doesn't see fit to call these out. Critically he has made no attempt to monitor the Phoenix defects.
By chapter 15 he's managed to distinguish between 4 kinds of inputs and has realised he has a resource contention problem.
Steve's alleged realisation of his errors is wholly unconvincing: if he could understand that well he'd have had far more self doubt and he would never have goofed as badly as he did.
By chapter 19 the characters accept that there is a resourcing issue. We still have no mention of impact analysis (but it might be coming).
There are mentions of technical debt but no reference to what it is or means.
The thinking shown on p 225 (chapter 22) is exactly what was missing in the DevOps occasions I have met. There is a glib reference to checklists. Writing checklists and keeping them current is a major task in itself.
There is no mention of the need to be able to handover a project to Operations and what this requires. 229 pages in and there is no mention of requirements specifications (they don't occur in the book). There is a reference to "... the need to understand the true business context that IT resides in" on page 251. Rather than get that right the authors worry about COSO cubes and KPIs without ever being sure that the requirements are aligned to the business. Nor is there any parallel drawn between keeping the documentation correct and oil changes (page 253). Business analysis? Process models (only in relation to SOX on page 269)? Business cases? What are they? By page 266 they start (effectively) writing partial outline requirements without ever looking to see if they already exist or trying to find out if not, why not.
Overall I don't think the symptoms listed are likely to be resolved by the proposed cures such that we can be sure that they won't recur.