What happened to the agile movement? Uncle Bob

[@LiamODev]

Project managers love to 'project manage' complex discovery tasks - which just doesn't make sense. Agile is becoming just another layer of 'reporting', rather than a methodology of 'delivery' :(

[@marcotroster8247]

Guess you should write a JIRA ticket about it and estimate the story points (in days) 😂😂😂😂😂😂😂😂

[@cloudboogie]

That sums up my feelings about agile. The only time i've seen agile somewhat succeeded was when it was used just for the managers and team was more focused on actually doing their job, while actively bypassing most cargo rules just for the sake of good looking reports.

[@abrahamdsl]

@@marcotroster8247 LMAO KZbinr A. Sistili: kzbin.info/www/bejne/ene2iIBjo9GsZtk

[@dwmichaels]

It's not a methodology. A methodology is prescriptive. If you take the values & principles of the manifesto, they are beliefs on how we should work together. There is no prescriptive anything. The difficulty is when you give people in an organization values & principles, they don't know what to do with them. If you are engaged in the company goal, and align with those values & principles, then you already have an idea of what will work effectively to delivery your work. You know where the delays in the system lie, where the problems are that prevent you from doing your best work. All you need to do if agree on how you'll deal with overcoming them and sharing the valuable work a team delivers. It's a lot of fuzzy things with the solutions left up to the teams. However, if the teams don't take on figuring out a solution, management will give them one.

[@laurenceotoole1700]

@@marcotroster8247 or in t-shirt size

[@steveoc64]

I don’t care what label you use to describe “the next great improvement” to replace Agile If it involves having stupid meetings all the time … then it’s just another gigantic waste of time The average developer doesn’t need another meeting every couple of hours to know what to do next. They are not like children lost in a shopping mall For most developers, their biggest problem is not knowing when they are ever going to find the time to work on the things that they already know have to be done by the end of the week Just let them do their job

[@a0flj0]

Actually, most developers are just like children lost in a shopping mall. Software keeps eating the world. A a consequence, the programmer population grows at a pace at which no other professional group grows. This means many would-be programmers - more than half of them - have less than five years of professional experience. That's not enough to call yourself professionally mature. A programmer being swamped is a very clear sign of not being professionally mature. It only happens when you don't understand the business you work for - something the vast majority of programmers are completely not interested to do. But that's our job. Our job isn't to churn out source code like there's no tomorrow. Our job is to help businesses do better what they already do, and enable them to do things they've never done before, with the help of software. That we create massive amounts of code in the process is just a side effect. Businesses don't understand software. To the vast majority of people on earth, software is still magic. Businesses don't know how they can benefit from software and can't easily make the difference between what's possible and what's impossible - it's magic for them, remember? That's why programmers _have to_ learn to understand business. Programmers (supposedly) already understand software. Only by also learning to understand business will they be able to explain to business _in business'es own language_ how software can help them. Also, once they can do that, they'll be able to make business understand that software isn't magic, and what can be achieved with software is a direct function of what resources are allocated to its development. Business isn't stupid, it's just distrusting of what it doesn't understand. Once you explain to them what can be done when, what the consequences of unrealistic expectations and careless prioritization can be, if management still presses on with unrealistic expectations, leave - that's a company with stupid management which will eventually fail. _Then_ you will be able to call yourself professionally mature.

[@MarkRuvald]

Agree. Also look up Erik Meijers presentation, The Hacker Way

[@mc4ndr3]

Agile has lost all meaning. Every company labels themselves Agile, without adopting any bottom up improvements in process or allowing space for creativity or fostering healthier relations between people. This unfortunate state of affairs is the natural consequence of hype having replaced long term prosperity. Everyone builds pointless vaporware on a death march, so there's nowhere to go to vote with your feet toward sane practices.

[@braincraven]

I hate Agile with a passion not because of the process but they way it's abused by leadership thinking it's a way of pushing development bypassing design. 😞

[@anandsharma7430]

The technical guys are socialists and the business people are capitalists. Bad analogy, but easy to understand. Technical guys want a stable long term manageable system, business people want to increase sales at all costs, sacrificing quality, longevity, stability.

[@xbmarx]

People try to dunk on Uncle Bob for things he said 20 years ago but his recent stuff is pretty good.

[@miikavihersaari3104]

Pair programming has always been good comedy.

[@QuantumMechanic343]

The magic of the grift.

