Please let us not impune he rich culture of the noble bro.
Any CTO who prefers a packaged methodology over doing some homework andtailoring technology/process to the specifics of their business, is aCTO to be avoided. (And boy, if you hear your CTO talk about "totalquality management" or "six sigma" - that's the time to run for thedoor. c.f. Dilbert for references to "stink like a dead weasel").
Hi Ernest,
obviously! not that all improvements are 'devops' issues. That would be stretching it too far indeed.
The reasoning was more that when we try to optimize your 'dev & ops' problem,
the bottleneck for improving it may well be outside dev & ops.
So you have to have a broad view, otherwise you're still trying to solve some problems with a narrow view.
While reasoning on the stories for the book , it made me think about the things happening in other parts of the company that have an influence on the dev and ops tension.
- hiring/HR policy can have it's effect on the devops tension , what kind of persons fit well in this problem
- financial incentive of each groups can have have an impact on the problem
I've seen the same thing happen with agile teams trying to solve 'devops problems' within the dev team only.
Makes sense?
On 23/05/12 14:09, Ernest Mueller wrote:Well, but Agile hasn't dropped the ball - it's just that it's just now getting around to us. When you look at the actual big picture there's a lot to it. The Agile Austin group, for example, has SIGs on agile dev, agile QA, agile architecture, agile product development, agile UX, agile leadership... And now DevOps. Just because now we're down with the concepts that are new and shiny to us doesn't mean we now know how to fix all the other parts of an organization.Going and looking at the first diagram in Patrick's article - no, optimizing the relationship between HR and Sales is not "DevOps." That's ridiculous. It's overreaching IMO just like my security example. DevOps isn't just chef and puppet, or just about deployment, but I think its focus is realistically on the part where ops is actually embedding into the rest of the organization instead of being a segmented sideshow and optimizing the process of actually delivering services. Yes, dev and ops represent the "two sides of the technology house" - and I think Ops can properly be understood to rep Net and Sec and all that as we move forward - but the scope is not "everything in an organization all the way to HR and Finance." Ops is waking up and smelling the coffee here, not inventing coffee. The expansion dilutes the usefulness of the focus. DevOps isn't lean/agile/OM but better. It's an application of those principles to a product team creating and delivering software.The next DevOps Areas part I think is great. It's the initial "well DevOps is everything!" thing that sounds like consulting gig scope creep to me.ErnestAt 10:27 PM 5/22/2012, damone...@gmail.com wrote:I see your point about being careful of DevOps being heralded as a panacea for all ills. But DevOps isolated to just the point of contact between Dev and Ops isn't the answer either.
You could say the macro perspective is "Lean" in it's purest form, but DevOps has as much claim to it in the technology realm as Agile does. The only proof I need that "big picture" isn't properly represented by Agile is that the Agile movement has been around for a long time (in "tech years") yet completely missed the big picture that you needed the align and optimize the entire development to operations delivery cycle to properly implement Lean in a software as a service world. Sure you can reference a handful of sharp folks who have been saying this all along… but the vast majority of the thought, effort, dollars, and time that has gone into Agile has resulted in a prescriptive methodology for software development that starts with requirements and ends with "code complete". I'm sure the purists will cringe at this and the manifesto will roll over in it's grave… but that is where that movement has gone. It's become a local optimization that doesn't address the "global" concern of the development to operations delivery cycle (i.e. what the business actually cares about and pays for)Now on to DevOps… Are we not doomed to repeat the same mistake if we don't take the all inclusive holistic approach? The whole point of having a "dev" and an "ops" is to take business ideas and manifest them as running features for customers. What's the point of the "focus on the relationship between dev and ops at the product level" if it doesn't optimize the whole system to achieve it's purpose? In order to optimize that relationship for that purpose you have to include all the pieces that must come together to make that happen. That doesn't mean that everyone has to be a generalist in everything (your example of conflating security and availability), but it does mean that everyone has to understand the system they are a part of and how to work together to fulfill the purpose of the system.
When the original DevOps conversation started, it was taking a broad system-wide view. The two seminal events both talked about Dev and Ops as if they were the entire technology house split into two sides. Paul Hammond (Dev) and John Allspaw (Ops) represented the entire Flickr technology team (at least figuratively if not literally). The first DevOps Days in Ghent was framed as bringing together the two self-identifications that rarely gather at the same conference, Dev and Ops.Post DevOps Days Ghent the conversation definitely became deployment centric. Why? Because deployment is the canary in the coal mine for a broken development to operations lifecycle. It's the flash point where the pain is felt, but the root cause of that pain comes from somewhere else.
Now that I'm 5 paragraphs into a rant… :)
I've always thought DevOps extends into the business more broadly (than narrowly Dev+Ops) because neither Dev nor Ops are the app owner or the customer.
Dev may build the features and functionality of the app, and fundamentally manages the cadence of those changes delivered to Ops for controlled exposure to the world, but inside the business there’s an app owner who studies the customer and fundamentally drives the app’s existence from infancy to grave. And that’s where I think DevOps discussion expands well into the organization via that loop from App Owner / customer back around into Dev and Ops.
The next DevOps Areas part I think isgreat. It's the initial "well DevOps iseverything!" thing that sounds like consulting gig scope creep to me.
I'm one of these people doing agile for a long time and interested in DevOps thanks to the personal evangelisation of Patrick.2012/5/23 Spike Morelli <f...@spikelab.org>
I admit to be ignorant when it comes to agile so I'm asking this list: how does agile position itself compared to devops? in my ignorance and exposure as a sysadmin or even a manager, agile has always been a dev thing. I know it's not, but that's been my experience on the ground. year after year. company after company. But if agile is finally coming around and there's more to it like Ernest mentioned (just recently I discovered the Agile Management book, been meaning to read that since then), how does that intersect with devops?And maybe I'm pushing the meaning of devops, but, like many ppl on this list, I didn't need that term to tell me that config management was good. However I did need that term to remind me that collaboration was good. Agile did not do that for me, devops did.
for that, I think the best way is too look at the agile manifesto.>We are uncovering better ways of developing software by doing it and helping others do it.
>Through this work we have come to value:>Individuals and interactions over processes and tools>Working software over comprehensive documentation>Customer collaboration over contract negotiation>Responding to change over following a plan>That is, while there is value in the items on the right, we value the items on the left more.For me, nothing in this says that it's just about development team.yes, it's true that in the beginning ops were ignored by agile.I see 2 reasons for thatA) the people who created the manifesto, were developersB) a lot was happening in smaller companies, and hus they did all the deployment themselves.I'm sure you can all find lots of other reasons.for me they don't matterDevOps, just as agile is about the mostly mindset, just as lean is and BeyondBudgetting(I think this discussion proves it)
Like Ranjib said, tools are useful and so is terminology, a couple FOSDEMs ago I argued that the shift of operations toward dev tools and practices represented a step toward a common story that would in turn help with the dialogue. What I really got out of devops however is the 'break down the silos' message. It was the thing that opened the doors to Lean, of which I'd also like to better understand the role of in this discussion.Break down the silos, communicate better, be transparent, eliminate waste, deliver value. That's what I care about. And it can be done everywhere. In HR, in finance, in prod dev. Is that devops? probably not. Is that Agile? not sure. Is that lean? in part. Do we need even something for that? possibly not.
yes, let's now not create silo's between agile, DevOps, lean etc...
am I going mad? possibly yes :)
;-)nothing wrong with being mad. It's the world that can't deal with people behaving different then the main stream
VeriSM https://verism.global/
BeingFirst https://beingfirst.com/
Taming Change https://www.tamingchange.com/
Team Topologies https://teamtopologies.com/
Customer Expectation Management Method http://tschurter.com/wp-content/uploads/2018/10/Customer-Expectation-Management-Revised-e1538575324591.png
Nicols WP https://www.nickols.us/difficult.pdf
Value Stream Mapping: How to Visualize Work and Align Leadership for Organizational Transformation https://www.amazon.com/Value-Stream-Mapping-Organizational-Transformation/dp/0071828915/ref=sr_1_3?gclid=CjwKCAiAis3vBRBdEiwAHXB29G0behX5zj11Xl0xCxQvg8wAFZ3QigWAtjP14HEfyGcB72VM03jvqhoCNGIQAvD_BwE&hvadid=323590030477&hvdev=c&hvlocphy=9003712&hvnetw=g&hvpos=1t1&hvqmt=b&hvrand=12095849842679789977&hvtargid=aud-840076997981%3Akwd-746770535&hydadcr=24407_11048948&keywords=value+stream+mapping+book&qid=1576271981&sr=8-3
ISO/IEC 33020:2019 Information technology — Process assessment — Process measurement framework for assessment of process capability https://www.iso.org/standard/78526.html
THE OPEN GROUP IT4IT™ REFERENCE ARCHITECTURE, VERSION 2.1 https://publications.opengroup.org/standards/it4it/c171
Fugle Innovation Model https://www.researchgate.net/figure/The-Fugle-innovation-model_fig1_290440787
eG Innovations https://www.eginnovations.com/it-monitoring/whats-new
Hello,
For your information :
http://java.dzone.com/articles/codifying-devops
Best Regards,
Guillaume FORTAINE