Jeff, well you've called me out on producing an example of my "analysis paralysis". Under such circumstances I freeze. I had to think about this for few moments, but I've got one. This is fresh because I'm living it now. Our Project Management Office has started a process of cataloguing all the software we use, whether built in-house or from third-party vendors. I'm meeting with them tomorrow to discuss our use of TFS.
I know you're familiar with the phrase, "Accidental DBA", from here on SSC. Well, I've become what I call the "Accidental TFS Administrator", or more generally the "Accidental DevOps Guy", although not everyone where I work would agree with that. The guy who used to handle TFS, left a while back, thus I became the TFS administrator since I spent more time than my colleagues in learning how to use TFS. (Generally, I love learning how to make any tool work better for me as I do my job, which is software development.)
They've been using TFS longer than I've been here, but I get the feeling that they've only used it for storing source code. You can do more with it, such as automating unit tests, and performing CI/CD. Even though we use an out-of-date TFS, it still can do these tasks. And I'm trying hard to get us to adopt Azure DevOps Services as a replacement for our old, out of support TFS.
I see the adoption of Agile/DevOps and related, as a way of producing applications faster and potentially with better results than we do now. However, I appear to be going up against decades of inertia, where there's no desire to do anything at all new, for several simple excuses such as, "We've never done that before", "We've always done it this way" or the unspoken "I don't want to." Another thing that makes my trying to bring about a cultural change difficult is I work for a large state government department, which means we don't have any competition. But I really struggle hard with the huge level of inefficiency, which is not only tolerated but I'm convinced encouraged to be in place. Last year I complained in these forums of having to wait a week for a high-level committee to pass judgment on whether I could add two records to a lookup table in SQL Server. Also, the tendency here has been to make builds a one-shot thing, where a developer will build the app (Windows or Web app), then push it out to whatever the destination. I'm engaged in what now seems like a futile attempt to get people to use the build system that TFS supports. To that end I've spent a lot of time reviewing all our applications that are in TFS. I look through their build and release sections (TFS 2015 uses those terms. Azure DevOps uses Build and Pipeline.) Over several weeks I've discovered that the team I'm on is the only one which makes builds and releases of the Windows apps we make. Even my team doesn't make build and releases of the Web apps we make. None of the other teams make builds and releases for the apps they produce. I keep digging into this for analysis, discovering what we're doing (or not doing in this case), but I don't really know how much I should continue to pursue this analysis. My tendency is to continue to investigate, but standing back from it I really can see that there's truly little evidence I can find, to prove from our own data, that trying to follow agile practices produces quicker and more consistent results. If anything, the lack of evidence I've found supports the idea I've suspected for a while that what really happens here when management tells us to adopt agile practices, what happens is the resistance to adopt agile is so strong no one does anything about it, then when no evidence of agile efficacy is produced, they declare agile a failure. They can go back to producing applications the way they've produced apps for years, which often aren't compliant with what the user wanted and built inconsistently when different developers build the app on different machines.
(Sorry for the length of this reply. Much of it was to demonstrate how and why I'm churning at trying to find evidence for the efficacy of following good CI/CD practices.)
Kindest Regards, Rod Connect with me on LinkedIn.