[@robertluong3024]

his advice deservingly does get dunked on, but his intentions were always pure to me I think the worst part about Uncle Bob were the people that take his word as gospel rather than anything he's done himself.

[@steveoc64]

On balance, the world would have been a better place if Uncle Bob had taken up stamp collecting or train spotting instead of software development

[@deanschulze3129]

Has Uncle Bob learned anything in the past 20 years?

[@ktreier]

As a CTO, my sole experience with a Certified Scrum Master was a negative one. They were so bound by the constraints of the “process” they were willing to allow the Company’s reputation be harmed by an outage.

[@kaasmeester5903]

"Certified" and "Scrum" are 2 words that shouldn't be together. "People over process" is one of the core tenets of the manifesto.

[@rtwas]

With my first and last experience in Agile, I found it to be a mechanism that enables upper management to more closely micromanage developers. It was rather unpleasant experience in my case.

[@tmac9208]

I thought that was in the manifesto..

[@kennethmark6868]

Good to listen to one of the initiators of the Agile movement, their original idea and principles.

[@samuelec]

This video is super old

[@arturhellmann9138]

We were a good working, self managed Software Team. We took some advantages from scrum, had a board and such things... but we did it our own thing. we did not need a lot of meetings, dailies were optional. Everything worked perfectly. Then someone from upper levels (basically a company that bought us) meant to implement scrum... We got a scrum master and what not... calendars got full with dailies, plannings, retrospectives... And everything went down... Now that I am leading, I would never do scrum again. We are working agile, but with a bunch of common sense... I feel like Scrum is just a way of overcomplicating a process that should run smoothly on its own with common sense and a good team...

[@bramvanduijn8086]

You drew the wrong conclusion. The problem isn't scrum, scrum is just another optional tool. The problem is hierarchy. The existince of upper levels is what caused your team to fail.

[@789juggernaut]

There is a lot of truth here. Like Six Sigma and other well-meaning concepts, the vultures descend, wanting to capitalize and monetize, ultimately changing it into something it was never meant to be. But companies can be independent and choose to do Agile any way they want. You just have to ignore the vultures.

[@chrisschrumm6467]

13 years ago worked at a company that went from Waterfall to Agile for some projects. At first things went well we had a chalk board with story cards and a 30 day release cycle. Soon there were certified scrum masters then agile process management applications. Soon we had story cards with documents as deliverables and soon we had a project manager that came over from the Waterfall projects to join our sprint as "business owners". We adopted more and more components of the old Waterfall as well as new tools that helped us be "more agile". Cancer doesn't come from outside it comes from within.

[@cannyp3]

Coming from the business side, Agile has become a convenient excuse to devote resources on "measurable" technical debt and waste time on endless incremental discovery work while a handful of well meaning developers actually deliver value. It has lost its way in the name of discipline and metrics. Deriding the business side has not helped, either. It's a partnership that requires patience.

[@psyaviah]

On which basis aren't you trusting your technical peers if they report technical debt being made? As a technical person, I have nothing against technical debt, it's often needed and very useful to go and make stuff happen. My experience though is that when "it works", people often forget the technical debt (shortcuts, maintenance, ...) and thus this becomes technical neglect. Which inevitably will become either a security, operational and continuity risk. Whatever technical debt there is, it has to be dealt with one way or another - when that is done is debatable. But when debt is made, it should never be forgotten. In this scenario you have, which I don't know of, maybe the technical people are afraid it might be forgotten and that then the debt isn't visible anymore. And if something goes wrong it'll be blamed on them for not reporting it, or doing something about it. Could that be an underlying factor at play in which you see them working on such things? Last, but not least. We live in such a fast paced, demanding, world that those shortcuts are needed sometimes. But that doesn't mean if you want to stay agile (as in, want to be able to move quickly and efficiently in changing processes etc) then slowness is a virtue. New features can be shiny and nice, but, to be able to have those and develop them in quick pace and succession and with success we need time. Both on business and technical side there's work to review the process, stand still, analyse, solve, and have a plan b in mind. My advice would be to just ask why it's important to work on it now, and what the risks are if we don't do it this week/month/quarter/year? Ask, go in an open and curious dialogue. That should be the purpose. And let them speak free, if too technical do point them to please keep in mind that too technical isn't helping their explanations. They have their work to make it understandable as well. But try to keep a dialogue going. Otherwise your problem or frustration won't go away. Mind, maybe ask, "how come this technical debt is created" (without pointing fingers). But it might give insight as well.

