Scrum and all "Agile" memes needs to fuck off and die

I just sign off the 2 hours long "sprint planning" meeting and I just want to blow my brain off. We spent 2 hours "voting" on different stories and those points will never ever matter again, other than the manager can make a tick in his spreadsheet, that we are "agile". FUCK OFF. I was actually in the middle of something, being productive when they called a meeting and now I feel totally numb. These meetings always feel like chore for everyone, like we are a religion and we need to pray twice a day and they rarely contribute anything meaningful. If I have question I will ask for clarification on Slack anyway. Fuck this.

Other urls found in this thread:

en.wikipedia.org/wiki/Scrum_(software_development)#Limitations
twitter.com/NSFWRedditVideo

>tfw nobody anywhere delivers a finished product anymore, because everyone is doing iterative endless beta garbage with rolling releases and constant waves of new bugs because feature stories are sexier than bug fixes

It's unbelievable that as a culture we pivoted from "Fuck meetings, everyone hates them and they only exist to satisfy middle managers" to "Actually everything is meetings now."

>We spent 2 hours "voting" on different stories
If your spring planning takes 2 hours then your scrum master is a fucking retard and doesn't understand how agile development is supposed to work.

>those points will never ever matter again
Those points are meant to be used by management so they can determine what needs to be backlogged (what won't fit in the sprint and is not part of the minimally viable product). They are important, but your management has to be competent.

>These meetings always feel like chore for everyone
No shit. You are at work. Everything you do is a chore. Those meetings are mostly for the benefit of management so they can prioritize stories based on your team's capacity and total workload. This is especially important for projects which have ever-changing requirements.

>scrum master
hahahahahaha
we are literally 3 guys sitting in the small office all day together and one product owner/manager who is in the other city. That's why I think it's ridiculous.

I am glad I never worked in team

this shit will suck your soul and will make you hate programming

God I know that feel.

It sounds like with that small of a team you should probably just use a Kanban board and pull in stories as you work and remove a lot of the process/meetings from your work. Kanban differs from Scrum in some important ways. Perhaps you can read up on Kanban and suggest it to your managers. It's still agile, just a different implementation with more flexibility and a little less planning.

When I was a slave to a corporate overlord this is how we did agile development:

1. Daily "standup" meetings (15 minutes): Discuss what we worked on yesterday, what we are working on today, and anything which is blocking us from completing our assigned stories. Each person takes turn giving their daily report and is expected to keep everything short and to the point. The scrum master would take note of any blockers and do what needs to be done to unblock individuals. (ideally

>grooming
kek

i'd like everyone to take a step back and read some of the things that have been posted.

"stories" "scrums" "scrum master" "agile" "sprints". From an objective point of view how can anyone say this isn't meme buzzword bullshit straight off some tech guy's blog one time

where you could just get a bug report and fix it or get a feature request and implement it instead there are hundreds of manhours dedicated to packing scrums to justify one or more manager's job that doesn't need to exist

following 1 process management is retarded and generally doesn't work. every company is different and killing all issues with one style rup, scrum, v-model or xp is simply not going to work out.

agile development is more or less just a sign in capslock that says "HYPERACTIVE MANAGEMENT INCAPABLE OF MANAGING".

the entire idea of agile development is flawed, because you prioritize the success of your product. the product owner is just a business analyst, so you lack proper technical expertise in software design and security.

agile * is the most cancerous thing that happened to the IT industry. the result is just another bunch of unmaintainable garbage just so a company can please their board of directors so they can profit further, by selling yet another useless product, while actively supporting adoption or introduction of broken technology.

Wait until you get a waterfall.

90 pages of documentation for a basic crud app written by people who have no fucking idea how anything works.

Try saying "this could be refactored" and get told "if we wanted your opinion you wouldn't be coding".

fml

Stay NEET, NEET. Or grow up and realize that complex projects have complex needs and that a standardized process is needed to ensure things keep running smoothly. I'm not saying agile is the best choice for every project, but it definitely has it's place. Just because you lack the experience to understand how and when it is useful, that doesn't make it "meme buzzword bullshit". For some projects, Waterfall methodology works best. For others, Agile works best (there are many different types of Agile development for different needs, with Scrum and Kanban being the most prominent).

It's pretty obvious you just lack experience working with teams on large projects with requirements that frequently change over time.

Anyone who tells you rules on how to be agile is a snake oil salesman. The whole idea of agile is that you do what works, and hopefully actually deliver things that are important and not cruft.

That said, this sounds like it is closer to what I have had positive experiences with.
But you have to know when something is having a positive effect and when you are lacking something that can be fixed by a change in your team rituals. Points are a huge wank though in all circumstances.

>hen your scrum master is a fucking retard and doesn't understand how agile

>implying scrum master is meant to understand something
>implying a scrum master is just someone from marketing

in addition, with using scrum you are bleed out, which of course your employer benefits from most because they have to higher less people qualified people and for you into a certain position if the project demands it. by definition from scrum you are supposed to be an all-rounder, so you do architecture, programming, testing and documentation all together. and as a result of the lose roles, legal responsibility for the product is unclear too.

scrum's just pure bullshit

You are retarded. Architecture and programming are not combined into a single role except in very small companies working on small projects with small teams. In fact, software architects are often not even on the same Agile team as the software developers.

> have to higher less people qualified people and for you into a certain position if the project demands i
have to hire less (qualified) people and force you into a certain position.

ore no ingrish heta desu yo

en.wikipedia.org/wiki/Scrum_(software_development)#Limitations
>Teams whose members have very specialized skills: In Scrum, developers should be able to work on any task or pick up work that another developer has started. This can be managed by good Scrum leadership. While team members with very specific skills can and do contribute well, they should be encouraged to learn more about and collaborate with other disciplines.

> In fact, software architects are often not even on the same Agile team as the software developers.
yeah that's even worse. you separate architects from the developers, that sure makes sense, lmao

>should be able to work on any task or pick up work that another developer has started.
That's between developers

>that sure makes sense, lmao
It does. The only reason a developer should need to directly interact with an architect is if the architect is bad at their job and wrote a shitty specification. All the information a developer needs to work on the low level implementation should be available in the specs/documentation. If it does become necessary for some minimal interaction between the devs and architects then they may set up an architecture review meeting. The software architects time is much more valuable than some stupid code monkey and they can't just have all the dumb monkeys wasting the time of the architects outside of process. Forcing the architects to context switch just because a bunch of dumb devs want to pester them with questions or other nonsense is bad for productivity.

I dont know, I personally like SCRUM or atleast the way it is done at my firm. We have 3 meetings a week where 2 of them go like 30min and the longer one goes 1h. Sprintplanning doesnt take too long because a lot because everybody is atleast somewhat prepared and a lot of tickets are pushed into the sprint already before planning officially starts and is just discussed at the meeting. So I cant really complain about the process, I think it's ridiculous if you do it for 3 man projects like you say but once you have a teamsize of like 10+ people and your SCRUM master is competent I like the system.

when I read about these flaws I am just happy the people in our company are smart enough to do a rather liberal interpretation of SCRUM to make it work for the project we have.

But when I hear of companies like Audi actually paying their developers according to how many Storypoints they finished I just think its utterly ridiculous. How can you possibly pay someone by an entirely made up metric ?

>That's between developers
>encouraged to learn more about and collaborate with other disciplines.

>The software architects time is much more valuable than some stupid code monkey and they can't just have all the dumb monkeys wasting the time of the architects outside of process. Forcing the architects to context switch just because a bunch of dumb devs want to pester them with questions or other nonsense is bad for productivity.
here is what i don't understand. if you have 2 cases, one of an architect which is external, and the other case of an internal one who isn't a developer, how do you have a constructive communication flow except when you have the initial kick-off?
i don't see how either of those to example architects can design something without being in the loop of with the devs, especially with senior developers. and most importantly, where the fuck are the security architects involved in this?

you overall confirm that scrum is not about good software development but about fast software development which in most cases results in shit software. everything has to be faster, cost and time efficient, disregarding security, stability, correctness and cost.

justification of salary. if you can't prove that you are worth it you are out.

audi, bmw and merzedes are full of business economists, who treat everything just as numbers and actively ignore the ROI so they can report numbers for the next quarter on how much they saved, etc

You are right. I wrote down notes and I will confront my boss at the next sprint review and propose kanban instead. At least one of my two colleagues feels the same way about it.

Here is a simplified explanation of how it works within a large project with a lot of people involved:

1. The customer explains to the product owner what they want. The architects may or may not be present during this handoff of information.
2. The product owner thinks about time management. Is it more important to get a minimally viable product out first and develop additional features later or do they need to have a full featured product from the beginning? That is the sort of thing the product owner worries about. The product owner works with the architects and customer to determine what pieces need to be developed and in what order. Once this is determined the architects are assigned work.
3. The architects determine how all the different pieces of the project should interact with each other and write specifications explaining the high level implementation details. If they are tasked with architecting changes to an existing system, they must consider the implications of those changes and weigh the pros and cons of different possible implementations. They write all the documentation needed for the developers to work on the project, often including diagrams. They outline what the input is and what the output should be. Stories are then created complete with description, acceptance criteria, links to relevant documentation, and any addiontal notes they feel are necessary.
4. Stories are assigned to developers. The developers do not provide any creative input regarding the high level process (hence the term "code monkey"). They follow instructions as written and ensure that the developed product provides the specified output given the specified input. If they need additional information to complete their stories that implies that the specifications are not very good. That would need be communicated to the product owner (usually by the scrum master after the dev reports the lack of information as a blocker during a standup meeting).

someones just mad that their daily scrum didnt get finished in time

>1. The customer explains to the product owner what they want. The architects may or may not be present during this handoff of information.
business analysis as usual, nothing out of the ordinary. i would assume that the architect is always present in order to get a first hand picture. sure it doesn't seem necessary at that time because it's just the analysis of the situation
>2. The product owner thinks about time management. Is it more important to get a minimally viable product out first and develop additional features later or do they need to have a full featured product from the beginning? That is the sort of thing the product owner worries about. The product owner works with the architects and customer to determine what pieces need to be developed and in what order. Once this is determined the architects are assigned work.
if the architect is present that should be doable if they talk to another, but if you think about it in detail, how can the business analyst manage time if he doesn't know how much time a certain task consumes on the development side? a BA does just as the name implies, analyze business, no more. on what foundation would a BA be in the position to determine time consumption of things?
it's like you let a waiter organize the ETA for a 5 course menu, where he knows all ingredients inside each meal, but doesn't know how long each meal or ingredient takes to prepare.

Notice how this threads lacks shitposting and has actually quality posts in it, because it discusses things NEETs doesn't know anything about

I wish my dev team continued with some form of project management. We used to do the daily meetings but stopped. We had a board with post-it notes for tickets in whatever stages. that stopped. now we just do work on whatever tickets we have, no communication and it's hell.

this board needs more threads like these and whenever i see one i post in them because that's what i'm actually here for, and less censorship than on feggit

>how can the business analyst manage time if he doesn't know how much time a certain task consumes on the development side?
They don't need to know how much time it will take as much as they need to know what pieces should be done first and in what order. Once the dev team has their sprint planning and starts assigning point values to different stories they get an idea of how long things will take and the product owner can get an idea of what the ETA will look like.

Kanban is a godsend in a small team.

Just stick all functionalities, feature requests and bugfixes onto it, along with other requirements(dBase, test evrirorments requests etc).

Prioritize them once per week, cleanup done part of board biweekly.

Whenever anyone is free and capable they just take note, do the work.

No meetings except when cleaning or prioritizing the board which take 15 min tops.

My team is very small, just 3 people, and we are mostly doing r&d though.

>>how can the business analyst manage time if he doesn't know how much time a certain task consumes on the development side?
this is now how you do project management. you just pull numbers out of your ass on the go. highly inefficient and vague, how can you explain that to a customer "well i'm sorry we don't have a precise timeline with a backup plan in hand because we don't really care about specifics"

One of the core tennants of agile is the team needs to "own" the process. If its dictated by management the the team can't choose to adapt/improve, and you are left with a shitty business as usually with agile buzzwords slapped on.

Proper agile, done well, is fantastic.

this OP is clearly retarded

Feminine trends in society. "Communication" is key! Just talk about nothing for hours, we need to discuss everything, anything, and nothing, that way when something does end up being decided, we have taken everyone's feelings into account so what we do feeeeeels right!

As a Rank 3 Scrum Legend. My day consist of at least 3 scrum ceremonies in honor of me. 5 meetings where I get to basically stroke my cock in the middle of the conference room while everyone discusses my girth. Finally, I get to bitch and moan at everyone who tries to talk to me and tell them how they're impeding my workflow.

That's not how Agile is supposed to work. Sounds like your manager doesn't actually understand it. It works like this:

>Rank tasks in order of importance
>Meet and everyone choose a task
>Discuss plans for like half an hour
>Head off to do tasks, test implementation
>Meet again during next cycle, depends on project complexity but usually daily or weekly
>Discuss what you got done, what you still have to do, people offer insight into stuff you may have missed
>Put what's left to do on the board, pick again, adjourn, repeat

This isn't rocket science and I can't understand why people don't get it. Is the training just garbage? This is a method I've been using for 10 years to speed up group projects.

Talk about HHRR

does your place hire? sounds like i could fit in perfectly, i also have a massive penis

You need to have a tight boipussy to work there.

It's probably due to the fact that 8 out of 10 people hired as scrum masters and product owners are complete fucking morons. No amount of training can fix stupid.

Fuck off faggot can't talk now I'm in the middle of a sprint

The stories are just supposed to be a teaching aid. Scrum and Agile are intended for managers who are pedagogues or really good at instruction. Since I had instructor experience and passion, this wasn't hard for me. But I now see my fiancee's dad's business slow down on database software deliverables because it's like an 8-person business and they're wasting 3 hours a meeting on this shit.

They should only be taking max 1 hour and it's likely due to a combination of learning curve and how overly-bloated the system is when you take it all literally. It's like if your high school history teacher tried to use the entire textbook.

What these companies also aren't thinking about is billable hours. If you spend 3 hours in this storytelling garbage meeting that accomplishes the same or less than ignoring all that, you are paying 3 * Wage * Employees every single time. So if you meet twice a week for 3 hours at a time, pay $18/hr, and have 8 employees, you just lost $864/week ($3.4k/month), the same as ANOTHER EMPLOYEE salary.

The larger the team, the more you meet, the worse it gets. At some point you have to just do the math and ask if it's worth it to continue the charade or just hire a junior manager to work with people individually.

But in the same situation, if you met once a week, or with half the team twice a week (Team A first half and Team B second half) for maybe 30 minutes to 1 hr depending on difficulty moving forward, you'd only spend $72.That's a drastic change and well-worth it for an individual team to move forward.

this...

We technically are in scrum but our team uses more of a mixture between kanban and scrum. Works great for us.

>like fixing bugs
>in a team that is tasked with the vague task of improving the product
>majority of the tasks I do are bug fixes
>most of them are really easy to fix
>most of them are visible to the customer
>tfw
It feels great when a new release comes out and it includes dozens of bug fixes from you.

>B..but you are not doing agile correctly
>Y.. you need a competent manager
>This is how its done (proceeds to explain an opinionated way of doing things that only his company is using)
>Now we have N+1 ways of doing agile, none of which works
Listen up you all faggots. You know nothing.

The sad truth of this industry is that it is all about individual skill and knowledge. Often there is no way of knowing how much time a task is going to take without actually doing it. This is a BIG RISK.

Agile is only meant for customers who want a set of functionality no matter the cost, and is willing to prioritize and discard some requirements shall they not be finished at the end of a sprint. This applies mainly to startups, since programmers are building their own product and they are working 80h per week anyways. Also companies that have its own product developed in-house. Agile deals with the risk by minimizing it shall the project go behind schedule. In the end the client eats up all the delay.

For real corporate customers this is not an option because:
1. They demand a closed price: a full estimation of the work is required UPFRONT (often impossible).
2. The project has to be delivered COMPLETE, they can't work with just half the product. Thus no requirements can be left behind.
3. Everything has to be delivered at a FIXED unmovable deadline, or else the developer organization is penalized economically.
Here the risk is entirely assumed by the developer firm. Which is what the market demands.

welcome to corporate world, retard

>how can anyone say this isn't meme buzzword bullshit straight off some tech guy's blog one time
It literally is, but it got popular enough in corporate environments that there's no escaping it if you write software for a living.

>where the fuck are the security architects involved in this?
You know perfectly well that they aren't.