Agile is Killing Development From the Inside

realJSOP

Slacker007 wrote:

It comes down to profit versus quality. profit will always win. quality will always lose.

Yup "velocity" kills quality. Every time. Our shop hasn't completed all stories in a sprint since last february. I would guess that 99% of the reason is our crappy infrastructure, such as sys admins apply STIGs that result in our code breaking, ETL code that fails at the "E" part because our either our providers change something without telling us, or the fore-mentioned infrastructure or STIG issues. Add to that list of problems that we don't have a configuration manager to wrangle proper use of TFS or deployments, and we're stuck in the "Ops" part of DevOps to the extent that actual development comes in a distant second (or third) place. Most of our infrastructure problems are the direct result of moving our dev environment to the cloud. For me, at my current job, Agile/Scrum quite frankly sucks balls, and I will never advocate or its use.

".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

lmoelleb

Why are these problems related to agile?

Greg Utas

If profit doesn't win, the business soon closes unless it can count on continual subsidies, bailouts, gullible angel investors, or 2% debt refinancing. Hmm, maybe I just disproved my point.... For much of my career, I worked on products (telecom call servers) where customers demanded quality. You needed a certain level of quality just to be in that market, and if your quality dropped, so did the number of contracts that you landed. Up to a point, quality trumped schedule, content, and price.

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

realJSOP

They're related to our particular implementation of agile. Agile does not fit well with our environment. Beyond that, I've never been on an agile team where quality was the most important factor. It's always speed of development because of the corporate bottom line. This results in "hurry-up" code that, while it works, is a bunch of poorly thought-out implementations of "well, it works" code. We never have the opportunity to revisit this code despite the fact that we have tech debt stories specifically to do so. Tech debt is always lowest priority, because ease of maintenance doesn't translate to up-time for management because it takes too long to do. I refuse to work like that, and I'm always getting grief from the stake holders, despite the fact that my code is the least revisited on the team, and when it is, it's easy to modify because I believe that code should be less complex the closer you are to the UI, and all of my new feature code is written that way. It takes a little longer up front, but maintenance time is significantly reduced.

".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

Greg Utas wrote:

Up to a point, quality trumped schedule, content, and price.

Finding the balance is the hard part, but it's almost never found, or even searched for.

".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

lmoelleb

This is just standard incompetence you describe. Nothing is due to agile, but you clearly have some people in positions they should not be in.Quality/features will always be prioritized differently between organizations, but there will always be a balance. Agile does not say where that balance should be.

realJSOP

lmoelleb wrote:

This is just standard incompetence you describe...you clearly have some people in positions they should not be in

I don't know if you're aware, but I work as a government contractor, so... yeah. :/

".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

FWIW, I was working after hours and on weekends to take care of some of the technical debt "under the radar", but they put a stop to that by turning off the entire dev environment on weekends/holidays to save money, and for devs that are on leave for more than one day at a time, they turn off their dev boxes - again, to save money. If they're so damn worried about money, you'd think they would be worried about the technical debt.

".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

Yes indeed. But "Agile" is a broad term, not a well-defined strategy. And most managers don't realize that -- because most bloggers don't write that. Bloggers (bloggarts?) only reiterate that Agile is the Holy Grail and things domino inevitably from there. I still can't convince my boss that we've been Agile from the start and that trying to use Scrum would slow us down. I have never been on a project which wasn't already Agile and which would have benefited from using Scrum.

lmoelleb

Oh sorry, then it is indeed a requirement to have incompetence in key positions. In the private sector it can be avoided.... now and then. :)

rnbergren

They turn off machines on nights and weekends to save what $2. Heck they lost more time/money trying to figure out where to save money than actual money they freakin saved? What the what!

To err is human to really elephant it up you need a computer

Marc Clifton

The Agile Manifesto should also include "Quality Determines Profit" ;P

Latest Article:
Create a Digital Ocean Droplet for .NET Core Web API with a real SSL Certificate on a Domain

Kent Sharkey

Thanks for posting this. I was getting bored reading it yesterday. I'm glad someone else got through it to decide it was worthy. :thumbsup:

TTFN - Kent

0x01AA

Before one can do a sprint, one should have an raw/rough overview of the route. Only my two cents.

PIEBALDconsult

Never begin a sprint when hurdles are in place.

lmoelleb

It does include "Working software" :)

realJSOP

"Working" software doesn't necessarily translate to "quality" software, or even "usable" software. In point of fact, it almost never translates to those things.

".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

lmoelleb

In my book it does. If the software does not do what the customer needs, then it is not working. Luckily our product owner does get dragged into technical troubleshoot sessions now and then. That does give him a better insight into why these things needs to be prioritized. And for any new development it is the developer working on the task that says it is done - not the product owner. So developers can guard the quality level. Addition: And it is not the product owner that decides what refactoring is needed to add a feature as he does not have the technical knowledge. Sure he can skip the feature if our estimates including the necessary refactoring makes it too expensive. But overall I have not been in a "war" with a product owner except once (15+ years ago now). He ran to a director, the director came to me - and then I explained software development procedures to him for half an hour. Did not go down well but not much he could say as I was right :) Took him a year or two to admit it directly.

raddevus

After reading that article -- and I read the entire thing -- my thought is: "It is no wonder Agile is garbage. It cannot even create World Peace!" :rolleyes: I think everyone is reading far more into Agile than was originally intended. The corruption that has occurred to the original heart of Agile (Agile's 12 principles) is beyond discussion. The article has, however, convinced me that all Software Development Methodologies are garbage. All! And that makes sense, because it was created by humans. :sigh:

obermd

I stopped reading right after the author identified the root problem, which is that management can't resist consulticks (https://dilbert.com/search\_results?terms=Consultick) who have enabled management to corrupt the overall Agile concept.