[@swordscythe]

Business: Hey programmer! Programmer: Hey business! Thanks for those use case scenarios! Business: You're welcome! Loving this cooperation! Programmer: Yeah me too, we are so productive, and I haven't seen a manager in weeks! **SAFe framework enters the chat**

[@mrrolandlawrence]

for me agile was the cure to working on gov contracts where years would pass before the end user would see anything. Far too late to make changes & feedback was considered a starting point for a new project. then managers decided that as managers they could make it even better if they had more managers, more reports and more meetings. As humans we are very good at bypassing and cheating any system.

Retired developer/PM/Scrum Master (in that order) here... Having been through many methodologies over 40+ years (waterfall, CASE, Information Engineering, RUP, Agile....) I felt that Agile was the least worst approach to software development for most cases. It all works great until you introduce people. Stop blaming management - everyone shares the blame. From management still pinning unrealistic deadlines, to PM's not having a clue to what it takes, to business having no understanding of what their involvement needs to be, to Scrum Masters for just going along with what others tell them, to developers not wanting anyone to ask them anything about how things are going and hiding the reality. People make mistakes at every level - even with the best of intentions. Still, as I said above - Agile is the least worst of all and I would continue to promote it.

[@netssrmrz]

Agile is to managers like UI Frameworks are to KZbin vloggers. It gives them something to do and justifies their existence.

[@SDNK79]

All project managers after taking agile certification started with new role “Scrum Master”. But they’re still acting & behaving the same. I’m living through the worst project execution, where developers are not engaged during story writing and sizing 😂, ridiculous.

[@TranscendentBen]

If project managers are "Scrum Masters," are programmers Scrum slaves?

[@patrickd9551]

@@TranscendentBen That comment is just a chef's kiss. I love it.

[@TorianTammas]

​@@TranscendentBen The scrum master is drumming and the "tourists on a cruise" row the ship in that rhythm.

[@kryptoknight992]

What software industry needs is to be more like other Engineering industry. Enough with fancy nonsense.

[@danielarledge7017]

Agile philosophy may have had good intentions, but the reality is businesses use Agile (specifically continuous delivery) as a way to inundate dev teams with more projects with an emphasis on quantity over quality. This is just breeding grounds for buggy prod environments and security vulnerabilities as devs teams struggle to keep pace with volume.

[@frederipochard8892]

Probably one of the biggest tool the management has created to take over Agile is SAFe.

[@cajonesalt0191]

It's not just agile. Corporate culture has completely taken the forefront of how people think about development. That's not necessarily a bad thing, but it shifts the perspective of how, or even what, to develop from whether or not the tool satisfies the customer requirements to whether or not the tool satisfies the business requirements. And business requirements and usability (read: customer requirements) do not always match. I think we can all think of more examples of business requirements failing to meet customer requirements than not. Someone else in the comments said it isn't useful to deride the business side, and I strongly agree, but at the same time the rate at which business requirements escape satisfiability or even feasibility grossly outpaces the technical sides ability to do the same, and this is inarguable.

[@brentlidstone1982]

This is really just a long-winded way of saying that business people actually have no fucking idea what makes a good product.

[@Beldraen]

So, what you're saying is "the most important thing about being Agile is to pick a fixed set of permanently defined roles and behaviors so no one and no process can allow bad changes to get into the process, regardless of the cost." The agile programmers never left. They were left behind when they said, "But, how does this change add any value to the process?" and the Agile Advocates said "you're not being a team player by working in your role and using Unit Test Red/Green/Refactor Methodology with hot-swap bean components." Agile is simple: be willing to evaluate your team's ability to achieve goals and periodically reflect on if you are meeting them. If you have better ways to do something, try it. If things aren't working well, tweak it or drop it. There is no "Agile Process." It is not a thing. It is a philosophy.

[@fredsmith1970]

It always makes me laugh when people (who are heavily invested in it) describe agile as a process, which they usually set rock solid in stone. Do they not know what the actual word "agile" means? I totally agree with you assessment... "agile" should be a case of being willing to drop what doesn't work and adapt/carry forward what does. Which also means changing the "process", not just code deliverables. (But if we scrapped bits of the process that held us back, then what would the scrum masters, agility leads and project managers do then??)

[@bramvanduijn8086]

