Was Posted in biz and had some good discussion and one suggested to take it to biz as there are some Dev's here.
Do you Jow Forums think this methodology has shat all over quality code development.? I keep hearing the argument that its just not implemented well as it taking on the mantra your not doing the REAL agile with a $150/hr Agile coach to tell you how it should be done for the nth time. The cult like mentality and buzzwords are off the fucking scale and the costs and special badges you get are akin to some pyramid MM scheme.
For me its been a total micromanaged costly fuck fest. Sprint X Y Z always turns into maintaining Sprints A B C with the dynamic changing of requirements, and the constant monitoring from Managers to report micro-tasks to the minute and justify why something wasn't done yesterday. Maybe this is the bastardization of it in the 00's and have achieved whats now called agile sweatshops you see posted in every job spec.
What are you experiences? Plus do you cram like sardines in an office of ass and testosterone?
What exactly is "quality coding" according to you? Because everytime I hear it it's to justify spending time on rewriting shit to C over delivering what was paid for.
Chase Allen
Non, non, non.
Agile is extremely simple, it's exactly and only what is outlined in the "agile manifesto" and basically boils down to "talking to people to know what they want and telling them what is possible beats clueless managers writing a specification"
Austin Mitchell
SCRUM is shit though. It was created for consultancy companies and only suitable for things a consultancy company would do. You can not develop software above a certain complexity using SCRUM.
Charles Bennett
Let me give it to you straight OP. It barely matters at all. Managers want some panacea that will make the software development process fool proof. So the trend is to come up with more and more systems to provide safety nets for bad developers. There is this belief that bad programmers under an agile methodology will be able to produce good code.
Well it’s all bullshit. The quality of the code depends on the quality of the coders. Give a team of seasoned programmers a project managed by a waterfall system and they will beat a group of average coders doing agile. But guess what, invert the roles and now agile will beat waterfall.
The single most important factor in software development is not your lifecycle system, it’s the quality of the programmers. But companies want to hire cheap coders so they will keep falling for the fads that promise higher programmer efficacy. And that’s the root of the problem
Angel Kelly
I used to be be a scrum master. Agile is just another tool to get a job done and is only as good of a tool as persons are competent in using it. Agile seems to be the latest buzz and fad and people like to use it as the excuse of how they accomplish tasks. Basically
>we’re agile, we can do what we want >oh, we fucked up developing a piece of software. Luckily we are agile
I’m sure something will supersede agile soon enough to be the next hot fad. I don’t really care either way.
>For me its been a total micromanaged costly fuck fest. It can certainly turn into that. It depends on the dynamic of what is in the backlog and how the product owners and scrum masters treat their team.
>Sprint X Y Z always turns into maintaining Sprints A B C with the dynamic changing of requirements To me, this comes off as either scope creep by the users (or someone closer to the devs) or that the users don’t actually know what the fuck they want. Ideally, the high level user requirements are broken down into defined lower level tasks that the dev teams can pick up to work. Of course, defining, sizing and allocating these tickets to future sprints can be a bit of a game and a pain in the ass.
>the constant monitoring from Managers to report micro-tasks to the minute and justify why something wasn't done yesterday. Yeah, basically business as usual. The uppers are always cracking the whip to get things done and adding new tasks if they can. A scrum master needs to be the reality check to the uppers. In other words, you need to make it a pain in the ass for uppers to just flip tickets on a daily basis.
(1/2)
Jose Sanchez
(2/2 continue)
>These were the priorities at the start of the sprint, why the change now >My team is already committed to these priorities, here are the consequences of changing the priorities now >You either get priority X done or priority Y done, not both
Never add new tickets to a sprint unless a team thinks they can handle them. In general, a team can only handle a certain number of points per sprint and throwing in additional points/tickets during a sprint will make work rushed. Honestly, if uppers are constantly doing this type of crap then something is broken in terms of what the requirements actually are and the uppers aren’t being honest in realizing this.
There’s probably other shit I can say on the topic of agile but I’ll hold off for the time being. Doubt people will read this anyway but I’d be curious of other people’s experiences.
Lucas Torres
Thanks for the post, I work in an agency and no amount of process seems to fix our dysfunction.
The thing I'm trying to bash into people is that there is really no such thing as a short task. Everything that is last minute wedged into the schedule actually has a knock on effect, PM's don't seem to understand that though.
Evan Kelly
>work in a small team getting stuff done >change of leadership >now have triple the amount of people, all agile monkeys, and get less stuff done Epic
Josiah Young
Jow Forums advice? How to deal with the inevitable crash and burn of a project you have recently been assigned to after the main dev, which also was a legit autist, quit the job after she blew it with every other dev for various reasons? Both management and Scrum Master hold a different opinion saying that we can make it. But I see it clear as day that this thing is going to blow up in our face through no fault of our own.
Wat do? hard mode - I actually like both the team and the company and don't want to switch jobs
Gavin Jenkins
if upper and middle management believe you can do it, and you're not in their group, there's little you can do to convince them otherwise personally i would just give them my opinion, explain why i think it's gonna blow up, and tell them if they want to keep working on the project i will, but not without warning them beforehand
Daniel Price
>Thanks for the post You’re welcome user. Wish I was around for the thread on Jow Forums.
I work in an agency and no amount of process seems to fix our dysfunction. You work for a Gov agency like DoD, don’t you. You poor soul.
>Everything that is last minute wedged into the schedule actually has a knock on effect, PM's don't seem to understand that though. Ideally, this shouldn’t happen and tasks that are shoed in at the last second are usually half assed thoughts. That means dev teams will have to play extra games to better understand the tasks and complete them which means the tasks suck up more time. PMs (not sure if you mean product managers or program managers, I’m thinking latter) don’t understand this because they don’t work on the level of the developers and treat dev teams as a black box.
>You put in a task and out comes a piece of working code after a sprint
To be fair, PMs shouldn’t be involved on a day by day basis with the devs anyway because then they’ll try to start micromanaging what the devs are doing. What PMs need to be aware of are what the processes are for completing tasks and that you can’t add additional tasks on top of a sprint, especially at the last minute, for free.
Lincoln Foster
>Epic Lame joke
Nathaniel Long
>write 80% of app by self in four months >company gets infusion of cash >hire product owners, more devs, and scrum master >been working on last 20% of app for 8 months and not delivered product yet >almost get fired for just randomly pulling shit out of the backlog and doing it, going end around the scrum process
Feels badman.
Blake Watson
Depends on how the project is crashing. If it’s really that bad then start looking for a new job. The harder thing to do is to understand which pieces of the project are salvageable and rework the broken pieces. Easier said then done because that could range from code to processes and so forth. Bottom line is to communicate with coworkers.
Noah Bennett
Why hire more in the first place then
Christopher Morris
This is probably the smartest thing I'll read all day. Thank you
Ethan Rogers
I didn't fucking hire them. I'm the architect. I guess that management thought that an application in 6 months wasn't fast enough so put all this bullshit in place.
Kevin Jackson
Software engineering is the humanities encroaching on STEM yet again. Unavoidable but disgusting nonetheless.
Just waiting for agile to update requiring diversity in the team for quality code
Or changing the questions so itd
1)what have i done 2)what i am going to do 3)whats in my way 4)how do I avoid spreading racist patriarchichal stereotypes?
Aaron Baker
>You work for a Gov agency like DoD, don’t you. You poor soul.
Nooo, just a private design agency, we mostly service pharma clients.
>Ideally, this shouldn’t happen and tasks that are shoed in at the last second are usually half assed thoughts. That means dev teams will have to play extra games to better understand the tasks and complete them which means the tasks suck up more time. PMs (not sure if you mean product managers or program managers, I’m thinking latter) don’t understand this because they don’t work on the level of the developers and treat dev teams as a black box.
I mean project managers, although I get the feeling that nothing at my place actually lines up with industry norms.
>To be fair, PMs shouldn’t be involved on a day by day basis with the devs anyway because then they’ll try to start micromanaging what the devs are doing. What PMs need to be aware of are what the processes are for completing tasks and that you can’t add additional tasks on top of a sprint, especially at the last minute, for free.
They seem to somewhat accept this in theory but it never works that way with them in practise. I've desperately tried to organise our software releases into actual "releases" instead of reactionary clusterfuck deployments after a PM gets off the phone and has promised the world. The bit where any kind of process breaks down is with bug reports, where we drop everything and fix them.
We have terrible problems with the quality of our software and its a vicious cycle. You get bug reports in which utterly fuck up proper work scheduling and timescales, and you end up releasing shit software that generates more of the same bug reports.
The amount of pain it takes to get any kind of automated testing approved in a project budget is just silly.
Nicholas Rogers
The classic story of the relationship between managers and engineers. It never changes, except in name.
Lucas Allen
That is Erik Meijer tier response. Good job. Kudos.
>Do you Jow Forums think this methodology has shat all over quality code development.? Yes. Read Watts Humphrey. >Software engineering is the humanities encroaching on STEM yet again. Nope. Software engineering is engineering. It's a science that uses objective metrics to measure software quality, development efficiency, etc. Read Watts Humphrey.
Jaxon Miller
Agile works very well for experienced team but is a nightmare if your team has too much variance in skill and experience.
Evan Hernandez
>after a PM gets off the phone and has promised the world Yeah, that’s a problem. PMs promise whatever to make the customer happy and then beat the ones under them to make the promises a reality. What is on the priority list to get done and what can get done are two separate concepts. This needs to be discussed with the PM so that they understand. Overpromising and underdelivering is not a good look from the customer point of view. On average, you want to deliver what you promise and figure out what is a good operating velocity.
>bug reports That’s an entity all of its own. In the ideal world, you are constantly running automated tests of each piece of of your software from the little bits to the full features to make sure things run as expected. In reality, not all tests can be smoothly automated, tests can take time to run, the real kicker is when tests are half assed or non-existent. Bugs themselves need to be prioritized. Just because you find a bug doesn’t mean it is critical to fix right away.
But it certainly is a game of trade offs. You have limited resources but a list of bugs and stuff the user wants.
