|
#2 and #3 are not unique to Agile/Scrum. They're a sign of imbecilic, blinkered management, which is a widespread problem.
|
|
|
|
|
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
|
|
|
|
|
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?"
|
|
|
|
|
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!
|
|
|
|
|
#realJSOP wrote: 3) 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?
 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"
|
|
|
|
|
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
|
|
|
|
|
I think any one of your items would make a great entry on a "Top 10 Signs You Should Bail"  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;
|
|
|
|
|
#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
|
|
|
|
|
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
|
|
|
|
|
#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"
|
|
|
|
|
5) 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.
|
|
|
|
|
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.
|
|
|
|
|
I try to do that, but when we go into sprint planning meanings where we point new stories, I always get overridden when I declare a high points value. I know more about the code base than anyone else working on it, and when I try to give a given task 100 points, then goddammit, it's because I know that chunk of code is complex (which all of our code seems to be). But we're pressured to underestimate the points value. Every time.
I hate agile/scrum.
".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
|
|
|
|
|
I totally understand. This project I was working on, was a total ball of mud originally written by the "architect" of the system before I was brought in. In the previous sprint, I managed to sneak in a large refactoring start, but of course caught flack for that. But I've been pushing for a refactoring push for the past year, and we finally were given this last sprint to do a massive refactoring and code cleanup effort.
Of course, that's when I was transferred to another project/team. I have to wonder how this project I am leaving will now fare...
|
|
|
|
|
The apps I’ve been working on are all moving to a GOTS, so it doesn’t make sense to care anymore. Ticks me off…
".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
|
|
|
|
|
|
Looks like clickbait to me, I ain't going there.
"I have no idea what I did, but I'm taking full credit for it." - ThisOldTony
"Common sense is so rare these days, it should be classified as a super power" - Random T-shirt
AntiTwitter: @DalekDave is now a follower!
|
|
|
|
|
|
| +1
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
Not clickbait, quite an interesting part of the talk where he says that he feels bad for the destruction social media has inflicted on society.
“That which can be asserted without evidence, can be dismissed without evidence.”
― Christopher Hitchens
|
|
|
|
|
Indians should adopt shorter western names. WTF is wrong with "John Smith"?
".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
|
|
|
|
|
What? I don't even know where to start with a reply to that comment.
cheers
Chris Maunder
|
|
|
|
|
|
#realJSOP wrote: shorter western names.
Meanwhile Spanish people 
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
|
|
|
|
|
I think the guy is Thai, not Indian,😁!
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