@@fredsmith1970 This is why scrum master isn't actually supposed to be a person, it is a role that rotates through the team.

[@P_Mann]

The problem with agile is that it became synonymous with winging it, not thinking anything through, never accounting for the costs associated with failed experiments (i.e., playing around), claiming “value” and “look what we learned” even when nothing useful to the client is created, and continuously moving the goal posts until someone finally pulled the funding. I believe this is why the norm seems to be broken software at release-not the working software promised in the manifesto-followed by feedback-based patches (squeaky wheel style) until the end of time.

[@Flylikea]

Pretty much

[@TelithsRage]

I'm an Architect, so my position is different to most. What I observe is that some project just don't fit the agile model. In the Banks, Government\Insurance organisations I work for I find that Agile is ideologically selected as a strategic direction or it's selected as the preference of the PM. IMHO, Agile as a delivery model is highly aligned to CI\CD as an operational model. However greater than 70% of all projects do not benefit to the incremental delivery model either because they need RFQ\Vendor Selection\Large Capex or have deliverables like large scale replacement\upgrade of production systems. For the 30% ish of projects this model really does take the boot off the neck of devs who need the space to try things out to see what works. For the other 70% of the projects Agile is being misused and people (including myself) have learnt to hate it. AFTERTHOUGHT : Also, I think that half of the projects only call themselves Agile because they use Jira and have a board replace a gaant chart with sprints that relieve the PM from having to even know what they are delivering. I recently was the principal architect on a large vendor outsourcing replacement. Agile was used. Near the end of the project I initiated a meeting to cover "all the things the PM forgot to deliver on that was in the design" . These were serious things that were totally dropped because the focus on sprints occluded the PM from long term planning. In my field we equate Agile PM's as Junior\Lazy PM's for the reason stated. On the upside Agile arrived at just the right time as when it was introduced most companies were struggling with bureaucratic process strangling waterfall delivery and the Agile approach of 'limited rules, just trust us' helped remove waterfall from the deadlock it was in.

[@a0flj0]

Can't relate. I don't like to call myself an architect, although some people push me in that direction. IME, an architect who stops coding quickly becomes a useless annoyance for the people who actually create value. I've seen it repeatedly that an appointed architect keeps wasting money and time until he's kicked out, and within months nothing of what he's designed remains in place. How I read your comment: banks and governments understand as little as any other organization, including some software development shops, about developing software. Only, unlike other organizations, they're unwilling to learn and also unwilling to accept external counselling. As a consequence, they impose their obtuse processes which are completely ignorant of software development specifics onto software development. And then act surprised when costs skyrocket, deadlines keep being missed and instead of user acceptance there's adversity. What I understand from your afterthought: you, or a team of architects you were part of, designed a system that didn't take constraints related to budget, time and available people into account. Then, when the system wasn't completely implemented, tried to blame it on the PM. The PM can only manage. He can't make something big fit into a box too small.

[@vaidyanathtdakshinamurthy8732]

Nicely summarized.

[@shaynewhite5207]

What he is describing is the iron law of bureaucracy, it takes hold everywhere unfortunately.

[@bramvanduijn8086]

I would say it has more to do with hierarchy than bureaucracy. Bureaucracy without hierarchy would just slow agile down, it wouldn't sabotage it.

[@jammintoast1]

In my 35 years experience I’ve seen many SDLC methodologies, and not once did the method make or break the product. Success comes from skilled analysts that ensure product delivers value. Meanwhile everyone is arguing about whether something should be classified as a feature or a story, even though they don’t understand the business requirements that will add value.

[@nicoscarpa]

Give business a fancy word like "agile" and they are going to sell it no matter what; even though it was created to give more power to developers, agile (or whatever other methodology or philosofy) will never solve the impedance mismatch between business and production... Only experience and saying "no" when it's needed will! I agree, tech people should learn to lead.

[@teeconsigliano7631]

Like any teamwork it won't work without decent communication

[@user-fed-yum]

In the 1980s I was building projects at home and building projects in the office. The ones I did at home completed faster, worked better, and were obviously more internally consistent. Of course I was call a hacker, a term I wore proudly in those days. Somewhere along the way, I heard the word agile and it described quite well the difference between the two practices. I "sold" the idea to government and big business. I grew my business fast. For a few years it was amazing how more productive my teams were, and how much more they enjoyed their work, because they got results. And then all the so called project managers and so called cios and other such wa nkerrs who haven't got a clue how to program, got hold of it, and then it became bureaucratic toast. Loving my retirement.

