Reddit reviews The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
We found 11 Reddit comments about The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win. Here are the top ones, ranked by their Reddit score.
I would be very cautious before you start this. You need to have a much better understanding of why you’re doing this before you start. I think breaking up ops teams may be an answer to a different question. That question should be: “how do I deliver better business value?”
The first step is to understand what you’re trying to achieve. Gene Kim, Patric Debois et al talk about the “three ways”. It’s essentially three steps towards embracing devops culture.
The first is all about increasing flow through the system - that system being your organisation. The idea is to look at how your organisation goes from a business need to realising business value. For instance, how do we go from wanting to provide another payment option on a website, to customers being able to use it?
One way of analysing and visualising your organisation as system is something called “value stream mapping”. This looks at how a piece of work gets requirements, gets developed and how it gets to customers (even if that’s internal customers). You need to understand the process, where the delays are, where teams hand off from one to another, where things go wrong. Ideally you want to optimise this process. One of the issues that many organisations look at just automation and essentially automate a slow and inherently crap process. This will never give the returns that many people are after. Looking at this level, you should be looking at organisation goals. How do you measure this work in a frame that other people are going to understand who are not IT? Is it how fast you can get a feature to market? Increasing individual spend? Increasing reliability of the service you provide to customers? If you’re not framing this initiative in those terms, then it’s doomed to failure. Be specific and measurable.
Once you understand your process, you can look at opportunities to optimise the feedback loops (the second way). It might be that infrastructure is required by dev teams that gets delivered by ops but isn’t what they need. There is a team hand-off here that needs to be addressed. There are many solutions to this problem, but it might be a start to move where the person provisioning that infrastructure sits. Put them in the dev team. You might still keep them as part of the ops team logically to start out with. The point is, you’re looking at the system, understanding the constraints and trying to optimise pain points.
You can achieve a lot without adding any new automation or technology solutions and this shouldn’t be underestimated, but ultimately, handcrafting systems isn’t repeatable or fast enough. This is where reorganising teams might look sensible, but you should know what outcomes you are string to achieve. That might be difficulties provisioning infrastructure fast or flexibly enough, it might be deployment of code to live being too slow, it might be that testing is too slow. Once you know you need improve, you can look at tooling to better achieve that.
/u/quailtop mentions:
>In my (admittedly limited) experience, you can solve needing faster development velocity (the first problem) through staffing a new team whose job it is to help improve the deploy, test and release process for all developer teams. Their job is necessarily cross-cutting across all dev teams. They would develop internal tooling e.g. a standardised build/release process that all teams can employ. This is a great pattern because it avoids encroaching on existing territory and is a very clear contract between engineering.
This is otherwise known as the DevOps “hub and spoke model” and is what my organisation has implemented. It’s worked very well for us and it’s a clever way to start a reorg.
For certain ops teams, you may want to keep them together. For example, you may have a large and complicated network setup and still need a dedicated networks team. My focus then, would be putting an obligation on those teams to allow others to better consume their services. They may need to add other people to this team to make that happen. For example, if you have a complicated network, with lots of steps, look at both automation of those steps but also to allow other teams to more effectively consume them. Amazon spent a lot of effort building the culture that ever system or service is an API that should be able to be consumed easily internally (have a read here: https://apievangelist.com/2012/01/12/the-secret-to-amazons-success-internal-apis/ . So, for this case, you may add a tech lead and some software engineers to build network APIs rather than splitting the team up. This may include some of your more traditional network admins to look at replacing on prem infrastructure to support this. The goal however, should always be about the organisation level goal. Improving the speed at which you can reliably deploy network changes should be in support of one of those strategic objectives.
The third way then focuses more on continual learning and experimentation. You should have embedded a set of objectives that you’re working on achieving but you’ll have lots of legacy systems, legacy processes and behaviours. Focusing on outcomes and consistent asking of “why?” will start to help. This is also where SRE becomes really relevant for me. IMO SRE isn’t something that is particularly useful to start out with. It’s best when you’re looking at elevating and existing DevOps culture to a new level. This will look more at observability of a systems and understanding where the more difficult optimisations can be done.
Let me be clear. DevOps is a long road for any organisation to change to. To really get mature it will take many, many years to properly bed in. My organisation started around 5 years ago and we still have more progress to make. One of which is to move from project based way of organising work to more long lived product teams. This organisational change is probably the biggest thing holding us back right now, and has nothing to do with automation or technical practices.
I wouldn’t start out by reading about SRE, I would start with a book called The Phoenix Project and then read The DevOps Handbook, at least twice. Start with the strategy before you make any changes. I would also look to see if you have a cloud strategy because many of these practices are much harder to implement purely on premise.
​
Edit: Thanks for the silver!
Edit2: One thing that's also worth noting is that for many people, moving from traditional sysadmin to DevOps is a hugely scary change. It means that many of the staff won't have the job security they thought they had and they need crucial skills they don't have. To make this work, understand this point of view and support them. This requires really mature and experienced leadership at all levels. This is a good, short and free ebook to help the more traditional sysadmins understand why they have to change.
u/the_jixxx - sounds like a classic case of a good developer throwing shit over the wall and unintentionally not being a team plater. I'd suggest reading this book as it describes EXACTLY the situation you are describing: https://www.amazon.com/Phoenix-Project-DevOps-Helping-Business/dp/1942788290
Your team/company will likely see a big benefit by moving to a more devops-style model of software development. Hope it helps you begin your journey
I think you're looking for a book called "The Phoenix Project". It is based on The Goal but focuses on visualizing the IT value chain in a company as if it were a factory floor. It also gives a solid understanding of the role of DevOps in companies.
https://www.amazon.com/gp/product/1942788290/ref=dbs_a_def_rwt_bibl_vppi_i0
> What is DevOps? Developer operations? What does does Dev ops imply?
What you are asking is a HUGE and complicated question.
DevOps is a dramatic change to the way the business operations unit and their technology teams interact to create technology solutions to support business projects.
Yes, DevOps involves a lot of software development skills. But it can also require technology infrastructure skills, and it DEMANDS the involvement of the business unit.
DevOps can be a real and very serious game-changer if a company is willing to invest in it.
It is growing steadily throughout the industry. Not explosive growth. Not leaps & bounds. But steady growth.
I STRONGLY encourage you to invest $15 into this book, and spend 6 hours plowing through it. (I read it in about 4 hours)
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win
This is not a reference book. You will not search through it to jog your memory about how to do something.
But you very well might loan it to a bunch of people so they can learn from it too.
So, spending the extra money on the hardcover edition wouldn't be a terrible idea, but any edition is fine.
YOU need to read it once, and develop an understanding of the almost philosophical concepts. Then you're pretty much done with the book.
If your local library has it, that's even better.
This might also help:
https://en.wikipedia.org/wiki/DevOps
It's really what works for you, this is the fundamental point of Agile which often gets lost, so if it's working for you that's perfect.
For our teams LEAN makes far more sense. As an example, Kanban replaces velocity with constraints. It makes it immediately obvious which parts of the process are bottlenecks.
Our priorities are set by the business on an available slot basis. We might be able to simultaneously work on three features. If three features are in flight there's zero capacity. The business can pause or abandon a feature, but they have to agree this by quorum (or dictatorially, hierarchy still exists :) ). Once a feature is complete a slot is available and the business can vote on what feature they want next.
So a feature takes as long as a feature takes. We still estimate, but there's no arbitrary sprint boundary to estimate around. We still subdivide tasks as an aid to estimation but again, not to fit in a sprint boundary.
We do stand ups (standing optional) in the morning, still meet as a team, but there's no need for a retrospective. If we are constrained by unanticipated volumes of support, or the task requires input from the business, the task sits in that column so we can see each day that support needs addressing or that someone needs chasing.
There's no formal backlog, the business set their priorities. This doesn't mean the team lead can't meet with the business, discuss future requirements and liaise with the team for informal estimates, complexities, etc. It sounds kind of chaotic but it works across many teams, although interestingly we still use scrum for the sort of transformational, multiyear multi team coordination.
If you're interested in taking a look at this, even if it's just to compare and contrast, take a look at this book. It covers pretty much all the above and a bunch of dev oppsy stuff in novel form. It's not dumbed down, and it is number 1 in its category.
First, read our Wiki. It is very thorough and answers a lot of these common questions such as
day to day? The Practice of System and Network Administration
And the topical reference books listed below.
Books to help in shaping a sysadmin? The above &:
The Phoenix Project
Time Management for System Administrators
Topical Books I see mentioned often and have been very helpful to me:
Powershell in a month of lunches
Learn Python the hard way
Unix and Linux System Administration Handbook
Windows Server 2016: Inside Out
Group Policy
AbsoluteBSD
FreeBSD mastery:ZFS
CCNA
RHCSA/RHCE
Pro Puppet
SSH Mastery
On my docket:
FreeBSD Mastery: Advanced ZFS
Michael W. Lucas and Thomas Limoncelli are very good sysadmin writers, you can't go wrong with a topic they have chosen to write about.
Most of the *nix stuff assumes a baseline knowledge of how to use a unix-based system. I learned as I went but did pick up an old copy of Unix Visual Quickstart Guide not too long ago at a used books sale, which seems like a good starting place for someone overwhelmed with sitting at a terminal and being productive.
I notice I don't have any Virtualization books, perhaps someone else can fill in good books. Most of my knowledge regarding virtualization and network storage has been a mix of official docs, video training, and poking at it. Seems innate but it isn't.
Hello,
From my experience, the tool selected for a project will always become the wrong choice after a certain period of time. It is never obvious which tool is the best at the beginning of a project. An experimented team will more likely make reasonable choices but they should always keep in mind that the tool they use will be replaced at some points or modified. That's why architecture and good coding practice are the cornerstones of a project able to withstand evolution.
I had to work, one day, on the transition from SQL to MongoDB. There is no magic, all the code calling the SQL data source had to be rewritten. It is a costly process but the final cost of the operation mainly depends on how well the calls to the database are isolated from the rest of the software.
Sadly, I don't have any tools for handling this specific case. But I can recommend those books :
Some of these are directly related to programming and some are not but are additional reading that touch on skills that most every programmer should have some concept or idea of.
I've read all of these at some point throughout my career and can attest to their usefulness. Here's my personal list:
There is a wonderful book about process improvement from about 35 years ago called The Goal by Eli Goldwater that is written as a novel. Wonderful book - terrible novel: The Goal: A Process of Ongoing Improvement https://www.amazon.com/dp/0884271951/ref=cm_sw_r_cp_tai_AS.vDb6F2QH3T
And The Phoenix Project - on DevOps is an homage to The Goal and is also a novel: The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win https://www.amazon.com/dp/1942788290/ref=cm_sw_r_cp_tai_9Y.vDb2981BYS
Also an amazing book and a terrible novel. Both of these are great examples of the power of different learning styles. The novel format accommodates Socratic Learning (questioning) and is just a terrific way to teach what would otherwise be very dry subjects. Humans are wired for storytelling and these books are exemplars of that.
They should have read "The Phoenix project" book
https://www.amazon.ca/Phoenix-Project-DevOps-Helping-Business/dp/1942788290?th=1&psc=1&source=googleshopping&locale=en-CA&tag=googcana-20&ref=pd_sl_36pzhuhqz5_e
You should definitely read this book: The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win.
It's very fun to read and talks about a business transformation with DevOps / Agile.
The questions you ask are answered in the book.
​
Cheers, Johan