|
A few weeks ago I held a meetup about DevOps.
Instead of giving a presentation, I stimulated a debate with the audience present, presenting several hypotheses to discuss and possibly refute.
?
Very provocatively, my hypothesis was that DevOps did not invent anything new :D
?
To summarize a lot, I believe DevOps rode the wave of the emerging cloud universe, bringing attention to a whole set of practices and tools that cannot be ignored today. Those who manage complex infrastructures can no longer afford to do it by hand, in many cases to date it is simply impossible to do so.
?
That said, I continue to believe that DevOps has "simply" taken up (and brought back into fashion) concepts from Lean, the Manifesto for Agile Software Development, and eXtreme of Programming of course.?
?
I come to the point, which is then the title of this post :)
?
What were Operations like in the days of the C3 Project?
I get the impression that XP was very little concerned with Operations, and I am curious to understand why:?
- Were Development and Operations worlds totally separate?
- Was it not of "strategic" interest?
- ?Wasn't Operations simply an issue at the time?
Or am I simply missing something?
?
I am curious to have the opinion and listen to the stories from the pioneers listening :)
?
Thank you!?
Ferdinando
|
Well ...
What were Operations like in the days of the C3 Project?
I get the impression that XP was very little concerned with Operations, and I am curious to understand why:? - Were Development and Operations worlds totally separate?
- Was it not of "strategic" interest?
- ?Wasn't Operations simply an issue at the time?
A key principle of XP was the “on site customer”, similar to Scrum “product owner”, who has the difficult job of deciding what to work on. The team might advise on what to do, but their job is to do what is asked for.
Perhaps the biggest mistake that the C3 effort made was that the payroll operations people had some I’m portent needs, and the “on site customer” was not prioritizing their needs. I think they didn’t like each other, but whatever the reason, we didn’t prioritize some key operational needs and thus the C3 project made an important “enemy” in the operations manager.
Arguably the big mistake was imagining that one person can stand in for all the stakeholders and decide what to do without error. I am not sure what a better way would be, but that way is at best very difficult and sometimes impossible.
Ron Jeffries
Everything that needs to be said has already been said. But since no one was listening, everything must be said again. -- Andre Gide
|
Arguably the big mistake was imagining that one person can stand in for all the stakeholders and decide what to do without error. I am not sure what a better way would be, but that way is at best very difficult and sometimes impossible.
"What do we build" is such a hard question to answer over and over again. I favor a small group of dedicated and diverse people to answer it:
-- best,
jk
--
Joshua Kerievsky
CEO,?Industrial Logic, Inc.
Web:
Twitter: @JoshuaKerievsky, @IndustrialLogic
New Book: Joy of Agility (Preorder at )
|
Hi Joshua, On Jul 12, 2022, at 3:53 PM, Joshua Kerievsky < joshua@...> wrote:
"What do we build" is such a hard question to answer over and over again. I favor a small group of dedicated and diverse people to answer it:
Yes. I think the big concern that both Scrum and XP had at the time was avoiding the team having more than one master. Clearly a true team approach would be better. I recall Kent saying that he felt the customer/programmer split in XP was a major flaw but that he didn’t see how to fix it.
Ron Jeffries
For us, there is only the trying.?
The rest is not our business.?
—T.S. ELIOT
|
Hi, Ferdinando. For a historical perspective about efforts to improve service and operations management on the IT industry, you could also include perspectives from ITIL concepts, practices, its derivatives and
diverse implementations since more than two decades ago:
|
The Information Technology Infrastructure Library (ITIL) is a set of detailed practices for IT activities such as IT service management (ITSM) and IT asset management (ITAM) that focus on aligning IT services with the needs of business.. ITIL describes processes,
procedures, tasks, and checklists which are neither organization-specific nor technology-specific, but can be applied by an ...
en.wikipedia.org
|
Regards.
toggle quoted message
Show quoted text
A few weeks ago I held a meetup about DevOps.
Instead of giving a presentation, I stimulated a debate with the audience present, presenting several hypotheses to discuss and possibly refute.
?
Very provocatively, my hypothesis was that DevOps did not invent anything new :D
?
To summarize a lot, I believe DevOps rode the wave of the emerging cloud universe, bringing attention to a whole set of practices and tools that cannot be ignored today. Those who manage complex infrastructures can no longer afford to do it by hand, in
many cases to date it is simply impossible to do so.
?
That said, I continue to believe that DevOps has "simply" taken up (and brought back into fashion) concepts from Lean, the Manifesto for Agile Software Development, and eXtreme of Programming of course.?
?
I come to the point, which is then the title of this post :)
?
What were Operations like in the days of the C3 Project?
I get the impression that XP was very little concerned with Operations, and I am curious to understand why:?
- Were Development and Operations worlds totally separate?
- Was it not of "strategic" interest?
- ?Wasn't Operations simply an issue at the time?
Or am I simply missing something?
?
I am curious to have the opinion and listen to the stories from the pioneers listening :)
?
Thank you!?
Ferdinando
|
Thank you Ron! :)?
?
So, even in the early days of XP the topic of Operations was present and felt, but for some reason the XP teams failed to convey this nascent culture to even that (very important) phase of the software release cycle.
Am I understanding this correctly?
?
Was any other effort made in this regard during or after the years at Chrysler?
Did XP ever worry about Operations, before the advent of DevOps?
|
Interesting read, thank you Joshua!
|
sent from iPad, probably via Mars. Errors, if any, are not mine. ronjeffries@... is a better address for me, maybe. On Jul 12, 2022, at 4:48 PM, Ferdinando Santacroce <ferdinando.santacroce@...> wrote:
So, even in the early days of XP the topic of Operations was present and felt, but for some reason the XP teams failed to convey this nascent culture to even that (very important) phase of the software release cycle.
Am I understanding this correctly? I told one story about one event, on the very first XP project. Your conclusion above seems more general, and more negative than one story would justify.
Was any other effort made in this regard during or after the years at Chrysler?
Did XP ever worry about Operations, before the advent of DevOps? Some folks did. I did. I recall specifically advising a team on bringing ops people together with the dev team. If I recall correctly, the company did not agree. I think DevOps is implied in both XP and Scrum, but has not received the emphasis that it might deserve. It seems to me that the DevOps supporters might have done better to align with XP/Scrum rather than try to be their own thing, but it is what it is. R
|
Having more than one final decision maker is a formula for paralysis and contradictory?stories.? Not knowing what to build is usually worse than building some stories that?should have been lower priority.
What should be feasible is having a diverse?set of stakeholders actively involved in the iteration/sprint reviews and encouraging them to provide feedback.
Hi Joshua, On Jul 12, 2022, at 3:53 PM, Joshua Kerievsky < joshua@...> wrote:
"What do we build" is such a hard question to answer over and over again. I favor a small group of dedicated and diverse people to answer it:
Yes. I think the big concern that both Scrum and XP had at the time was avoiding the team having more than one master. Clearly a true team approach would be better. I recall Kent saying that he felt the customer/programmer split in XP was a major flaw but that he didn’t see how to fix it.
Ron Jeffries
For us, there is only the trying.?
The rest is not our business.?
—T.S. ELIOT
|
And of course, operations should be one of the stakeholders providing regular feedback.
On Tue, Jul 12, 2022 at 11:28 PM Steven Gordon < sgordonphd@...> wrote: Having more than one final decision maker is a formula for paralysis and contradictory?stories.? Not knowing what to build is usually worse than building some stories that?should have been lower priority.
What should be feasible is having a diverse?set of stakeholders actively involved in the iteration/sprint reviews and encouraging them to provide feedback.
Hi Joshua, On Jul 12, 2022, at 3:53 PM, Joshua Kerievsky < joshua@...> wrote:
"What do we build" is such a hard question to answer over and over again. I favor a small group of dedicated and diverse people to answer it:
Yes. I think the big concern that both Scrum and XP had at the time was avoiding the team having more than one master. Clearly a true team approach would be better. I recall Kent saying that he felt the customer/programmer split in XP was a major flaw but that he didn’t see how to fix it.
Ron Jeffries
For us, there is only the trying.?
The rest is not our business.?
—T.S. ELIOT
|
Thank you for the clarification, Ron.
|
I’ve seen teams who used a form of consensus to make very good decisions. I think that’s better than having one person with the Big Says, not least because it is a horrible job to have.
R
Having more than one final decision maker is a formula for paralysis and contradictory?stories.? Not knowing what to build is usually worse than building some stories that?should have been lower priority.
What should be feasible is having a diverse?set of stakeholders actively involved in the iteration/sprint reviews and encouraging them to provide feedback.
Ron Jeffries
Perfectionism is the voice of the oppressor -- Anne Lamott
|
I have seen that work well for the tactics of what to do in the coming iteration given the long term vision of the product and recent feedback.? I have never seen that work well for the vision itself except for a product whose target customers?were developers.
I’ve seen teams who used a form of consensus to make very good decisions. I think that’s better than having one person with the Big Says, not least because it is a horrible job to have.
R
Having more than one final decision maker is a formula for paralysis and contradictory?stories.? Not knowing what to build is usually worse than building some stories that?should have been lower priority.
What should be feasible is having a diverse?set of stakeholders actively involved in the iteration/sprint reviews and encouraging them to provide feedback.
Ron Jeffries
Perfectionism is the voice of the oppressor -- Anne Lamott
|
Are you supposing that there would only be developers on the team??
I have seen that work well for the tactics of what to do in the coming iteration given the long term vision of the product and recent feedback.? I have never seen that work well for the vision itself except for a product whose target customers?were developers.
Ron Jeffries
This was once revealed to me in a dream.
— Geoffrey Bles
|
From my experience, agile development methods and DevOps were orthogonal?concepts that?worked very well together. With the XP books written ~1998 and DevOps showing up a decade later.
I started using XP on my teams in 2005 when one still needed a separate team to stand up production hardware and software. In 2006, we did have aws, but the engineers that I worked with didn't want to be managing linux distributions.
Enabling technologies like heroku and later cloud foundry allowed engineers to own the entire operations experience. Back in 7/2010, I remember the huge time savings I had when I switched my first app over to heroku. From then on, the developers on my XP teams did DevOps, it was so easy. For larger companies running cloud foundry, there might be an operations team responsible for configuring cloud foundry, but each product team would own the running of its own applications.?
Recall that one of XP 2.0's practices is "Daily Deployment" and that XP and Scrum both want shorter feedback loops and smaller batch sizes. In time, XP and Scrum reduced the planning commitment level to a week. At Pivotal, we reduced the planning commitment level to the story. After achieving that, I'd like to think that Continuous Delivery would be inevitable.
sent from iPad, probably via Mars. Errors, if any, are not mine.
ronjeffries@... is a better address for me, maybe.
> On Jul 12, 2022, at 4:48 PM, Ferdinando Santacroce <ferdinando.santacroce@...> wrote:
>
> So, even in the early days of XP the topic of Operations was present and felt, but for some reason the XP teams failed to convey this nascent culture to even that (very important) phase of the software release cycle.
> Am I understanding this correctly?
I told one story about one event, on the very first XP project. Your conclusion above seems more general, and more negative than one story would justify.
>?
> Was any other effort made in this regard during or after the years at Chrysler?
> Did XP ever worry about Operations, before the advent of DevOps?
Some folks did. I did. I recall specifically advising a team on bringing ops people together with the dev team. If I recall correctly, the company did not agree.
I think DevOps is implied in both XP and Scrum, but has not received the emphasis that it might deserve. It seems to me that the DevOps supporters might have done better to align with XP/Scrum rather than try to be their own thing, but it is what it is.
R
|
My experience in the industry is that most organizations enforce a separation between development teams and a (generally shared) operations team.? And the two groups generally fall into a hostile relationship with each other.? The development teams (and their managers, in particular!!!) are heavily incentivized to "claim as many features as possible" and cram them all into production ASAP, regardless of consequences -- to get the "On Time and Within Budget" performance incentive checks.? And operations gets hit with the 2am calls when it crashes, and is expected to fix things.
I've worked to "reach across the isle" on many projects, to recognize and resolve problems.? It's always tense.? And often not even allowed.? "There Are Official Channels And You Will Use Only Those!!!"? I've done a lot of informal "wondering over to chat."? ?;->
I think that development teams should be a lot more involved and responsible for production support.? Don't "throw it over the wall" to operations; be involved.
|
Hi!
You just acknowledge a common orgnizational anti-pattern, IME, the first version of XP doesn?t talk about, but when Continuous Integration evolved in Countinuos Delivery, it started to show the importance of integrate Dev with Ops.
In 2008 some people started to talk about "Agile IT Ops", and later it was called DevOps.
In my own experience, my first full fledged XP team was also a DevOps team since one of our team members has an deep ops understanding, so we discover some of current DevOps most known good practices.?
Since XP hasn?t been updated since the last Kent Beck's book, probably we need to make our own mix to integrate DevOps?
Saludos!
? Agustin
|
I don’t think XP has forgotten about operations, except to the degree that “official" XP has stagnated over the last ~15 years. Personally, I see DevOps as a natural extension of XP’s ideas. Including ops in the team is a natural extension of Whole Team. Continuous Deployment is a natural extension of Continuous Integration. Etc.
It’s not official, but my book (The Art of Agile Development) is a sort of spiritual successor. It starts with an XP base and integrates a bunch of DevOps topics, along with other recent Agile ideas. I have a bunch of book club discussions linked from the table of contents, including topics such “Build for Operation” (with Jessica Kerr), “Continuous Deployment” (with Kelsey Hightower), and “System Architecture” (with Doc Norton):
Cheers, James
Hi!
You just acknowledge a common orgnizational anti-pattern, IME, the first version of XP doesn?t talk about, but when Continuous Integration evolved in Countinuos Delivery, it started to show the importance of integrate Dev with Ops.
In 2008 some people started to talk about "Agile IT Ops", and later it was called DevOps.
In my own experience, my first full fledged XP team was also a DevOps team since one of our team members has an deep ops understanding, so we discover some of current DevOps most known good practices.?
Since XP hasn?t been updated since the last Kent Beck's book, probably we need to make our own mix to integrate DevOps?
Saludos!
? Agustin
-- James Shore - The Art of Agile
voice: +1 503-267-5490
blog:
|
Nice point James!
?
I hadn't thought of that, actually the concept of "Whole Team" can be seen as the practice opened to include Operations.
Just as CI contained a seed of DevOps.
?
You then raised another issue that has been on my mind for some time, the fact that XP has not been "officially updated" anymore.?
I sometimes wonder: what would a third edition of the white book would look like? What would it contain today? :)
?
I am very familiar with your work (aoad and aoad2): it is what I recommend to any dev who asks me for a book from which to begin his or her journey in agile software development world.
In fact, while I am at it I take this opportunity to thank you for this very important contribution to our beloved world :D
?
|
Thank you!
Nice point James!
?
I hadn't thought of that, actually the concept of "Whole Team" can be seen as the practice opened to include Operations.
Just as CI contained a seed of DevOps.
?
You then raised another issue that has been on my mind for some time, the fact that XP has not been "officially updated" anymore.?
I sometimes wonder: what would a third edition of the white book would look like? What would it contain today? :)
?
I am very familiar with your work (aoad and aoad2): it is what I recommend to any dev who asks me for a book from which to begin his or her journey in agile software development world.
In fact, while I am at it I take this opportunity to thank you for this very important contribution to our beloved world :D
?
-- James Shore - The Art of Agile
voice: +1 503-267-5490
blog:
|
Ferdinando Santacroce
Agustin Villena