[@ciroformenton]

Where can I find the full presentation?

[@carstenkonig4758]

kzbin.info/www/bejne/m5SsiIOwfKqVfMUsi=Ym25yWro8LRrfoLT

[@Shadyyy90]

"Uncle" Bob Martin - "The Future of Programming" - youtu.be/watch?v=ecIWPzGEbFc

[@foroparapente]

As a project manager this hits home

[@distrologic2925]

Agile is a paradigm designed for the comfort of the customer, not the user. Most of the time, the customer is the project manager. Agile is designed for managers. They don't have to make proper plans anymore, they plan for maximum flexibility on the programmers side and they can stick to their "agile" scheme.

[@georgehelyar]

It's designed for the end user, but it's been twisted into scrum ceremonies and safe etc. People split things into increments so that they can report that they made progress this sprint, without actually delivering any value to end users or, most importantly, getting any feedback from end users to decide what to do next.

[@Tensquaremetreworkshop]

Every idea travels from a movement to a business, then to a scam.

[@hallstewart]

30 years ago, I had a standup row at a job interview: software is engineering, but coding is a craft. The interview went mental at the idea that programmers were craftsman.

[@maxmanus6575]

Agile harmed more then it helped. Software development was meant to be from people for the people. Now it is a big fat consultant-industry with tons of people managing all kind of businesses.

[@IdgaradLyracant]

Agile: A complex con to legitimize 'making shit up as you go' as a methodology.

[@donfolstar]

Sort of reminds me of what happened with "organic". People out there actually doing the work and seeing the problems had an idea. Their peers recognized the value of this idea. Now the owners and their proxies (management) want to get involved. The idea gets "reshaped", "optimized (for our purposes)" , and otherwise distorted until it is working against the original intent. Step 3: Profit.

[@dbsql6238]

Saturday is my fast track day. Monday thru Friday is meetings and support related tasks.

[@jf3518]

I remember what happened after our scrum master left the project. Nothing...

[@kdicus]

Uncle - In your opinion, WHO should lead? Doctors, engineers, lawyers, architects have figured this out. What worked and what didn’t? Is it one really rich person? Several of the largest tech firms? An existing standards body?

[@psychic8872]

You think you will hear just another opinion about agile but then you remember that Uncle Bob signed the agile manifesto

[@tuna2k10]

Agile became a buzzword to throw around by people who didn't really understand it - the number of times I've heard managers, marketers, execs, even HR people, interchangeably use 'agile' and 'flexible'...

[@OdysseyHome-Gaming]

When I heard of agile and scrum I imagined a guy doing fancy footwork that makes them look like they can fight; untill some fighter patiently waits for the right time to sock em once and they get KO'd.

[@Wahinies]

It became a buzzword for micromanagers to pervert

[@AndrewGoodnough]

Agile solved for quality and had time to delivery as a secondary concern. Managers need to solve for time to delivery with software quality as a secondary concern. That's why Agile was coopted and why any attempt to bring it back to craftsmanship will fail. It's a difference in focus partially due to visibility within the organization. A product that ships late is much more visible than a product that ships with low quality that will need to be addressed over time in maintenance. Obviously this is the very thing that Agile did better - build high quality software that would save time over the long haul - but organizations are are short-sighted. It's becoming hard to continue following and learning from my favorite leaders in this space knowing that this is not the reality that I see day to day as a professional developer and haven't for over a decade.

[@StephanLuik1]

When an adverb becomes a Noun (with capital N) you know that your concept has been hijacked by business bobos. I have seen it all: VSP, RAD, XP, RUP, LEAN, Agile, Six Sigma, SCRUM, SAFe. As soon as the trademark sign appears behind the name, you know you're in trouble. Just build stuff that works and have some fun in the meantime.

[@flippert0]

I'm quite divided over the benefits of Agile. Two of my main concerns is that the need to have workable increment after each sprint leads to problems with testing and in general to a rushed development. The use of Kanban (or 'Scrunban') can take away some of tha that pressure. The other concern is that epics / features / user stories are no replacement for a working requirements engineering but a lot of people in the trade (devs and product owners alike) seem to think that.

[@yorailevi6747]

Please also reference the original lectures. people should know about them!

[@AmandipSangha]

