I hate agile/scrum because...

realJSOP

We don't use branching/merging in TFS. 1) We don't have a configuration manager that should be in charge of making deployment packages. 2) We never get sanctioned time to work technical debt on our 13-year-old code base 3) We never get sanctioned time to work on developing tools that help us do our jobs better (a different kind of technical debt) 4) It's not a software development management tool, it's a people/time management tool that doesn't allow for mistakes or problems, or delays outside the development process (usually regarding infrastructure problems). 5) Our program manager is micro-managing our development. Yesterday, he had an all-day meeting to go over ALL of the support tickets and what their status was, and he took it on himself to cancel a bunch for reasons only known to him. During the meeting, he said, "What are you guys doing with your time?", and I said, "Well right now, we're in an endless meeting listening to you complain about ticket statuses, when we could be working on the tickets we've already been assigned." That response was not well-received.

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

PIEBALDconsult

#realJSOP wrote:

We don't use branching/merging in TFS.

Branching/merging is a process smell. In thirty years (?!) of development I haven't had to use branching/merging.

#realJSOP wrote:

... to work on developing tools that help us do our jobs better

TFS' API is an outstanding tool for developing these kinds of team-helpers.

RickZeeland

Maybe you should use JIRA, a magic agile bullet that will make all your problems go away ... (or one of these jira-alternatives[^] ) :-\

raddevus

PIEBALDconsult wrote:

Branching/merging is a process smell. In thirty years (?!) of development I haven't had to use branching/merging.

Attempting a discussion, not a rant nor anything to prove. In a team, Branching, Merging means: 1) Production-running code is on the Main (develop, default,etc.) branch. 2) To make a change, a developer branches Main (production code), makes changes, enhancement, bug fixes --- This leaves Main (prod code) safe and sound in it's original branch. 2a) Once dev is done, code is built & handed to QA/Test 2b) Maybe QA/Test notice some things that have to be fixed in the code. 2c) Dev makes more changes (checking into branch along the way, of course) and submits to QA/Test 3) Finally the code is approved. 4) Merge the changes into Main (default, develop,) branch and deploy. * This all means that Production code is always safe and easily retrieved from Main branch * This means that if a dev begins doing a change and it is decided not to be used then the branch is dead & she doesn't have to pull the code out of Main (production code). * This also means that a team of developers can work on different parts of the system at the same time (last to complete & merge to Main gets the pain though). * Keeps things so you always have a good working copy in source control at all times. Does this still seem like a Smell? Just curious.

Slacker007

How many more days again till you retire? :laugh:

Greg Utas

Quote:

Branching/merging is a process smell.

Disagree. There should be a release branch for each previous release, plus a development branch. Only bugs are fixed in a release branch (and damn the architecture). They must then be fixed properly in the development branch, which is also where new features are undergoing development.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

Greg Utas

#2 and #3 are not unique to Agile/Scrum. They're a sign of imbecilic, blinkered management, which is a widespread problem.

Robust Services Core | Software Techniques for Lemmings | Articles
The fox knows many things, but the hedgehog knows one big thing.

englebart

#0 should at a minimum have a Dev branch and a Prod branch. If something major pooches Dev, you can start a new Dev from Prod Agree on #2 We recently switched to a new UI. It took a lot of scrambling to get the artifacts for the previous iteration removed from the code. We need to be able to have dedicated sprints to “take out the trash”. #4 infrastructure: why Developers came up with DevOps and infrastructure as code!

kmoorevs

#realJSOP wrote:

We never get sanctioned time to work on developing tools that help us do our jobs better (a different kind of technical debt)

Is that an agile thing? :thumbsup: It's hard to sell the ROI to management who also have to sell it up the chain. In my situation, I'm forced to lie about it (working on productivity tools) or worse, do it on my own time/dime.

"Go forth into the source" - Neal Morse "Hope is contagious"

realJSOP

We have multiple devs working on multiple apps sharing a lot code - branching/merging would really help.

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

realJSOP

we have a lot of signs of imbecilic, blinkered management.

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

realJSOP

July 12 2023 - that's my magic bullet.

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

realJSOP

It's a a side-effect of agile. We're only supposed to work on assigned tasks. Most of the technical debt we resolve is done on our own time - like the deployment tool I wrote, or the config-less connection strings module I wrote, or the entity factory app I wrote, or the refresh process forensic inspection tool I wrote. I could go on, but I think you get the point...

