I mostly agree with the overall tone of the article but I do have to point something out:
> It is baffling on many levels to me. First, I am not an application developer and never have been. I enjoy writing code, mostly scripting in Python, as a way to reliably solve problems in my own field. I have very little context on what your application may even do, as I deal with many application demands every week. I'm not in your retros or part of your sprint planning. I likely don't even know what "working" means in the context of your app.
The point about not being in retros or part of sprint planning... I take up arms against that. I've worked for companies that have gone from waterfall to hybrid agile because we cannot get buy in from Ops to actually... you know... come to our retros, sprint planning and scrums.
Some things in this article is just pointing out the obvious... mediocre developers who push their problems and/or lacks on other teams. However, that quote the Author needs to look in the mirror. They exist only because of the products offered by the Company need resources. They have a responsibility to be business partners in that. If they aren't the company needs to re-align some priorities and it could start with Ops. Ops doesn't get a pass in an agile organization. The whole point of agile is to destroy them ivory towers. And if they were in those planning sessions, the developer might have already gone over the type of destructive testing that would have emerged from that collaboration and their DevOps relationship would be even richer.
> It is baffling on many levels to me. First, I am not an application developer and never have been. I enjoy writing code, mostly scripting in Python, as a way to reliably solve problems in my own field. I have very little context on what your application may even do, as I deal with many application demands every week. I'm not in your retros or part of your sprint planning. I likely don't even know what "working" means in the context of your app.
The point about not being in retros or part of sprint planning... I take up arms against that. I've worked for companies that have gone from waterfall to hybrid agile because we cannot get buy in from Ops to actually... you know... come to our retros, sprint planning and scrums.
Some things in this article is just pointing out the obvious... mediocre developers who push their problems and/or lacks on other teams. However, that quote the Author needs to look in the mirror. They exist only because of the products offered by the Company need resources. They have a responsibility to be business partners in that. If they aren't the company needs to re-align some priorities and it could start with Ops. Ops doesn't get a pass in an agile organization. The whole point of agile is to destroy them ivory towers. And if they were in those planning sessions, the developer might have already gone over the type of destructive testing that would have emerged from that collaboration and their DevOps relationship would be even richer.