these methodologies are just a business idea for making money on overcomplicating simple things

[@KevinMuldoon-ks5hc]

The Agile Split will only grow wider. Business will always put their immediate needs over Professionalism and Craftsmanship.

[@AnnatarTheMaia]

As a technical person and an engineer by trade and profession, every time I saw agile, it was carte blanche for "developers" to hack with wild abandon and deliver lowest quality software I have ever had the misfortune of seeing. It was really amateurishly done. Every single time. That is why I am so much against agile and so much for the formally defined waterfall process.

[@carlo-sacchi]

where is the complete video?

[@brentlidstone1982]

Literally all he's describing is the same trend that has been going on forever. Bean counters who know absolutely nothing about technology or engineering end up taking over everything, and everything they touch becomes awful. But for a brief moment in history, the shareholders get great value. People have been saying that believing bean counters should run everything is a dumb and archaic style of thinking for well over 50 years. And yet, most major companies keep doing it over and over and over for some reason.

[@recarsion]

"Individuals and interactions over processes and tools". Companies and managers should just remember this one line of the manifesto. We are supposedly agile but god forbid we deviate from the same useless meetings every 2 weeks and actually let the team figure out a process that works for them.

[@georgebeierberkeley]

I'm a big believer in pair programming. It's frustrating for sure but it leads to a better product. And rapid iteration/deployment. And Kanbans. Daily meetings are a waster. The "scrum master" role needs to re-defined as a "programming coordinator" to make sure all the pieces keep fitting together.

[@bramvanduijn8086]

A daily 5-10 minute meeting can be a useful ritual, to take a minute to check in if anyone needs help. The need for it depends on the personality and personal issues of the team members, some people stay quiet about issues unless directly asked about it.

[@lerneninverschiedenenforme7513]

why the cut at the end?

[@zvejkal2]

What do you mean by the last sentence???

[@daithi007]

I've yet to meet a scrum master that removed impediments. The roll attracts bluffers and people who are effectively secretaries juggling jira tickets. Scrum itself is compressed waterfall. Scrum is a death march for team members. That's my opinion, based upon nearly twenty years of dealing with this faeces.

[@statebased]

You need to love the background music... Still, you cannot lead agile without strength, and sadly promises of control, such as made by project managers, are stronger than promises of new developments, such as made by engineers.

[@nocgod]

10 years I. The industry I can count on a single hand the amount of project managers and product owners who actually worker WITH the teams instead of diminishing the engineering to code moneys dictating practically. Agile has failed.

[@otockian]