".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013

Rick York

Since it is a government organization that is exactly what I would expect. Even a moderate level of competence would be a surprise to me.

"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"

Gary R Wheeler

I think any one of your items would make a great entry on a "Top 10 Signs You Should Bail" X| list. Just today I got tacit approval to address a #2 item. We have a piece of equipment-wrangling code that got its start 20 years ago. It's been through 6 or 7 hands in that time and an integral part of several different products. There have been any number of chain-saw edits to adapt it each time. The end result is less than coherent, and its behavior on the newest product has... bizarre edge-condition issues. I volunteered to take it over when one of our team quit and we reshuffled responsibilities. Yeah, I know volunteering is stupid. This thing, however, should be easy. Anyway, there was a gripe from the product prototype machine. This was the first time I'd done a deep dive into this code. None of it is particularly bad, it's just there's inactive cruft laying around and you can't see the forest for the kudzu. I told my boss in our team meeting today that I'd set up a branch of the component and I was developing a new version as a "learning experience" while I reviewed the original. Josh knew this was some of my finer grade BS, but he let me get away with it. Part of it may have been the fact that his hands were the last ones in this body of code before it landed in my lap. In my role as the DSJB(*) I've spent significant time on item 3. We have a diagnostic tool that is a Leatherman™[^] multi-tool for debugging our multi-processor, multi-threaded applications. Our home-grown automated build process ensures our products go from source control to compilers to install media, internal publishing, and change documentation without any manual steps or intervention. (*) Departmental Shit-Job Boy

Software Zen: delete this;

den2k88

#realJSOP wrote:

It's not a software development management tool, it's a people/time management tool that doesn't allow for mistakes or problems, or delays outside the development process (usually regarding infrastructure problems).

On this point I just want to say that Agile/Scrum is not a process per se but a few requirements of a process to be implemented by the company - nobody can print a list of operations to follow and declare themself agile. Compare it with SPICE and AutoSPICE to see the difference: each phase in SPICE is preceded, followed and cluttered by a metric farkton of paper. That said, if the process does not account for mistakes then it is broken. Each and every process must take into account the presence of mistakes in each of its phases and have mitigation/recovery procedures in place. All the other points are not Agile per se, it's the usual bad management. No process or process philosofy can fix that. I also worked with a manager that swore by Agile and he could work on safety sensitive (railway, so millions of potential life losses involved) projects that required high amounts of formal documents and validation with 99% efficiency, with a team of average-good developers (no geniuses). How did he do that? He is simply a good manager that chose Agile as it reflected his way of moving. I am sure he could have used any process management and have it work just as flawlessly.

GCS d--(d-) s-/++ a C++++ U+++ P- L+@ E-- W++ N+ o+ K- w+++ O? M-- V? PS+ PE- Y+ PGP t+ 5? X R+++ tv-- b+(+++) DI+++ D++ G e++ h--- r+++ y+++* Weapons extension: ma- k++ F+2 X

GuyThiebaut

My understanding is that the purpose of Agile was to get developers to talk with each other but it has morphed into something that can be marketed and sold and can become bloated with unnecessary guff. Strangely enough all the swimlanes, burndown, backlog, user stories etc. can lead to developers talking less with each other. Branching and merging isn't always necessary but in my daily work I could not get away without it as there are too many of us working on the same codebase to risk committing straight to main and making the lives of other developers hell - on my personal home projects where I am the only developer I don't use branches.

“That which can be asserted without evidence, can be dismissed without evidence.”

― Christopher Hitchens

megaadam

#realJSOP wrote:

We never get sanctioned time to work technical debt

and such idiocy is not the fault of Scrum. That is the fault of a dyzfunctional corporate organisation [that uses "Scrum" as a pretext for anythin and everythin]

"If we don't change direction, we'll end up where we're going"

obermd

is your real problem. I agree with your comment about spending time in an endless meeting. I try not to do this with my staff.

Andreas Mertens

I always try to add an extra bit of buffer to my estimates. That way I have that extra bit of time to deal with refactoring/technical debt issues. If I don't use it, it looks good to management that I am meeting or exceeding my estimates.