Hot off the heels of reading The Phoenix Project, I'd contend that there
are still inefficiencies inherent in this model. I'm still nowhere near
Allspaw levels of DevOps enlightenment, but I'm coming from a
perspective somewhere between doing a lot of reading (like the author of
this blog) and running a very successful team of ninjas that has really
fundamentally changed the way we think of operations.

After reading The Phoenix Project, I'm still hearing in my head "elevate
your constraints", "think like a plant manager", etc. I'm still
digesting it all, comparing notes, incorporating what I've learned into
my world view of DevOps. And I'm learning that my team wasn't bringing
value early enough in the process. Nor was work flowing as effectively
through my team as it could be. I'm doing some work now experimentally
combining work centers, and to some good effect. I'm rather low on the
totem pole so I'm somewhat constrained ("elevate!")in how I can utilize
the resources of other teams, but my team has earned some credibility
across the organization and it seems other teams are increasingly
willing to take risk to realize a better way of doing business.

Dev + Ops is indeed DevOps Lite, or Diet DevOps, however you'd prefer to
look at it. The name is actually pretty unfortunate. Agile++ may have
been more apropos. How do you apply Agile values and methodologies to
the whole business, not just the development business unit? Part of the
answer lies in Operations Management theory (Taichi Ohno, Eli Goldratt,
W. Edwards Deming, etc).  The name DevOps has actually made it harder
for me to sell at work, because it is already so horribly misunderstood
by upper management thanks to opportunistic marketing folks trying to
sell products with a DevOps name on it.

Once you can see your business like a factory, it's rather like being
rudely awakened from the Matrix. Suddenly these mid 20th century
manufacturing models fit in 21st century software development. This is
where you start looking beyond Dev + Ops and considering the other
constraints on "optimizing the whole".

I'm rather wrapped up right now in putting together a one hour intro
presentation right now with the target audience being my colleagues at
work (to be delivered next week at a big internal tech conference) and
however many levels of management above me are supposed to be flying in
from the main office for this conference (no pressure!). I do intend to
package it in such a way that I could pretty easily deliver it as an
"Intro to DevOps" for this group and some of the other local tech groups
if there is interest.

-M

On 02/06/[masked]:06 AM, Mark Mzyk wrote:
> I sent out the question a long while back to this mailing list asking
> what DevOps was. There was some discussion around the idea, but I don't
> know that we ever came to any kind of agreement as a group (nor do I
> actually expect we ever will). I thought I'd bring up the idea again in
> light of this post:
> 
> https://www.graham...­
> 
> 
> I came across it the other day and though it did a good job distilling
> down what DevOps is.
> 
> My question to the group: what from that post strikes you? Any really
> important quotes there? Anything you disagree with or would change?
> 
> - Mark
> 
> 
> 
> -- 
> Please Note: If you hit "REPLY", your message will be sent to everyone
> on this mailing list ([address removed])
> https://www.meetup...­
> This message was sent by Mark Mzyk ([address removed]) from Triangle DevOps.
> To learn more about Mark Mzyk, visit his/her member profile:
> https://www.meetup...­
> Set my mailing list to email me
> 
> As they are sent
> https://www.meetup...­
> 
> In one daily email
> https://www.meetup...­
> 
> Don't send me mailing list messages
> https://www.meetup...­
> Meetup, POB 4668 #37895 NY NY USA 10163 | [address removed]
>