It's easy why Agile didn't work really. Because of constantly changing requirements. Your constantly shifting things around, even in the current Sprint because everything is dynamic. In addition, stakeholders don't want or care two craps about velocity, or points. They want to know how when it will be done, they want a solid date. Even if that date is completely meaningless and won't be met (it won't), you have to give it to them. So you generated a random date, you generate random timelines based on velocity and guesses. None of it is accurate, because it's all dynamic and constantly in flux. It's no better than PMP really, all PMP did was apply a bunch of formality to it that was also completely worthless. Both are absolutely awful at predicting time and cost which is what ultimately matters in the end. But I do think parts of Agile are good, such as swimlanes, and sprints which act as a sort of line in the sand even if they are constantly fluxxing. The key thing to realize is that you won't have accurate time frames (it's not possible), you won't have accurate cost (also impossible) as they will constantly and nearly almost always be wildly off target. In my 30 years of doing software dev, and management I've never seen a single project meet it's deadlines, or target cost. Not once, using PMP or Agile. Never.

[@thankyouforyourcompliance7386]

"agile" has become the preferred word for understaffed project with no structure.

[@dixieflatline1189]

Agile lost its way when the methodology became more important than the outcome. Satisfying customer through "x" is a brilliant objective. The outcomes should define what X is - Start with that.

[@philipoakley5498]

Classic "Competing Values Framework (CVF)" scenario [tech programming vs programme cost/schedule] of conflict. The Graphic already has the diagonal slash!

[@rboothby]

Will this all rendered moot by AI? I helped co-found npm. The downloads of many top npm packages have stopped growing. Programming is undergoing a massive change. Five years from now, for most business settings, I think we'll be down to a type of pair-programming with a "developer" and a "product person" who roll out changes almost as fast as they can talk about them.

[@valerys.219]

Only one thing count in order to build something: try, failed, and re-try until it works. Everything else is bullshit for people who have never done anything. The best programmers I met had no methods but one: they didn't talk at all.

[@TorianTammas]

Why did the pyramids finish in the life time of the pharoa who ordered building them? They did not have meetings and sprints and stories and all the niceties that fill time.

[@WarrenPostma]

Agile means "saying we want X" but "doing the opposite of X". Agile means using buzzwords that suck meaning instead of adding it. Agile means "sprinting" towards unknown unknowns using over-simplified statements of our real goals without a concrete plan and without a solid design process. Agile is flailing around, while using a layer of nonsense and sanctimonious shop talk that obfuscates the fact that we are merely flailing around. Planning Poker is nonsense. Agile planning is no plan at all. Pair programming? Now that's a good practice. Test driven development? Great practice. SOLID design and architecture? Great stuff. Now how about a new way to pragmatically design and execute software and make an R&D schedule that can be integrated with and is survivable for the business, and the business's core activities and plans. Software development costs unknown amounts of time and money. This is the fundamental reality. Instead of trying to invent an one size fits all impedance match between coding and business, how about we start with the fact that you can't do that. What we can do instead is have a very large and stretchy springy thing in between the two to make the train stay on the rails. I call that stretchy bit "pragmatism". You can't get a certification for it. You can't turn it into a product you can mass manufacture. It has to be in your head the way riding a bike is in your head. Meetings should be few and far between and should be reserved for things that can't be emails. We crap all over any attempt to make any designs at all, and call everything that isn't our cargo cult "waterfall".. Like that ever made sense. Design is valuable. Can we waste time designing? Yes. But we also waste a lot of time not designing.

[@ElPolemista]

Agilebmade secretaries to be scrum master and later on Team leads. Upside-down world

[@deanschulze3129]

Something similar is happening when it comes to defining craftsmanship. People who don't spend their time writing code want tell those of us who do how we should write code. The Bob Martins and Martin Fowlers of the world want to tell us that we have to pair program and do TDD. That's much like managers wanting to take over agile and turn it into some management fad instead of an approach to engineering.

[@a0flj0]

Both Robert Martin and Martin Fowler have written code for the better part of their professional life.

[@DarrylHebbes]

Agile was weaponised to speed up teams

[@CaribouDataScience]

Who trick remembers TQM ?

[@rackbites]

These days Agile is just a cover the business taking over the engineering space ... the cway cway shit I have seen ... the good old days it was how teams wanted to self organise using a good pattern.

[@rolz71]

You don't add all that defined structure to fix something you want to be "agile". You teach people what it's purpose is and how it can help organizations. Agile is a most valuable as a process that's integrated into a situation, not a design pattern.

[@kevinmilner2072]

literally the process that happens to everything CS related. Someone figures out how to make money off of it and its no longer science but business.

[@erkintek]

I couldn't concentrate after subscribe button, clicking sound. 😮.

[@daviddelaney363]

Let’s all do the Agile Kubuki dance instead of writing code.

[@Tensquaremetreworkshop]

Agile was created as a cynical satire that programmers fooled management with. They called freewheeling programming a 'system'. Managers bought it hook line and sinker. They had created a monster.

[@user-kt5hx6hl7m]

What's up with the never ending coffee table music in the background, get's annoying fast.

[@kandycan]

Insightful.

[@jf3518]

Scrum is imo the worst of it all. Agile is people before processes. Scrum puts this all onto its head with processes before people and puts up some weird roles into the team. Scrum Master is an evangelist for agile??? Nothing more than a glorified secretary at best. Product owner is an overloaded role, with so much needed power and insight in all the business needs that this role is also outsourced to IT service companies because customers usually do not have somebody capable for this role. :D Meanwhile forcing unnecessary arbitrary two weeks sprint lengths on the whole team. The whole process is an abomination of meetings and unnecessary process. But it works, because the whole point of Scrum is not success, but TRANSPARENCY. By the way, I am a certified scrum master.

[@bramvanduijn8086]

I see the product owner role being overloaded as well and I don't get it. It's almost as if they're being put in the mold of project managers. I think the first mistake was thinking that product owner should be a full time job. It cannot be a fulltime job, and you cannot own multiple products. It simply doesn't work because you need to have a deep understanding of everything involved, and that's barely possible for a single product.

[@paulvantongeren2780]

“We” had a good idea: we want to come together with them. “They” fucked it up. Now “we” have to have another great idea: we still need to come together. But we have to take the lead. … That’s a good recipe for success. NOT.

[@dj_jiffy_pop]

Agile, as I've been most recently exposed to it as part of a small, quick-moving mobile dev team in a very large U.S. financial institution (you've heard of it) that "implemented Agile" 6+ years ago, is a self-imposed organizational anti-pattern. At least half of the tech side of the company is not, AND WILL NEVER BE, "Agile"... specifically, services and backend tiers. So there's an impedance mismatch there, and it's a big one. Sorry, Agile Evangelists, but I don't get the feeling that "Agile", in its current widely-accepted definition, is ADAPTIVE enough to accommodate reality. My definition of reality: give me a PROJECT-SPECIFIC process that simply sits smack dab between waterfall and 2-week "sprints". I'm sure Pure Agile is better than sliced bread if you're working on totally self-contained projects with no significant outside dependencies, where an ACTUAL FUNCTIONAL SPEC really and truly is optional, etc. etc. etc. I'm sure it's fantastic if you own the whole deal, but that's not reality in anything resembling a large, disparate, cross-functional technology organization. The irony is: before "implementing Agile", my dev team (~30 mobile devs in a 200K-person company) had VERY close working relationships with business partners, QA, and UX. Now, 20% of my dev team's time is taken up with what I like to call "Jira Engineering"... everybody sitting in conference rooms and on WebEx's shuffling "stories" around a web page and trying to figure out WTF the actual requirements are because nobody actually captured them in a complete, consistent, and cohesive manner. If all of that Agile and Jira money had been spent on a.) more QA resources, b.) more reliable SIT environments, c.) more QA resources, and d.) more QA resources, then the company would have been much, much, MUCH better off 6+ years on.

