autotldr@lemmings.world
on 05 Jun 23:30
nextcollapse
This is the best summary I could come up with:
Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it’s cracked up to be.
One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.
“Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout.”
A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.
One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.
The original article contains 501 words, the summary contains 175 words. Saved 65%. I’m a bot and I’m open source!
Agile software development bases on four core values (paraphrased to make them more drastic but not change them in their meaning):
Proper tools are not important
Documentation is irrelevant
Don’t have a contract to adhere to
Do not follow any plans
I am not surprised that this fails miserably.
Skullgrid@lemmy.world
on 05 Jun 23:54
nextcollapse
eXtreme Go Horse Methodology
audiomodder@lemmy.blahaj.zone
on 06 Jun 00:13
nextcollapse
I’ve worked on supposed “Agile” teams that operate this way, and worked on an Agile team that actually work ridiculously well. The biggest issue with Agile isn’t the philosophy, it’s when management starts using it to cut costs. This comment is what it turns into. Notice that every single one of these points lower cost. But one of the main assumptions of Agile is that the workers control the work, managers support the workers. The places I’ve been where Agile didn’t work it was because management was unwilling to buy into this basic assumption, then use Agile as a crutch for not giving the team what they needed to be successful.
The one successful team I was on that was Agile, the entire group of around 12 worked directly with the customer, and our manager’s role was to ask “what do you need”. It was hands down the best dev role I was ever in (before I became a teacher).
skoberlink@lemmy.world
on 06 Jun 00:25
nextcollapse
I understand the frustration; almost nowhere does agile “right”. However, this is a gross misrepresentation of the philosophy.
Specifically it leaves out and ignores this very important part:
That is, while there is value in the items on
the right, we value the items on the left more.
As seen on agilemanifesto.org
The base philosophy is meant to remind us what we are here to do: make software (or whatever project we’re working on), not become dogmatic about processes or tools or get bogged down in peripheral documentation.
natecox@programming.dev
on 06 Jun 00:51
nextcollapse
This just in: intentionally misrepresenting something has a 100% chance of it being misrepresented.
Let’s try again:
proper tools are important, but not as important as the people using them
documentation is important, but not as important as the software functioning correctly
working with the customer to accomplish their needs is more important than adhering to the letter of a contract
plans are important, but dogmatically applying them above the spirit of their intent is harmful
Windex007@lemmy.world
on 06 Jun 01:01
nextcollapse
I’ll rephrase them, except in good faith:
Talking directly to the people about the work is better than a 95 state JIRA pipeline
Document your finished working work, not every broken POC, because that’s a waste of time
If the contract isn’t actually going to meet the desires of your stakeholders, negotiate one that will
If you realize the plan sucks, make a better plan.
My company paid to have Kent Beck come to workshop with our Sr devs. I expected to dislike him, but he won me over pretty quick.
I don’t remember what it was, but someone was like “Kent, we do X like you recommend in the manifesto, but it creates Y, and Z problem for us”
And he was like “So, in your situation it isn’t providing value?”
Guy was like “No”
“Then stop doing it.”
It’s not hard. It’s the most fucking common sense shit. I feel bad for them because these guys came from a world where there were these process bibles that people were following. So they wrote like, basically a letter saying “if your Bible doesn’t serve you, don’t follow it”
And all these businesses dummies were like “oh look, a NEW bible we can mindlessly follow”
atzanteol@sh.itjust.works
on 06 Jun 03:39
nextcollapse
Agile development reminds me of the Life of Brian.
He’s giving sensible and well meaning life advice but all the people want is to follow the gourd.
best_username_ever@sh.itjust.works
on 06 Jun 04:36
collapse
It assumes that: devs can and have the right to talk to the final user, devs can negotiate anything, and devs can make plans. Where I’ve used agile, the whole circus was taken hostage by the managers and there was nothing you could do about it.
You’ll tell me it’s not real agile, but it’s like real communism, I’ve never seen it.
I mean, I’ve never seen a real platypus but I’m not going to use that as a justification for why they can’t exist.
I don’t know what to tell you. It’s a spectrum. I’ve worked in shops that claimed to be agile but to them, that just meant JIRA and story points. I’ve worked at places where agile meant having daily standups.
And I’ve worked places where there actually was a genuine attempt, and that was an awesome place to work.
DirigibleProtein@aussie.zone
on 06 Jun 01:18
collapse
This has been my experience of agile in multiple workplaces.
Also interesting, successful software projects don’t just finish and die. They keep on going and adapt changes and implement new features. If we have a successful project that goes on for a decade but we have a clusterfuck of a project which blows up each year for the same time period, by this metric you’ll have only a 10% success rate.
It applies to more things than software projects. Like new companies keep innovating until they succeed. Political organizations keep pressing for change until they get some small gain. People are eager to throw themselves at work until they get something they care about…
WhatAmLemmy@lemmy.world
on 06 Jun 00:05
nextcollapse
One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is “Working Software over Comprehensive Documentation.”
Requirements ≠ Documentation. Any project with CLEAR requirements will be most likely to succeed. The hard part is the clear requirements, and not deviating.
One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”
The inability of management to conduct productive meetings is even more well-known than their inability to conduct a decent hiring process, and we all know how broken that is.
The study’s sample and methodology are not linked so I suspect a huge bias, in that the projects succeeding sans-Agile have been successful without it long term, while the Agile projects chose Agile because they were unsuccessful pre-adoption — you don’t adopt agile if you were already successfully delivering projects.
Aurenkin@sh.itjust.works
on 06 Jun 00:46
nextcollapse
Yes, and daily standups are not a requirement of agile in any way. The whole point is people over process and adapting to change rather than following a plan so if standups aren’t working you should stop doing them rather than following a rigid process!
atzanteol@sh.itjust.works
on 06 Jun 03:33
collapse
💯
Agile is not an excuse to be stupid. If you need documentation then fucking do documentation. If your stand-ups suck then either change them or stop. You don’t just do things “because agile”.
best_username_ever@sh.itjust.works
on 06 Jun 04:25
collapse
Most companies I’ve worked for “do agile because agile” and everything revolves around agile. And you can’t change this because they decide and they have the money.
I was going to say most of this, too. I’m a big adherent of BDD, which works well with agile. It clarifies what everyone is working on without getting weighed down in unnecessary minutiae or “documentation for paperworks sake”… it lives and evolves with the project, and at the end becomes both testing criteria and the measurement of success.
snooggums@midwest.social
on 06 Jun 02:15
nextcollapse
Requirements ≠ Documentation.
They are part of documentation, but not all documentation.
The difference is in exact wording
Agile: the software shall properly authticate a user within our active directory.
Documention : user authentication will be provided by functions ”valisate username” as described in section 14,7 subsection 4, ”validate password” as described in section 16.2 and validate the correct pasword as described in section 23.4.Proper authication to the correct use group shall comply with the requirements in document 654689 section 64.7 subsection 17
So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.
I think you’re confusing documentation with specification.
Requirements are specified. They are the goals and the conditions in which they are met. Documentation just means paper trails on how things were designed and are expected to work.
Requirements drive the project. Documentation always lag behind the project.
If you write it down it is documentation. When requirements are written down, they are documented! Requirements are not the same thing as specifications either, but both are documentation!
You are saying that only technical documentation counts as documentation.
It matters nothing if you write down something. For a project, only the requirements specification matters. The system requirements specification document lists exactly what you need to deliver and under which conditions. It matters nothing if you write a README.md or post something in a random wiki.
Requirements are not the same thing as specifications either, but both are documentation!
Aurenkin@sh.itjust.works
on 06 Jun 00:24
nextcollapse
Note that this is failure to deliver on time, not failure to deliver full stop.
I also think a lot of places claim to be agile, but don’t follow or understand the principles at all. Another commenter here is the perfect example of that where they say the opposite of what’s in the agile manifesto and claim that it’s a representation of what it says.
Maybe that’s a fundamental problem with agile. It’s just a set of loose principles rather than a concrete methodology being pushed for by a company and it has therefore been bastardised by consulting companies and scrum masters claiming to teach the checklist of practices that will make your company agile. Such a checklist does not exist, it’s just a set of ideas to keep in mind while you work out the detailed processes or lack thereof that work for you.
For anyone that wants to refresh their memory on the agile manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more.
snooggums@midwest.social
on 06 Jun 02:14
nextcollapse
The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.
It sucks for any large group that requires a lot of coordination. Some parts of it are still helpful as part of a blended process, like more collaboration with the customer and responding to change, but those can easily derail a project if not everyone is on the same page through scope creep or losing sight of long term goals.
tyler@programming.dev
on 06 Jun 03:07
nextcollapse
I wonder why anyone would downvote you. to break down what you said:
The primary problem is using agile all the time instead of when it is actually intended to be used
this applies to everything in life. zero reason to downvote this unless you’re a zealot who doesn’t understand nuance
short term work that needs to be done quickly by a small team that are all on the same page already.
the whole point of agile is to be short term, maybe your downvoter thinks that the team doesn’t need to be on the same page??? don’t know how that is in any way a good idea. it means you haven’t done a good job communicating…
Some parts of it are still helpful as part of a blended process, like more collaboration with the customer and responding to change, but those can easily derail a project if not everyone is on the same page through scope creep or losing sight of long term goals.
anyone that disagrees with this hasn’t actually gone through with Agile according to all the tenets. It sucks for anything more than the tiniest projects that don’t need long term maintainability. I’m guessing this is where someone disagrees, but I can’t fathom why. Maybe they’ve only worked at one place, they think it actually is working, yet haven’t been there long enough to see the downsides or something.
atzanteol@sh.itjust.works
on 06 Jun 03:29
nextcollapse
There is nothing in the agile tenets about only using it for short term projects. I’ve had very successful multi-year agile projects.
Frankly “agile” just goes over most people’s heads. They think it means sprints and stand-ups with no documentation.
A large and complex system with an API and interacts with multiple other systems that is maintained over multiple years will be killed by agile through scope creep and inconsistent implementation when there is staff turnover. People will get great ideas that break other things snd without a cohesive vision across the team, things will be missed and unfinished because people focus on their part and not the whole.
You can add the structure to keep things coherent and spend more time doing documetation up front so people can review the API and do it right the first time instead of redoing it multiple times.
Agile is great for some projects, but ataff turnover, coordination, and meeting any kind of complex external requiirements means it isn’t a great fit for all projects.
I’m curious about why you think this. I’ve seen complex multi year efforts succeed and continue to evolve with agile principles in mind. What specific part of agile do you think would necessarily cause the issues you mentioned?
I’ve used a wrench to hanmer in a nail more than once, but that doesn’t mean it was the best tool for the job.
It isn’t that agile can’t be used for something big, but that the design will likelyntun into hard requirements that must be approached certain ways and at thst point you are using agile to do waterfall. If it improves communication earlier in the process (which waterfall does not prohibit) that is great!
Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can’t accommodate any changes because the process does not have room for those.
This is why this whole “things need to be planned” crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.
Don’t blame Agile for your inability to plan. No one forces you not to plan ahead.
Aurenkin@sh.itjust.works
on 06 Jun 03:28
nextcollapse
I don’t understand what you mean, why would coordinating across a large group be against the agile principles? It sounds like the main issue here is lack of communication and planning which are both important parts of any process including one based on agile.
Planning becomes more important for a larger project but if you hyper focus on sticking to the plan even if things change you can end up delivering something that is not useful for your customers, so I think the principles still make sense there.
The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.
I think you got it entirely backwards.
The whole point of Agile is being able to avoid the “big design up front” approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you’re picking up along the way.
The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.
tyler@programming.dev
on 06 Jun 02:50
nextcollapse
Agile was designed for contractors to deliver contract work. It’s a terrible design for any sort of sustainable business plan, hence “working software over comprehensive documentation”. That line right there causes the majority of outages you as a consumer encounter.
Aurenkin@sh.itjust.works
on 06 Jun 03:06
nextcollapse
Would you rather have working software or a bunch of documentation? If your software is having outages then by definition it is not working. If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work per “working software over comprehensive documentation”. Maybe I’m missing something but I don’t see the contradiction here.
If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work
Or create a better UI that doesn’t require so much documentation.
pivot_root@lemmy.world
on 06 Jun 03:59
nextcollapse
This assumes front-end development.
From a (dev)ops perspective, if I had a vendor hand me a tarball instead of proper documentation, I’d look very far away from their company. It isn’t a matter of if shit goes wrong, but when. And when that shit goes wrong, having comprehensive documentation about the architecture and configuration is going to be a lot more useful than having to piece it together yourself in the middle of an outage.
But that’s what agile sounds like to management. They don’t understand the “it’s held together by hopes and dreams” communication, because all they see is something that appears to work. So why would they invest anything else in it.
mctoasterson@reddthat.com
on 06 Jun 05:20
collapse
This is the most accurate description of anything that’s ever been written.
In long term development, sensible and updated documentation is far more important than the software working constantly. You will have downtimes. You will have times before the PoC is ready.
But if your documentation sucks or is inexistent, you cannot fix any problems that arise and will commit a ton of debt the moment people change and knowledge leaves the company.
Fair enough, at my job the code working consistently is absolutely the number one priority at all times but I can imagine that there are some places where this is not true. If working software isn’t imporant then I agree agile is probably not the right choice
It’s worth pointing out though that having insufficient documentation is not a feature of agile. Sounds more like laziness or misplaced priorities to me as documentation is called out as being useful in the agile principles, just not as important as working software.
Especially that working software over comprehensive documentation part, which can be automated so easily if done right.
There’s so much value in TDD and providing a way to do integration and automated UI tests early on in a project, yet none of the companies I’ve worked at made use of it.
Also automated documentation tools like Swagger are almost criminally underutilised.
The other mistake everyone makes is “agile = faster and cheaper” . This results in corner cutting and unreasonable deadlines.
fruitycoder@sh.itjust.works
on 06 Jun 08:22
collapse
Gotta remember it was a response to water fall. Docs didn’t mean the man page or the wiki, they ment the spec sheet, PowerPoint’s, graphs, white papers, diagrams, aggreements and contracts, etc. Where you might go MOUNTHS making paperwork before you ran a single line of logic.
Docs SHOULD be the last resort of an engineer if your UX just can’t be intuitive in some way or some problem domain just can’t be simple. You should first strive to make it work well.
For example Lemmy, it just would work if you needed to read the Lemmy user guide first to post on Lemmy. That would indicate bad UX, but that was how it was back in the day.
Unified process, which, despite usually not being called that way and/or being codified in the way it is nowadays, is how virtually all early software companies did their development work post-punchcards (when you no longer had to get things done in a single step).
It’s why the “agile is better because iterative hoooo!” is so laughable, because even though we didn’t yet call it iterative - as a distinction from pre-planned, since we thought in punchcards+mainframe vs after that - we did iterative work. Of course we did, software development is naturally iterative and Waterfall was the contrived contrasting example of how a non-iterative process would look.
lysdexic@programming.dev
on 06 Jun 04:09
nextcollapse
Note that this is failure to deliver on time, not failure to deliver full stop.
It’s also important to note that the Hallmark of non-Agile teams is de-scoping and under-delivering. It’s easy to deliver something on time if you switch your delivery goals and remove/half-bake features to technically meet requirements while not meeting requirements.
magic_lobster_party@kbin.run
on 06 Jun 09:18
collapse
That is, while there is value in the items on
the right, we value the items on the left more.
This is funnily the part of the manifesto most have trouble understanding.
1800doctorb@lemmy.world
on 06 Jun 00:24
nextcollapse
I’m curious what they mean by “failure.” I read the article but didn’t get a clear definition. Isn’t one of the expected outcomes of agile the ability to experiment rapidly and move on when the experiment fails?
So what if you fail 300% more? If you’re able to get 300% more ideas to the stage where you can test their viability, then it’s a success.
I just hate how companies cling to agile like it’s some kind of cult. Like a company I know gave all the employees very nice swag embroidered with a big “agile development” slogan on it like your development methodology is supposed to be a source of pride or something. Of course like most companies they don’t really follow agile practice very much except where they can use it as an excuse to skimp on requirements and such.
Aa someone who has misspent a budget before - you’re making it sound like a lot more people in the company care about the topic than what’s happening in real life.
I organize some events in our office every now and then. For example, one of them is a sort of competition/race/quiz/whatever - completely optional, but I get about 75% of the office to join, which in my experience - that’s huge, nobody joins any type of other events in such magnitude, usual rates are at 30-40%. The big bosses approve it because “morale” and “team building”. The people like it because it’s actually fun. So I get a budget to spend on this event, and we use it to buy “prizes” for literally everyone participating. Which means they’re shitty prizes, but hey, it’s not about winning first place, it’s about making some jokes at the bosses’ expense, on company time.
The way the process works is: all my bosses already know how this money is spent, and they approve. But because I need the money, it has to go through finance. And they involve marketing/PR guys. And these guys insist on having the fucking logo on everything. At the end of the day everyone is going home with several items (backpack, external battery, pen, umbrella, Swiss army knife etc) with the company logo on them, which is goddamn ridiculous. It’s actually one of the reasons I always refuse to receive items, even if the budget includes the organizers - because I really hate the branding aspect.
But all that aside - you see the aftermath of this event and you’ll draw the conclusion that we just spent the day in a corporate culture workshop, when in fact we were answering silly questions and getting imaginary points the entire day, but there’s ONE guy in ONE department who can’t let things slide. So… Idk man. Take it with a grain of salt next time. The agile dudes probably did it to get away from other things for a few hours, and they got the budget to also give something back to the coworkers. But not everyone really cares about agile, they’re just going through the motions.
Oh boy I hate the branding. I’ve gotten some really nice swag this way but I can’t use them because they’re so obnoxiously branded. I’m not going to the beach for example with a Dickhead Company stamped large on the beach towel, or going out of the house with it on the umbrella. Pens, battery are ok.
Oh yeah, I feel that. I got a nice beach towel with my company’s name on it some years ago, of course I couldn’t take it to the beach, I’d feel silly. But on the other hand - nobody sees it if I use it in the shower. Man, that company name has touched my dick&balls so many times I’m thinking I should marry it at this point.
I always try to make them put the branding in shitty places. For the umbrella I got them to print it on the classy wooden handle, instead of the fabric, exactly where you’d hold the thing. That way it’s still usable, you just need to hold your hand over the brand name. And on some other shit like wireless earbuds & smaller objects, the guys doing the printing can sometimes provide smaller velvety satchels to put the objects in, kind of like a gift bag, and I can usually print on those. Then you’re just left with the plain unbranded object when you inevitably throw away the satchel.
According to the study, putting a specification in place before development begins can result in a 50 percent increase in success, and making sure the requirements are accurate to the real-world problem can lead to a 57 percent increase.
Is this not self-evident to most teams? Of course you will not reach your destination if you don’t know where you’re going.
iamtherealwalrus@lemmy.world
on 06 Jun 03:41
nextcollapse
On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development. Often claiming that we can’t know the requirements up-front, because we’re agile.
pivot_root@lemmy.world
on 06 Jun 03:57
nextcollapse
For your sake, I hope your employment was agile as well. Those jobs sound like they were dumpster fires waiting to happen.
Also seems like a shitty get-outta-jail-free card. With no design in place, timelines and acceptance criteria can’t be enforced. “Of course we’re done now, we just decided that we’re done!”
lysdexic@programming.dev
on 06 Jun 04:06
nextcollapse
On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development.
I don’t think this is an Agile thing, at all. I mean, look at what Agile’s main trait: multiple iterations with acceptance testing and product&design reviews. At each iteration there is planning. At each planning session you review/create tickets tracking goals and tasks. This makes it abundantly clear that Agile is based in your ability to plan for the long term but break/adapt progress into multiple short-term plans.
We’re so agile the sprint became a time-block framework rather than a lock-down of tickets that we certainly will finish. (In part because stuff comes up within sprint.)
I’ve been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.
The main factors in burning out we’re always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It’s not Agile’s fault that your manager wants a feature out in half the time while looming dismissals over your head.
It’s not Agile’s fault that stack ranking developers results in hostile team environments where team members don’t help out people and even go as far as putting roadblocks elsewhere so that they aren’t the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.
best_username_ever@sh.itjust.works
on 06 Jun 04:09
nextcollapse
It’s not Agile’s fault
that managers want to stay in control of everything, and they decide whether they do it or not.
It’s like real communism: it’s perfect but it’s not possible to implement in our universe.
that managers want to stay in control of everything, and they decide whether they do it or not.
That’s fine, it’s a call from the manager.
That doesn’t make it Agile’s fault though. In fact, one of the key principles of Agile is providing developers with the support they need. Blaming Agile for the manager single-handledly pushing for something in spite of any feedback does not have any basis.
best_username_ever@sh.itjust.works
on 06 Jun 10:49
collapse
I have a cure for all cancers. Except that bodies refuse to use its molecules, but it still cures cancer in theory. That’s how agile have always been used around me.
Agile wants to empower devs, but managers do not want this.
This is why you should always visualise and multiply by 4 when people ask for an estimate. If someone gives me a ticket that’s expected to take me 1 day I’ll let them know it’s very likely not going to be done in 1 day but rather 4 which I’ll finish comfortably in 3.
Ranking devs is toxic though
Semi_Hemi_Demigod@lemmy.world
on 06 Jun 12:39
collapse
“Never tell them how long it will really take! How else will people see you as a miracle worker?” - Scotty
Grandwolf319@sh.itjust.works
on 06 Jun 12:57
collapse
It’s not Agile’s fault
Yes, yes it is. You don’t judge a system by some ideal that can’t be achieved. If it’s a system meant for humans you judge it based on what it does to said humans.
If agile makes managers more insufferable, then maybe it’s not a good tool for the problem at hand, working in companies with managers.
Agile is not a system. It’s a set of principles, set by the Agile manifesto.
The Agile manifesto boils down to a set of priorities that aren’t even set as absolutes.
I strongly recommend you read upon Agile before blaming things you don’t like on things you don’t understand .
Grandwolf319@sh.itjust.works
on 09 Jun 12:21
collapse
I have read those principles, many years ago.
Those principles sound great but they are not compatible with management.
If management is gonna be part of the picture then agile principles are not beneficial to a developer experience, regardless of what unachievable ideal they talk about.
belllllla@discuss.online
on 06 Jun 04:08
nextcollapse
F4M] Available for hookup, sexting and FaceTime 💦🌬️🌊🌊🍉🍉both in blowjob, anal doggy style and more🍉🍉🍉🍉🍉
TELEGM:Mialisa100
Number:+1 480-696-8297
pixxelkick@lemmy.world
on 06 Jun 05:45
nextcollapse
I’ve literally never actually seen a self proclaimed “agile” company at all get agile right.
If your developers are on teams that are tied to and own specific projects, that’s not agile.
If you involve the clients in the scrum meeting, that’s not agile.
If your devs aren’t often opening PRs on a variety of different projects all over the place, you very likely aren’t agile.
If your devs can’t open up a PR in git as the way to perform devops, you aren’t agile.
Instead you have most of the time devs rotting away on the sane project forever and everyone on “teams” siloed away from each other with very little criss talk, devops is maintained by like 1-2 ppl by hand, and tonnes of ppl all the time keep getting stuck on specific chunks of domains because “they worked on it so they knpw how it works”
Shortly after the dev burns out because no one can keep working on the same 1 thing endlessly and not slowly come to fucking losthe their job.
Everyone forgets the first core principle if an agile workplace and literally its namesake us devs gotta be allowed to free roam.
Let them take a break and go work on another project or chunk of the domain. Let them go tinker with another problem. Let them pop in to help another group out with something.
A really helpful metric, to be honest, of agile “health” at your company is monitor how many distinct repos devs are opening PRs into per year on average.
A healthy company should often see many devs contributing to numerous projects all over the company per year, not just sitting and slowly be coming welded to the hull of ThatOneProject.
I don’t disagree with you (on giving devs some creative freedom), but “Agile” as a process methodology isn’t about developers working on multiple things to keep their interests up.
That’s actually a pretty important part of its original premise.
It’s a big part of why scrum meetings were a thing, as the expectation was any curious dev could just join in to see what’s up, if they like.
Not tying devs down to 1 specific thing is like the cornerstone of agile, and over many years of marketing and corporate bastardization, everyone had completely forgotten that was literally the point.
The whole point of the process was to address 2 things:
That client requirements can’t easily be 100% covered day one (But you still need to get as many as you can!)
To avoid silo’ing and tying devs down to specific things, and running into the one bus rule (“how fucked would this project be if <dev> got hit by a bus?”)
And the prime solution posited is to approach your internal projects the same way open source works. Keep it open and available to the whole company, any dev can check it out, chime in if they’re familiar with a challenge, etc.
One big issue often noted in non-agile companies (aka almost all of them) is that a dev slent ages hacking away at an issue with little success, only to find out far too late someone else in the company already has solved that one before.
An actually agile approach should be way more open and free range. Devs should be constantly encouraged to cross pollinate info, tips, help each other, post about their issues, etc. There should be first class supported communication channels for asking for help and tips company wide.
If your company doesn’t even have a “ask for help on (common topic)” channel for peeps to imfoshare, you are soooooooo far away from being agile yet.
I don’t know man. Nothing in the Agile Manifesto talks about not focusing on one project.
In addition, I think most people (and studies) would agree that “focus” is key to building almost anything of quality. Not flittering about working on shiny pennies of the day. I mean, a key tenant of sprints is “Don’t interrupt the sprint”. The whole concept is about letting developers focus.
The best architectures, requirements, and designs
emerge from self-organizing teams.
It’s an incredibly critical part companies love to completely ignore.
If you assign devs to teams and lock em down, you’ve violated a core principle
And it’s a key role in being able to achieve these two:
Agile processes promote sustainable development.
And
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
This is talked about at length by the likes of Fowler, who talk about how locking devs down us a super fast way to kill sustainable development. It burns devs out fast as hell.
Note that it’s careful not to say on the same project
Thcdenton@lemmy.world
on 06 Jun 06:06
nextcollapse
Agile went through the mgmt human centipede and now it’s an unrecognizable broken system built on conflated ideas. I bet a good number of those projects are ‘agilefall’ anyways.
Kissaki@programming.dev
on 06 Jun 08:01
nextcollapse
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates. ®
Random trademark symbol. What’s the registered trademark here? The dot? “advocates”?
One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed. In comparison, one of the four pillars of the Agile Manifesto is “Working Software over Comprehensive Documentation.”
You need clearly defined requirements to write a good user story. Documentation comes after.
However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. “We don’t need a test team because we’re Agile” is a cost-saving abdication of responsibility.
Precisely, once once have i worked in a company where agile was properly implemented and, yes, user stories were well documented and discussed before being developed. All others are just waterfall in disguise, or Fragile™.
However, while the Agile Manifesto might have its problems, those stem more from its implementation rather than the principles themselves. “We don’t need a test team because we’re Agile” is a cost-saving abdication of responsibility.
You need clearly defined requirements to write a good user story.
This is the main reason the last company I worked for lacked in project delivery. They had just transitioned to Agile, and their whole teams lacked proper Agile experience and the training provided was very superficial. They barely put any time in refining the requirements and this trickled down to developers.
Projects that allow for clear requirements before really starting on them are clearly more likely to succeed than ones that have a higher complexity due to unknowns.
magic_lobster_party@kbin.run
on 06 Jun 09:11
nextcollapse
It’s more about poor planning vs good planning. Of course a project with good planning is more likely to deliver in time.
It’s just to that poor planners tend to use “agile” as an excuse for their poor planning.
In the days before Agile the Waterfall projects failed too. Though not necessarily for being late, they failed because they didn’t deliver the thing that the business thought they were building, they delivered something else due to a misunderstanding. If nothing more, Agile gives more visibility into the process and allows for course correction.
Every time I see a discussion of agile, there are plenty of comments about how mentally exhausting and useless/wasteful the meetings are. And the defenders can only say, “you’re doing meetings wrong!” Maybe if everyone is doing it wrong the process itself is fundamentally flawed and lends itself to misinterpretation.
Semi_Hemi_Demigod@lemmy.world
on 06 Jun 12:35
nextcollapse
I’ve been in agile projects that worked really well and didn’t have soul-sucking, time-wasting meetings. It can be done well, it just isn’t most of the time.
Same, I’ve been on agile projects with quick efficient meetings most of the time. But I’m a project now with a 45 minute standup every morning for like 15 people. The lead just lets people ramble on and try to solve issues in standup. Backlog grooming and sprint plannings get equally sidetracked as well.
Semi_Hemi_Demigod@lemmy.world
on 06 Jun 14:35
nextcollapse
One common thread between these projects was that we used actual, physical note cards to track things. They were also logged in Jira, but the standups were 5-10 people actually standing in a room tracking burn down and status with cards taped to a wall. Nobody wants to be standing for more than 15 minutes, and anything that needed a sidebar was handled with a smaller group in another impromptu meeting.
I agree, in my experience in person stand-ups are much better than online.
People don’t want to sand around and want to get back to their desk.
Parking lot discussions can just be handled in the hall outside the meeting room 90% of the time and don’t require adding a new meeting to a calendar, although if there is only one issue that needs further discussion we just usually let everyone else drop call and handle it then.
Similar, except we only budget for half an hour so as it drags on past the first or sometimes even second hour it takes over lunchtime.
Even when people avoid trying to say anything so as not to drag it out, the mere fact that the meeting is happening means that it will manage to take up the whole block of time and then some.
Ironically I’m starting to wonder if the solution might be MORE rather than fewer meetings, bc people need SOME time to work it all out, so if there were other more focused ones then all that could go there rather than have to take place in the only meeting it can - where it takes up the time of the entire team.
Is it really that unlikely that companies that jumped into the agile hype train do it wrong?
WhiskyTangoFoxtrot@lemmy.world
on 06 Jun 21:17
nextcollapse
Maybe if everyone is doing it wrong the process itself is fundamentally flawed and lends itself to misinterpretation.
Like Communism.
trolololol@lemmy.world
on 06 Jun 22:28
nextcollapse
Just like saying AI will solve all your problems even if you misuse. It’s just like a pattern big companies use to mask when they’re talking out of their asses.
the_artic_one@programming.dev
on 07 Jun 18:58
collapse
There aren’t any meetings that are part of Agile. The point of Agile is that you’re supposed to let teams self-organize and define their own process through iteration but managers hate that so they issue a top-down mandate to implement the Scrum process without allowing anyone outside of management to change it in any way and call it “Agile”.
ICastFist@programming.dev
on 06 Jun 13:27
nextcollapse
With 65 percent of projects adopting Agile practices failing to be delivered on time
They’re not “failing to deliver”, they’re being Agile in disappointing everyone involved!
Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.
Which shouldn’t surprise anyone, but I know some managers, directors and users loathe the idea of the people who’ll do the actual job having any say other than “yes, sir”.
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.
Good documentation is critical and process-agnostic. If people can read and understand it, it’s good. It’s something that can be used as a shield and weapon against users/higher ups who want too much, it can create a trail of responsibility.
Theharpyeagle@lemmy.world
on 06 Jun 18:14
nextcollapse
Honestly a little confused by the hatred of agile. As anything that is heavily maligned or exalted in tech, it’s a tool that may or may not work for your team and project. Personally I like agile, or at least the version of it that I’ve been exposed to. No days or weeks of design meetings, just “hey we want this feature” and it’s in an item and ready to go. I also find effort points to be one of the more fair ways to gauge dev performance.
Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.
I’m not really sure how this relates to agile. A good team listens to the concerns of its members regardless of what strategy they use.
A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.
Again, not sure how shipping with bugs is an agile issue. My understanding of “fail fast” is “try out individual features to quickly see if they work instead of including them in a large update”, not “release features as fast as possible even if they’re poorly tested and full of bugs.” Our team got itself into a “quality crisis” while using agile, but we got back out of it with the same system. It was way more about improving QA practices than the strategy itself.
The article kinda hand waves the fact that the study was not only commissioned by Engprax, but published by the author of the book “Impact Engineering,” conveniently available on Engprax’s site. Not to say this necessarily invalidates the study, or that agile hasn’t had its fair share of cash grabs, but it makes me doubt the objectivity of the research. Granted, Ali seems like he’s no hack when it comes to engineering.
Remember that it is frightingly easy to lie with statistics. This is just a correlation. Smaller companies (whom may have less experience, worse less-paid engineers) may prefer agile due to the amount of up-front effort for things like waterfall.
Projects where engineers felt they had the freedom to discuss and address problems were 87 percent more likely to succeed.
is not always the norm. I’ve worked in agile environments where we had to work fast because the large corporate stakeholder had such a rapid turnaround that discussing and addressing problems meant slowing the process down, so no one wanted to be the one to say anything.
Agile feels like one of those things that works well on paper and when practiced properly, but when you get the wrong type of stakeholders involved, their lack of understanding rushes everything and makes the process and the final product bad for everyone.
Theharpyeagle@lemmy.world
on 07 Jun 16:32
collapse
I definitely agree, but that’s true of any system. The particulars of the pitfalls may vary, but a good system can’t overpower bad management. We mitigate the stakeholder issue by having BAs that act as the liason between devs and stakeholders, knowing just enough about the dev side to manage expectations while helping to prioritize the things stakeholders want most. Our stakes are also, mercifully, pretty aware that they don’t always know what will be complex and what will be trivial, so they accept the effort we assign to items.
I liked agile as it was practiced in the “Extreme Programming” days.
Rather than attempt to design the perfect system from the get-go, you accept that software architecture is a living, moving target that needs to evolve as your understanding of the problem evolves.
Rather than stare down a mountain of ill-defined work, you have neat little user stories that can be completed in a few days at most and you just move around some Kanban cards instead of feeding a soul-sucking bureaucratic ticketing, time tracking and monitoring system.
Rather than sweat and enter crunch mode for deadlines, the project owners see how many user stories (or story points or perfect hours) the team completes per week and can use a velocity graph / burndown chart to estimate when all work will be completed.
.
But it’s just a corporate buzzword now. “We’re agile” often enough means “we have no plan, take no responsibility and expect the team to wing it somehow” or “we cargo cult a few agile ideas that feel good to management, like endless meetings with infinite course changes where everyone gives feel-good responses to the managers.”
Having a goal, a specification, a release plan, a vision and someone who is responsible and approachable (the “project owner”) are all part of the agile manifesto, not something it tries to do away with. I would be sad if agile faces the same fate as the waterfall model back in its time and even sadder if we return to the time-tracking-ticket-system-with-Gantt-chart hell as the default.
Maybe we need a new term or an “agility index” to separate the cases of “incompetent manager uses buzzword to cover up messy planning” from the cases of “project owner with a clearly defined goal creates a low-bureaucracy work environment for his team.” :)
TheGiantKorean@lemmy.world
on 07 Jun 04:05
collapse
Someone would look at our process and say “that’s not agile!” and they might be correct, technically speaking. I don’t personally care what it’s called as long as it works.
We agree to requirements up front with our customer; we might change stuff as we go along if our customer realizes that what they asked for won’t work (this happens occasionally), which is fine, but otherwise we don’t let them change stuff around on a whim, and we don’t allow scope creep. If they want a new feature, that’s version 2 (or 3, or 4).
We don’t meet very frequently. We do check in to make sure we’re on target, and deliver features incrementally when it makes sense to do so. We do sprints. We talk about when things are working and when they aren’t, but only when we think it’s a good time to do so.
At the end of the day, you need to tailor the process to your needs and what makes sense to you and your team.
threaded - newest
This is the best summary I could come up with:
Even though the research commissioned by consultancy Engprax could be seen as a thinly veiled plug for Impact Engineering methodology, it feeds into the suspicion that the Agile Manifesto might not be all it’s cracked up to be.
One standout statistic was that projects with clear requirements documented before development started were 97 percent more likely to succeed.
“Our research has shown that what matters when it comes to delivering high-quality software on time and within budget is a robust requirements engineering process and having the psychological safety to discuss and solve problems when they emerge, whilst taking steps to prevent developer burnout.”
A neverending stream of patches indicates that quality might not be what it once was, and code turning up in an unfinished or ill-considered state have all been attributed to Agile practices.
One Agile developer criticized the daily stand-up element, describing it to The Register as “a feast of regurgitation.”
In highlighting the need to understand the requirements before development begins, the research charts a path between Agile purists and Waterfall advocates.
The original article contains 501 words, the summary contains 175 words. Saved 65%. I’m a bot and I’m open source!
.
Agile software development bases on four core values (paraphrased to make them more drastic but not change them in their meaning):
I am not surprised that this fails miserably.
eXtreme Go Horse Methodology
I’ve worked on supposed “Agile” teams that operate this way, and worked on an Agile team that actually work ridiculously well. The biggest issue with Agile isn’t the philosophy, it’s when management starts using it to cut costs. This comment is what it turns into. Notice that every single one of these points lower cost. But one of the main assumptions of Agile is that the workers control the work, managers support the workers. The places I’ve been where Agile didn’t work it was because management was unwilling to buy into this basic assumption, then use Agile as a crutch for not giving the team what they needed to be successful.
The one successful team I was on that was Agile, the entire group of around 12 worked directly with the customer, and our manager’s role was to ask “what do you need”. It was hands down the best dev role I was ever in (before I became a teacher).
I understand the frustration; almost nowhere does agile “right”. However, this is a gross misrepresentation of the philosophy.
Specifically it leaves out and ignores this very important part:
As seen on agilemanifesto.org
The base philosophy is meant to remind us what we are here to do: make software (or whatever project we’re working on), not become dogmatic about processes or tools or get bogged down in peripheral documentation.
This just in: intentionally misrepresenting something has a 100% chance of it being misrepresented.
Let’s try again:
I’ll rephrase them, except in good faith:
Talking directly to the people about the work is better than a 95 state JIRA pipeline
Document your finished working work, not every broken POC, because that’s a waste of time
If the contract isn’t actually going to meet the desires of your stakeholders, negotiate one that will
If you realize the plan sucks, make a better plan.
My company paid to have Kent Beck come to workshop with our Sr devs. I expected to dislike him, but he won me over pretty quick.
I don’t remember what it was, but someone was like “Kent, we do X like you recommend in the manifesto, but it creates Y, and Z problem for us”
And he was like “So, in your situation it isn’t providing value?”
Guy was like “No”
“Then stop doing it.”
It’s not hard. It’s the most fucking common sense shit. I feel bad for them because these guys came from a world where there were these process bibles that people were following. So they wrote like, basically a letter saying “if your Bible doesn’t serve you, don’t follow it”
And all these businesses dummies were like “oh look, a NEW bible we can mindlessly follow”
Agile development reminds me of the Life of Brian.
He’s giving sensible and well meaning life advice but all the people want is to follow the gourd.
It assumes that: devs can and have the right to talk to the final user, devs can negotiate anything, and devs can make plans. Where I’ve used agile, the whole circus was taken hostage by the managers and there was nothing you could do about it.
You’ll tell me it’s not real agile, but it’s like real communism, I’ve never seen it.
I mean, I’ve never seen a real platypus but I’m not going to use that as a justification for why they can’t exist.
I don’t know what to tell you. It’s a spectrum. I’ve worked in shops that claimed to be agile but to them, that just meant JIRA and story points. I’ve worked at places where agile meant having daily standups.
And I’ve worked places where there actually was a genuine attempt, and that was an awesome place to work.
This has been my experience of agile in multiple workplaces.
Hum… That implies that at least 30% of some subclass of projects are successful.
Also interesting, successful software projects don’t just finish and die. They keep on going and adapt changes and implement new features. If we have a successful project that goes on for a decade but we have a clusterfuck of a project which blows up each year for the same time period, by this metric you’ll have only a 10% success rate.
That’s a very good point.
It applies to more things than software projects. Like new companies keep innovating until they succeed. Political organizations keep pressing for change until they get some small gain. People are eager to throw themselves at work until they get something they care about…
Has anyone asked Jared for his input?
I think he’s still in prison
Requirements ≠ Documentation. Any project with CLEAR requirements will be most likely to succeed. The hard part is the clear requirements, and not deviating.
The inability of management to conduct productive meetings is even more well-known than their inability to conduct a decent hiring process, and we all know how broken that is.
The study’s sample and methodology are not linked so I suspect a huge bias, in that the projects succeeding sans-Agile have been successful without it long term, while the Agile projects chose Agile because they were unsuccessful pre-adoption — you don’t adopt agile if you were already successfully delivering projects.
Yes, and daily standups are not a requirement of agile in any way. The whole point is people over process and adapting to change rather than following a plan so if standups aren’t working you should stop doing them rather than following a rigid process!
💯
Agile is not an excuse to be stupid. If you need documentation then fucking do documentation. If your stand-ups suck then either change them or stop. You don’t just do things “because agile”.
Most companies I’ve worked for “do agile because agile” and everything revolves around agile. And you can’t change this because they decide and they have the money.
I was going to say most of this, too. I’m a big adherent of BDD, which works well with agile. It clarifies what everyone is working on without getting weighed down in unnecessary minutiae or “documentation for paperworks sake”… it lives and evolves with the project, and at the end becomes both testing criteria and the measurement of success.
They are part of documentation, but not all documentation.
The difference is in exact wording Agile: the software shall properly authticate a user within our active directory.
Documention : user authentication will be provided by functions ”valisate username” as described in section 14,7 subsection 4, ”validate password” as described in section 16.2 and validate the correct pasword as described in section 23.4.Proper authication to the correct use group shall comply with the requirements in document 654689 section 64.7 subsection 17
Yes there is a difference and one is better…
So you started with the need to authenticate, which should be documented in the requirements. You know, the things that are required to happen.
The details on HOW to authenticate are ALSO documentation. Not all documentation describes functionality.
If you need documentation then do documentation. Nothing in the agile methodology tells you not to.
I think you’re confusing documentation with specification.
Requirements are specified. They are the goals and the conditions in which they are met. Documentation just means paper trails on how things were designed and are expected to work.
Requirements drive the project. Documentation always lag behind the project.
If you write it down it is documentation. When requirements are written down, they are documented! Requirements are not the same thing as specifications either, but both are documentation!
You are saying that only technical documentation counts as documentation.
I think you’re not getting the point.
It matters nothing if you write down something. For a project, only the requirements specification matters. The system requirements specification document lists exactly what you need to deliver and under which conditions. It matters nothing if you write a README.md or post something in a random wiki.
en.wikipedia.org/…/System_requirements_specificat…
No gold likes on lemmy? So sad…
You can use whatever images you wish:-)
<img alt="img" src="https://image.similarpng.com/very-thumbnail/2020/05/Gold-like-symbol-Trophy-on-transparent-background-PNG.png">
Note that this is failure to deliver on time, not failure to deliver full stop.
I also think a lot of places claim to be agile, but don’t follow or understand the principles at all. Another commenter here is the perfect example of that where they say the opposite of what’s in the agile manifesto and claim that it’s a representation of what it says.
Maybe that’s a fundamental problem with agile. It’s just a set of loose principles rather than a concrete methodology being pushed for by a company and it has therefore been bastardised by consulting companies and scrum masters claiming to teach the checklist of practices that will make your company agile. Such a checklist does not exist, it’s just a set of ideas to keep in mind while you work out the detailed processes or lack thereof that work for you.
For anyone that wants to refresh their memory on the agile manifesto:
The primary problem is using agile all the time instead of when it is actually intended to be used: short term work that needs to be done quickly by a small team that are all on the same page already.
It sucks for any large group that requires a lot of coordination. Some parts of it are still helpful as part of a blended process, like more collaboration with the customer and responding to change, but those can easily derail a project if not everyone is on the same page through scope creep or losing sight of long term goals.
I wonder why anyone would downvote you. to break down what you said:
this applies to everything in life. zero reason to downvote this unless you’re a zealot who doesn’t understand nuance
the whole point of agile is to be short term, maybe your downvoter thinks that the team doesn’t need to be on the same page??? don’t know how that is in any way a good idea. it means you haven’t done a good job communicating…
anyone that disagrees with this hasn’t actually gone through with Agile according to all the tenets. It sucks for anything more than the tiniest projects that don’t need long term maintainability. I’m guessing this is where someone disagrees, but I can’t fathom why. Maybe they’ve only worked at one place, they think it actually is working, yet haven’t been there long enough to see the downsides or something.
There is nothing in the agile tenets about only using it for short term projects. I’ve had very successful multi-year agile projects.
Frankly “agile” just goes over most people’s heads. They think it means sprints and stand-ups with no documentation.
A large and complex system with an API and interacts with multiple other systems that is maintained over multiple years will be killed by agile through scope creep and inconsistent implementation when there is staff turnover. People will get great ideas that break other things snd without a cohesive vision across the team, things will be missed and unfinished because people focus on their part and not the whole.
You can add the structure to keep things coherent and spend more time doing documetation up front so people can review the API and do it right the first time instead of redoing it multiple times.
Agile is great for some projects, but ataff turnover, coordination, and meeting any kind of complex external requiirements means it isn’t a great fit for all projects.
I’m curious about why you think this. I’ve seen complex multi year efforts succeed and continue to evolve with agile principles in mind. What specific part of agile do you think would necessarily cause the issues you mentioned?
I’ve used a wrench to hanmer in a nail more than once, but that doesn’t mean it was the best tool for the job.
It isn’t that agile can’t be used for something big, but that the design will likelyntun into hard requirements that must be approached certain ways and at thst point you are using agile to do waterfall. If it improves communication earlier in the process (which waterfall does not prohibit) that is great!
Not really. The whole point of Agile is to iterate. This means short development cycles which include review and design rounds to adapt to changes that can and will surface throughout the project. The whole point of Agile is to eliminate problems caused by business, project, and technical goals not changing because planning is rigid and can’t accommodate any changes because the process does not have room for those.
This is why this whole “things need to be planned” crowd are simply talking out of ignorance. Agile requires global planning, but on top of this supports design reviews along the way to be able to face changing needs. This requires planning in short-medium-long terms.
Don’t blame Agile for your inability to plan. No one forces you not to plan ahead.
I don’t understand what you mean, why would coordinating across a large group be against the agile principles? It sounds like the main issue here is lack of communication and planning which are both important parts of any process including one based on agile.
Planning becomes more important for a larger project but if you hyper focus on sticking to the plan even if things change you can end up delivering something that is not useful for your customers, so I think the principles still make sense there.
Being able to adapt does not require all of the other parts of agile.
I think you got it entirely backwards.
The whole point of Agile is being able to avoid the “big design up front” approach that kills so many projects, and instead go through multiple design and implementation rounds to adapt your work to the end goal based on what lessons you’re picking up along the way.
The whole point is improving the ability to deliver within long term projects. Hence the need to iterate and to adapt. None of these issues pose a challenge in short term work.
Agile was designed for contractors to deliver contract work. It’s a terrible design for any sort of sustainable business plan, hence “working software over comprehensive documentation”. That line right there causes the majority of outages you as a consumer encounter.
Would you rather have working software or a bunch of documentation? If your software is having outages then by definition it is not working. If documentation is the root cause of that then you should fix that by creating enough documentation to allow your software to continue to work per “working software over comprehensive documentation”. Maybe I’m missing something but I don’t see the contradiction here.
Or create a better UI that doesn’t require so much documentation.
This assumes front-end development.
From a (dev)ops perspective, if I had a vendor hand me a tarball instead of proper documentation, I’d look very far away from their company. It isn’t a matter of if shit goes wrong, but when. And when that shit goes wrong, having comprehensive documentation about the architecture and configuration is going to be a lot more useful than having to piece it together yourself in the middle of an outage.
Yeah, I almost added a clarification for that very point, and see now that I should have.
Sacrilege!! /s
If 2 and 3 happen the game is up. Management killed it.
That’s not agiles fault.
Surely you’re not gonna blame the manager… /s
But that’s what agile sounds like to management. They don’t understand the “it’s held together by hopes and dreams” communication, because all they see is something that appears to work. So why would they invest anything else in it.
This is the most accurate description of anything that’s ever been written.
In long term development, sensible and updated documentation is far more important than the software working constantly. You will have downtimes. You will have times before the PoC is ready.
But if your documentation sucks or is inexistent, you cannot fix any problems that arise and will commit a ton of debt the moment people change and knowledge leaves the company.
Fair enough, at my job the code working consistently is absolutely the number one priority at all times but I can imagine that there are some places where this is not true. If working software isn’t imporant then I agree agile is probably not the right choice
It’s worth pointing out though that having insufficient documentation is not a feature of agile. Sounds more like laziness or misplaced priorities to me as documentation is called out as being useful in the agile principles, just not as important as working software.
Definitely. Most often it’s people misunderstanding the “a over b” of agile as “never do b”.
The very first mistake most people make when reading the agile manifesto is that “a over b” means “don’t do b”.
100% that.
Especially that working software over comprehensive documentation part, which can be automated so easily if done right.
There’s so much value in TDD and providing a way to do integration and automated UI tests early on in a project, yet none of the companies I’ve worked at made use of it.
Also automated documentation tools like Swagger are almost criminally underutilised.
The other mistake everyone makes is “agile = faster and cheaper” . This results in corner cutting and unreasonable deadlines.
Gotta remember it was a response to water fall. Docs didn’t mean the man page or the wiki, they ment the spec sheet, PowerPoint’s, graphs, white papers, diagrams, aggreements and contracts, etc. Where you might go MOUNTHS making paperwork before you ran a single line of logic.
Docs SHOULD be the last resort of an engineer if your UX just can’t be intuitive in some way or some problem domain just can’t be simple. You should first strive to make it work well.
For example Lemmy, it just would work if you needed to read the Lemmy user guide first to post on Lemmy. That would indicate bad UX, but that was how it was back in the day.
It wasn’t, Waterfall in itself was a contrived example of a bad setup. More common was UP, or something UP-like.
Never heard of UP, what is that?
Unified process, which, despite usually not being called that way and/or being codified in the way it is nowadays, is how virtually all early software companies did their development work post-punchcards (when you no longer had to get things done in a single step).
It’s why the “agile is better because iterative hoooo!” is so laughable, because even though we didn’t yet call it iterative - as a distinction from pre-planned, since we thought in punchcards+mainframe vs after that - we did iterative work. Of course we did, software development is naturally iterative and Waterfall was the contrived contrasting example of how a non-iterative process would look.
It’s also important to note that the Hallmark of non-Agile teams is de-scoping and under-delivering. It’s easy to deliver something on time if you switch your delivery goals and remove/half-bake features to technically meet requirements while not meeting requirements.
This is funnily the part of the manifesto most have trouble understanding.
I’m curious what they mean by “failure.” I read the article but didn’t get a clear definition. Isn’t one of the expected outcomes of agile the ability to experiment rapidly and move on when the experiment fails?
So what if you fail 300% more? If you’re able to get 300% more ideas to the stage where you can test their viability, then it’s a success.
Exactly. Agile is basically guaranteed to deliver something.
The real question is how fit-for-purpose is the resulting product.
I highly (10/10) recommend that comment section - it is hilarious!:-P
Should I remove my Agile experience from my resume?
Time to replace it with AI experience! /sarcasm… Mostly
I just hate how companies cling to agile like it’s some kind of cult. Like a company I know gave all the employees very nice swag embroidered with a big “agile development” slogan on it like your development methodology is supposed to be a source of pride or something. Of course like most companies they don’t really follow agile practice very much except where they can use it as an excuse to skimp on requirements and such.
Aa someone who has misspent a budget before - you’re making it sound like a lot more people in the company care about the topic than what’s happening in real life.
I organize some events in our office every now and then. For example, one of them is a sort of competition/race/quiz/whatever - completely optional, but I get about 75% of the office to join, which in my experience - that’s huge, nobody joins any type of other events in such magnitude, usual rates are at 30-40%. The big bosses approve it because “morale” and “team building”. The people like it because it’s actually fun. So I get a budget to spend on this event, and we use it to buy “prizes” for literally everyone participating. Which means they’re shitty prizes, but hey, it’s not about winning first place, it’s about making some jokes at the bosses’ expense, on company time.
The way the process works is: all my bosses already know how this money is spent, and they approve. But because I need the money, it has to go through finance. And they involve marketing/PR guys. And these guys insist on having the fucking logo on everything. At the end of the day everyone is going home with several items (backpack, external battery, pen, umbrella, Swiss army knife etc) with the company logo on them, which is goddamn ridiculous. It’s actually one of the reasons I always refuse to receive items, even if the budget includes the organizers - because I really hate the branding aspect.
But all that aside - you see the aftermath of this event and you’ll draw the conclusion that we just spent the day in a corporate culture workshop, when in fact we were answering silly questions and getting imaginary points the entire day, but there’s ONE guy in ONE department who can’t let things slide. So… Idk man. Take it with a grain of salt next time. The agile dudes probably did it to get away from other things for a few hours, and they got the budget to also give something back to the coworkers. But not everyone really cares about agile, they’re just going through the motions.
Oh boy I hate the branding. I’ve gotten some really nice swag this way but I can’t use them because they’re so obnoxiously branded. I’m not going to the beach for example with a Dickhead Company stamped large on the beach towel, or going out of the house with it on the umbrella. Pens, battery are ok.
Oh yeah, I feel that. I got a nice beach towel with my company’s name on it some years ago, of course I couldn’t take it to the beach, I’d feel silly. But on the other hand - nobody sees it if I use it in the shower. Man, that company name has touched my dick&balls so many times I’m thinking I should marry it at this point.
I always try to make them put the branding in shitty places. For the umbrella I got them to print it on the classy wooden handle, instead of the fabric, exactly where you’d hold the thing. That way it’s still usable, you just need to hold your hand over the brand name. And on some other shit like wireless earbuds & smaller objects, the guys doing the printing can sometimes provide smaller velvety satchels to put the objects in, kind of like a gift bag, and I can usually print on those. Then you’re just left with the plain unbranded object when you inevitably throw away the satchel.
Fail fast baybee
Is this not self-evident to most teams? Of course you will not reach your destination if you don’t know where you’re going.
On all the agile projects I’ve worked on, the teams have been very reluctant to make a specification in place before starting development. Often claiming that we can’t know the requirements up-front, because we’re agile.
For your sake, I hope your employment was agile as well. Those jobs sound like they were dumpster fires waiting to happen.
Also seems like a shitty get-outta-jail-free card. With no design in place, timelines and acceptance criteria can’t be enforced. “Of course we’re done now, we just decided that we’re done!”
That’s boneheaded.
I don’t think this is an Agile thing, at all. I mean, look at what Agile’s main trait: multiple iterations with acceptance testing and product&design reviews. At each iteration there is planning. At each planning session you review/create tickets tracking goals and tasks. This makes it abundantly clear that Agile is based in your ability to plan for the long term but break/adapt progress into multiple short-term plans.
How did they know how to break things down into tasks? How did they know if a task would fit in a sprint? 😄
We’re so agile the sprint became a time-block framework rather than a lock-down of tickets that we certainly will finish. (In part because stuff comes up within sprint.)
On the other hand you can just call wherever you end up the destination, and no one can prove you wrong. 100% success rate.
Congratulations you’ve just been promoted to product manager
Not to mention that this Agile methodology is burning out people pretty fast. It puts a lot of pressure on developers.
I’ve been working with Agile for years and I worked with people who burned out, but there was not even a single case where Agile contributed to burning out, directly or indirectly. In fact, Agile contributed to unload pressure off developers and prevent people from overworking and burning out.
The main factors in burning out we’re always time ranges from the enforcement of unrealistic schedules and poor managerial/team culture. It’s not Agile’s fault that your manager wants a feature out in half the time while looming dismissals over your head.
It’s not Agile’s fault that stack ranking developers results in hostile team environments where team members don’t help out people and even go as far as putting roadblocks elsewhere so that they aren’t the ones in the critical path. Agile explicitly provides the tools to make each one of these burnout-inducing scenarios as non-issues.
that managers want to stay in control of everything, and they decide whether they do it or not.
It’s like real communism: it’s perfect but it’s not possible to implement in our universe.
That’s fine, it’s a call from the manager.
That doesn’t make it Agile’s fault though. In fact, one of the key principles of Agile is providing developers with the support they need. Blaming Agile for the manager single-handledly pushing for something in spite of any feedback does not have any basis.
I have a cure for all cancers. Except that bodies refuse to use its molecules, but it still cures cancer in theory. That’s how agile have always been used around me.
Agile wants to empower devs, but managers do not want this.
true, scotsman
This is why you should always visualise and multiply by 4 when people ask for an estimate. If someone gives me a ticket that’s expected to take me 1 day I’ll let them know it’s very likely not going to be done in 1 day but rather 4 which I’ll finish comfortably in 3.
Ranking devs is toxic though
“Never tell them how long it will really take! How else will people see you as a miracle worker?” - Scotty
Underpromise overdeliver
Yes, yes it is. You don’t judge a system by some ideal that can’t be achieved. If it’s a system meant for humans you judge it based on what it does to said humans.
If agile makes managers more insufferable, then maybe it’s not a good tool for the problem at hand, working in companies with managers.
Agile is not a system. It’s a set of principles, set by the Agile manifesto.
The Agile manifesto boils down to a set of priorities that aren’t even set as absolutes.
I strongly recommend you read upon Agile before blaming things you don’t like on things you don’t understand .
I have read those principles, many years ago.
Those principles sound great but they are not compatible with management.
If management is gonna be part of the picture then agile principles are not beneficial to a developer experience, regardless of what unachievable ideal they talk about.
F4M] Available for hookup, sexting and FaceTime 💦🌬️🌊🌊🍉🍉both in blowjob, anal doggy style and more🍉🍉🍉🍉🍉 TELEGM:Mialisa100 Number:+1 480-696-8297
I’ve literally never actually seen a self proclaimed “agile” company at all get agile right.
If your developers are on teams that are tied to and own specific projects, that’s not agile.
If you involve the clients in the scrum meeting, that’s not agile.
If your devs aren’t often opening PRs on a variety of different projects all over the place, you very likely aren’t agile.
If your devs can’t open up a PR in git as the way to perform devops, you aren’t agile.
Instead you have most of the time devs rotting away on the sane project forever and everyone on “teams” siloed away from each other with very little criss talk, devops is maintained by like 1-2 ppl by hand, and tonnes of ppl all the time keep getting stuck on specific chunks of domains because “they worked on it so they knpw how it works”
Shortly after the dev burns out because no one can keep working on the same 1 thing endlessly and not slowly come to fucking losthe their job.
Everyone forgets the first core principle if an agile workplace and literally its namesake us devs gotta be allowed to free roam.
Let them take a break and go work on another project or chunk of the domain. Let them go tinker with another problem. Let them pop in to help another group out with something.
A really helpful metric, to be honest, of agile “health” at your company is monitor how many distinct repos devs are opening PRs into per year on average.
A healthy company should often see many devs contributing to numerous projects all over the company per year, not just sitting and slowly be coming welded to the hull of ThatOneProject.
I don’t disagree with you (on giving devs some creative freedom), but “Agile” as a process methodology isn’t about developers working on multiple things to keep their interests up.
That’s actually a pretty important part of its original premise.
It’s a big part of why scrum meetings were a thing, as the expectation was any curious dev could just join in to see what’s up, if they like.
Not tying devs down to 1 specific thing is like the cornerstone of agile, and over many years of marketing and corporate bastardization, everyone had completely forgotten that was literally the point.
The whole point of the process was to address 2 things:
That client requirements can’t easily be 100% covered day one (But you still need to get as many as you can!)
To avoid silo’ing and tying devs down to specific things, and running into the one bus rule (“how fucked would this project be if <dev> got hit by a bus?”)
And the prime solution posited is to approach your internal projects the same way open source works. Keep it open and available to the whole company, any dev can check it out, chime in if they’re familiar with a challenge, etc.
One big issue often noted in non-agile companies (aka almost all of them) is that a dev slent ages hacking away at an issue with little success, only to find out far too late someone else in the company already has solved that one before.
An actually agile approach should be way more open and free range. Devs should be constantly encouraged to cross pollinate info, tips, help each other, post about their issues, etc. There should be first class supported communication channels for asking for help and tips company wide.
If your company doesn’t even have a “ask for help on (common topic)” channel for peeps to imfoshare, you are soooooooo far away from being agile yet.
I don’t know man. Nothing in the Agile Manifesto talks about not focusing on one project.
In addition, I think most people (and studies) would agree that “focus” is key to building almost anything of quality. Not flittering about working on shiny pennies of the day. I mean, a key tenant of sprints is “Don’t interrupt the sprint”. The whole concept is about letting developers focus.
Agree to disagree I guess.
Might wanna read it again, it’s right there :)
It’s an incredibly critical part companies love to completely ignore.
If you assign devs to teams and lock em down, you’ve violated a core principle
And it’s a key role in being able to achieve these two:
And
This is talked about at length by the likes of Fowler, who talk about how locking devs down us a super fast way to kill sustainable development. It burns devs out fast as hell.
Note that it’s careful not to say on the same project
Agile went through the mgmt human centipede and now it’s an unrecognizable broken system built on conflated ideas. I bet a good number of those projects are ‘agilefall’ anyways.
We prefer the term “wagile”.
I liked frAGILE
Random trademark symbol. What’s the registered trademark here? The dot? “advocates”?
Its just the symbol The Register uses at the end of an article. Like how some papers use a filled in square.
Right off the bat i read
You need clearly defined requirements to write a good user story. Documentation comes after.
Precisely, once once have i worked in a company where agile was properly implemented and, yes, user stories were well documented and discussed before being developed. All others are just waterfall in disguise, or Fragile™.
This is the main reason the last company I worked for lacked in project delivery. They had just transitioned to Agile, and their whole teams lacked proper Agile experience and the training provided was very superficial. They barely put any time in refining the requirements and this trickled down to developers.
Projects that allow for clear requirements before really starting on them are clearly more likely to succeed than ones that have a higher complexity due to unknowns.
It’s more about poor planning vs good planning. Of course a project with good planning is more likely to deliver in time.
It’s just to that poor planners tend to use “agile” as an excuse for their poor planning.
In the days before Agile the Waterfall projects failed too. Though not necessarily for being late, they failed because they didn’t deliver the thing that the business thought they were building, they delivered something else due to a misunderstanding. If nothing more, Agile gives more visibility into the process and allows for course correction.
Lol I’m going to send this to my project manager
Agile is LinkedIn religious bollocks. Might as well just pray. Bunch of corporate nonsense.
BUt YoUrE NoT DoINg it RIghT!!1!
Should be reciting the creed in Latin, presumably.
Every time I see a discussion of agile, there are plenty of comments about how mentally exhausting and useless/wasteful the meetings are. And the defenders can only say, “you’re doing meetings wrong!” Maybe if everyone is doing it wrong the process itself is fundamentally flawed and lends itself to misinterpretation.
Well, you’re supposed to refer to them as “rituals”. “Meetings” are so waterfall. No wonder it isn’t working.
Maybe if we mix in another metaphor, Agile will work.
Great idea! Let’s huddle with the Coach at the retrospective.
I prefer séance
I’ve been in agile projects that worked really well and didn’t have soul-sucking, time-wasting meetings. It can be done well, it just isn’t most of the time.
Same, I’ve been on agile projects with quick efficient meetings most of the time. But I’m a project now with a 45 minute standup every morning for like 15 people. The lead just lets people ramble on and try to solve issues in standup. Backlog grooming and sprint plannings get equally sidetracked as well.
One common thread between these projects was that we used actual, physical note cards to track things. They were also logged in Jira, but the standups were 5-10 people actually standing in a room tracking burn down and status with cards taped to a wall. Nobody wants to be standing for more than 15 minutes, and anything that needed a sidebar was handled with a smaller group in another impromptu meeting.
I agree, in my experience in person stand-ups are much better than online.
Similar, except we only budget for half an hour so as it drags on past the first or sometimes even second hour it takes over lunchtime.
Even when people avoid trying to say anything so as not to drag it out, the mere fact that the meeting is happening means that it will manage to take up the whole block of time and then some.
Ironically I’m starting to wonder if the solution might be MORE rather than fewer meetings, bc people need SOME time to work it all out, so if there were other more focused ones then all that could go there rather than have to take place in the only meeting it can - where it takes up the time of the entire team.
Is it really that unlikely that companies that jumped into the agile hype train do it wrong?
Like Communism.
Just like saying AI will solve all your problems even if you misuse. It’s just like a pattern big companies use to mask when they’re talking out of their asses.
There aren’t any meetings that are part of Agile. The point of Agile is that you’re supposed to let teams self-organize and define their own process through iteration but managers hate that so they issue a top-down mandate to implement the Scrum process without allowing anyone outside of management to change it in any way and call it “Agile”.
They’re not “failing to deliver”, they’re being Agile in disappointing everyone involved!
Which shouldn’t surprise anyone, but I know some managers, directors and users loathe the idea of the people who’ll do the actual job having any say other than “yes, sir”.
Good documentation is critical and process-agnostic. If people can read and understand it, it’s good. It’s something that can be used as a shield and weapon against users/higher ups who want too much, it can create a trail of responsibility.
Ha, “fail faster” indeed
Normal development: measure twice, cut once. Agile development: measure once, cut twice.
Shockedpikachu.jpg when things fall apart.
Honestly a little confused by the hatred of agile. As anything that is heavily maligned or exalted in tech, it’s a tool that may or may not work for your team and project. Personally I like agile, or at least the version of it that I’ve been exposed to. No days or weeks of design meetings, just “hey we want this feature” and it’s in an item and ready to go. I also find effort points to be one of the more fair ways to gauge dev performance.
I’m not really sure how this relates to agile. A good team listens to the concerns of its members regardless of what strategy they use.
Again, not sure how shipping with bugs is an agile issue. My understanding of “fail fast” is “try out individual features to quickly see if they work instead of including them in a large update”, not “release features as fast as possible even if they’re poorly tested and full of bugs.” Our team got itself into a “quality crisis” while using agile, but we got back out of it with the same system. It was way more about improving QA practices than the strategy itself.
The article kinda hand waves the fact that the study was not only commissioned by Engprax, but published by the author of the book “Impact Engineering,” conveniently available on Engprax’s site. Not to say this necessarily invalidates the study, or that agile hasn’t had its fair share of cash grabs, but it makes me doubt the objectivity of the research. Granted, Ali seems like he’s no hack when it comes to engineering.
Remember that it is frightingly easy to lie with statistics. This is just a correlation. Smaller companies (whom may have less experience, worse less-paid engineers) may prefer agile due to the amount of up-front effort for things like waterfall.
I could be wrong, but from what I’ve experienced,
is not always the norm. I’ve worked in agile environments where we had to work fast because the large corporate stakeholder had such a rapid turnaround that discussing and addressing problems meant slowing the process down, so no one wanted to be the one to say anything.
Agile feels like one of those things that works well on paper and when practiced properly, but when you get the wrong type of stakeholders involved, their lack of understanding rushes everything and makes the process and the final product bad for everyone.
I definitely agree, but that’s true of any system. The particulars of the pitfalls may vary, but a good system can’t overpower bad management. We mitigate the stakeholder issue by having BAs that act as the liason between devs and stakeholders, knowing just enough about the dev side to manage expectations while helping to prioritize the things stakeholders want most. Our stakes are also, mercifully, pretty aware that they don’t always know what will be complex and what will be trivial, so they accept the effort we assign to items.
The project manager’s revenge: the last Scrum Master.
I liked agile as it was practiced in the “Extreme Programming” days.
Rather than attempt to design the perfect system from the get-go, you accept that software architecture is a living, moving target that needs to evolve as your understanding of the problem evolves.
Rather than stare down a mountain of ill-defined work, you have neat little user stories that can be completed in a few days at most and you just move around some Kanban cards instead of feeding a soul-sucking bureaucratic ticketing, time tracking and monitoring system.
Rather than sweat and enter crunch mode for deadlines, the project owners see how many user stories (or story points or perfect hours) the team completes per week and can use a velocity graph / burndown chart to estimate when all work will be completed.
.
But it’s just a corporate buzzword now. “We’re agile” often enough means “we have no plan, take no responsibility and expect the team to wing it somehow” or “we cargo cult a few agile ideas that feel good to management, like endless meetings with infinite course changes where everyone gives feel-good responses to the managers.”
Having a goal, a specification, a release plan, a vision and someone who is responsible and approachable (the “project owner”) are all part of the agile manifesto, not something it tries to do away with. I would be sad if agile faces the same fate as the waterfall model back in its time and even sadder if we return to the time-tracking-ticket-system-with-Gantt-chart hell as the default.
Maybe we need a new term or an “agility index” to separate the cases of “incompetent manager uses buzzword to cover up messy planning” from the cases of “project owner with a clearly defined goal creates a low-bureaucracy work environment for his team.” :)
Someone would look at our process and say “that’s not agile!” and they might be correct, technically speaking. I don’t personally care what it’s called as long as it works.
We agree to requirements up front with our customer; we might change stuff as we go along if our customer realizes that what they asked for won’t work (this happens occasionally), which is fine, but otherwise we don’t let them change stuff around on a whim, and we don’t allow scope creep. If they want a new feature, that’s version 2 (or 3, or 4).
We don’t meet very frequently. We do check in to make sure we’re on target, and deliver features incrementally when it makes sense to do so. We do sprints. We talk about when things are working and when they aren’t, but only when we think it’s a good time to do so.
At the end of the day, you need to tailor the process to your needs and what makes sense to you and your team.