|
There is no better way to do it. What I mean by that is, agile is shite, but there is not current better alternative that takes into equal consideration for both profit and quality.
It comes down to profit versus quality. profit will always win. quality will always lose.
modified 9-May-22 6:47am.
|
|
|
|
|
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
|
|
|
|
|
Why are these problems related to agile?
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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. 
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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.
|
|
|
|
|
The Agile Manifesto should also include "Quality Determines Profit" 
|
|
|
|
|
It does include "Working software"
|
|
|
|
|
"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
|
|
|
|
|
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.
|
|
|
|
|
Thanks for posting this. I was getting bored reading it yesterday. I'm glad someone else got through it to decide it was worthy. 
TTFN - Kent
|
|
|
|
|
Before one can do a sprint, one should have an raw/rough overview of the route.
Only my two cents.
|
|
|
|
|
Never begin a sprint when hurdles are in place.
|
|
|
|
|
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 ![Heart | [heart]](https://www.codeproject.com/script/Forums/Images/love.gif) 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
|
|
|
|
|
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
|
|
|
|
|
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!" 
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. 
|
|
|
|
|
|
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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