[@stevefromsouthafrica]

Don’t agree at all. Agile healed divide massively. Put another way, business haven’t so much ‘taken over’ agile as rather they’ve been aligned with a better approach to collaborating.

[@delanym]

Cool man

[@T1Oracle]

Agile is still alive and well. No one is waiting two years to see a demo of a $100 million software project anymore. They expect regular updates and the ability to give feedback. That's all agile is really. All the extra stuff us just cultural. Everyone has a different personal preference there.

[@wewantthefunk73]

Government has entered the chat

[@MobsterSam]

​@@wewantthefunk73 beat me to it!

[@Gamerlegend123-f3k]

Nonsense. They just spent 5 years if tiny meaningless changes because it wasn’t done right. Plenty of agile projects still takes months or even years to develop

[@adambickford8720]

Not. Even. Close.

[@pdebie1982]

Problem is that it’s even more micro-managed these days. 2~4 weeks of waterfall instead of actual sprints.

[@michaelz8260]

This is like the weightloss people that took over keto and brought all their trash weightloss theory with them.

[@musicalintuition]

Agile is an excuse for managers to sit on their asses and watch the team do the real work. And they call themselves leaders. Nope.

[@perfectionbox]

I subscribe to LMHALMC: Leave Me the Hell Alone and Let Me Code 🤣

[@T1Oracle]

You still have to work with a team. The other devs, the business people, the customers, they all have to be in agreement. What you code may not match what the customer wants to buy.

Yes unfortunately this isn’t leading. Business people expect to deal with mature people, devs who can talk business language. If there are none of those then you can expect business people to take the lead.

[@dfs-comedy]

Honestly, Agile always seemed to me like an elaborate joke rather than anything real, even from the start.

[@marsim4150]

agile certification, seriously ??!! What a kind of certification is an online test made without identifying the candidate, without survveillance during the examination and all possivle questions and answers available to select the exact answer from?

[@DSAK55]

It got stiff

[@Daijyobanai]

Agile is an excuse for PMs to introduce new features during and at the end of every sprint. A sprint is short period of time during which PMs try to force down estimates so that developers have to demo unfinished work, or admit failure to meet those halved estimates. EVERYTHING ends up in the backlog, nothing ever gets optimised or indeed properly completed, and the task-board is used to harass and shame any developer who had an off-day, because they were tired and didn't perform. Agile has become premium BS. It could have worked, but all the wrong people got the authority and power.

[@a0flj0]

Someone should point out to your managers that in agile the only people with authority over estimates are the developers. That's it. Break this rule and nothing holds anymore - most importantly, deadlines.