Agile is Killing Development From the Inside

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.

Mike Hankey

How about ponying up for a talented crew where every member is talented at a piece of the project. Managements job is then; To make sure communications between teem members is maximized. Provide the necessary resources to do the job. Make sure the goals are clearly defined. Provide plenty of coffee. And stay the hell out of the way!

The less you need, the more you have. Even a blind squirrel gets a nut...occasionally. JaxCoder.com

RaviBee

0x01AA wrote:

one should have an raw/rough overview of the route.

I'm afraid I have to disagree. IMHO before starting work on a sprint's committed backlog items, one should have a damn good idea of the route (i.e. the deliverables). An important aspect of the agile process (whether it be applied to manufacturing or software development) is that the deliverables for a sprint be well articulated and small - i.e. small enough so that there's a high probability of achieving the sprint's goals. Agile novices often confuse small specifications with vague specifications. Also, you can't apply agile development to only a tiny part of the company (e.g. a development team) and hope that productivity will somehow magically improve. Where I work, product owners, BAs, QA (manual and test automation), design and documentation are involved in our agile process (along with devs) from the get go. We've actually seen improvements (requiring explicit specification of feature behaviors, fewer bugs, easier development and easier testing) in our dev cycles thanks to agile. And the tools we use aren't anything special. We just (ruthlessly) enforce good behavior: requirements (authored by product) are mostly in Gherkin and we have a clearly documented and realistic definition of done (which includes unit tests). I may be the exception to the rule but I :love: where I work. I think a lot of this has to with the fact that our engineering management all started out as devs (decades ago) and know the drill. #JustSayNoToBS :) /ravi

My new year resolution: 2048 x 1536 Home | Articles | My .NET bits | Freeware ravib(at)ravib(dot)com

realJSOP

We *constantly* redefine "done". Developers, testers and the customer all have different definitions. Then someone came up with "done done", which is "f*ckin stupid". It doesn't help that the software we use doesn't really fit scrum/agile very well, nor does it fit our bastardized version of scrum/agile. Our con-bon board has something like 15 states.

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

Slacker007

As the great J.R.R. Tolkien once wrote: "Evil cannot create anything new, they can only corrupt and ruin what good forces have invented or made." Management can't create anything new, it can only corrupt and ruin what once was good.