How Agile failed software developers and why SCRUM is a bad idea

[@nigh7swimming]

Shielding your team from corporate BS is crucial to productivity.

[@maxron6514]

How ?

[@EbonySeraphim]

@@maxron6514 how? A manager that doesn’t know how to do this shouldn’t be a manager? Find ways to make sure your team is productive and not switching directions every two seconds and getting nowhere, or focusing on something very niche and a more general failure. Find ways to avoid doing things and fail to enforce things that hurt team morale. If you’re directly told to do something, you can do it and still communicate with your team your disproval of it and inform them if the decision is made versus a battle is still ongoing. There’s so much to shield

[@THEROOT1111]

Big companies understand that, they don't use scrum, but they do have ownership which means many good things and all the bad too. They are fluid to whatever gets the job done, it IS a team effort after all.

[@maxron6514]

How do you shield a team of engineers from bs like scrum@@EbonySeraphim when it is already established and like, the norm then.

[@TheEvertw]

Nothing wrong with having a product owner who pushes back against sales drones who want a color display on your toaster. You don't need SCRUM for that. And SCRUM is no guarantee your team actually is shielded from corporate BS, only when the PO and SM do their jobs.

[@Hndshks]

In my experience, I think the problem with Agile in many companies is that, outside of maybe some high tech places like silicon valley, in most organizations software developers are treated as a sort of red headed step child of the company. We are a necessary evil for them to ship the product that the true stars of the show, the sales team, promise to customers. We are the absolute bottom of the totem pole in most corporate environments, ranked somewhere just above the homeless guy who lives in the woods outside of the building and just below the cleaning staff. In such an environment, software developers will never be allowed to self organize and make decisions like the intelligent engineers that they are. Instead, Agile is implemented from the top down and used as a way to micromanage the dumb lazy code monkeys who can't be trusted to pick their nose unsupervised. The best part is that management can just go out and buy Jira and they are off to the Agile races, because it turns out that Agile is actually 100% about tools and processes and 0% about people and interactions.

[@phonyalias7574]

I see a twofold issue. Unless the actual product being sold is software, developers are seen as a cost center, you're in that same category as customer assistance where it's something ancillary to the product that is expected to exist for the customer but doesn't provide real value. The other problem is that businesses like processes and there's an infatuation with taking all work, no matter how complex, and distilling it down to a series of steps on a checklist that anyone can perform with no training. To an extent this brings efficiencies and eventual automation to the workplace, but when that same mentality is applied to agile, you transform from a set of loose rituals, guidelines, and mindsets to a rigid workflow that is about making an inflexible "efficient" process. Companies don't like non deterministic workflows where everything is decided by knowledge, experience, and compromise, opposed to measurable distinct steps and results. And it's understandable as they need methods to evaluate employees, but that just doesn't work well with software.

[@litjellyfish]

Funny part is AGILE was developed by and for developers. In my view it started out the opposite. AGILE was done to “protect” the devs from the evil waterfall PM TBF AGILE is the opposite of micromanaging as the ownership of the user stories is handled to the devs. And in a committed sprint the PM can’t go in and fiddle. So it’s interesting that you feel that about micromanaging. For me AGILE sucks in too to bottom the worst people. The pampered devs that want to do stuff “their” way and is protected by the user stories. The PM who feel they want to regain control through endless meetings. And scrum masters and agile coaches that usually don’t have a clue, is not needed and don’t want to feel left out it so at every chance try to change to “improve” the process. (Which again ironically not is what AGILE really is about) But most interesting is that it seems that both “sides” devs and product owners feel AGILE takes away their ownership. I still just need to remind that AGILE was pushed and owned from Start by devs and not management. In the contrary it’s only the last 10y or so upper management have embraced it as they started to read how cool and how much better everything is with it. (Without any rel data to back that up apart from the praising of… guess who. The AGILE evangelists themselves…)

[@litjellyfish]

Also for most managers JIRA is to technical so they don’t even know how to use it so they order devs to set it up for them in the totally wrong way. It’s so ironic

[@jus3278]

​@ianajax currently experience this at my job. I don't think any of the PMs really understand how to use it and generate dashboards

[@Alkis05]

That is not just software developers, any developer is treated like that. To paraphrase the wire, "Do you think the guy that the invented MacNuggets is rich? No, he is just a nobody that no one cared about."

[@recmtnbiker4368]

Working as a software engineer was better back in the 80's and 90's before scrum. I graduated college in 1982 with a degree in electrical engineering and worked as a software engineer since 1987. I started working exclusively as a contractor in 1990. Since I mostly work in real time embedded, safety critical software, I hadn't heard of scrum until 2016. I worked at a job that does scrum in 2021 to 2022 and it was like being a character in a dystopian sci fi movie, with all their cult like behaviors. Most of my career I worked autonomously and was treated like an adult. With scrum and the pointless daily morning meetings, employees are treated like six-year-olds. I just started working what will probably be my last contract job before I retire for good, with a former employer in the commercial avionics industry. The reason I went back there, and not some other companies is because they are not doing scrum. It is good to be able to work autonomously and be treated like an adult.

[@sunay72]

But the whole point of scrum is : Employees are intelligent and can work for themselves. I am sorry but seems like scrum was being implemented in a bad way with your company.

[@recmtnbiker4368]

@@sunay72 Scrum doesn’t work well with real time embedded software. There is no user interface for people who are easily amused by shiny flashy bells and whistles on an inertial navigation system for a commercial jet for example. For an indivisible product like this, an MVP is a complete product. Tell me how you would break down the design and implementation of a kalman filter into a bunch of infantile two week sprints.

[@sunnohh]

@@sunay72scrum doesn’t work for shitty business widgets either

[@DouglasRenwick]

u must have god tier coding ability after 35+ years experience. I've been coding for 1 year and everything is too simple to get a deep understanding.

[@fulconandroadcone9488]

@@sunay72 the point of system does not have to agree with design idea. That is where ideas that turn out to be bad after 5s go into real world. It sounds good on paper but it creates so much misery that all you can say is:"You haven't tried it the right way".

[@hypatia4754]

Making introverts tell each other what they're doing every morning on a long term project when sometimes days go by with very little being achieved is effing painful. Just a way for management to micromanage the sh.t out of everything

[@fredmercury1314]

That really depends on the team and the manager. The fact is, that meeting only needs to take 15 seconds. The basis is for everyone to have an opportunity to keep each other abreast of any *important* information, and for people to exchange ideas they may have had that might affect something someone else is working on, and an opportunity to highlight any issues people can see coming down the pipeline. It's only painful when you're doing it wrong.

[@buxton5165]

@@fredmercury1314 Every time I see some criticism of agile I see exactly what you say "you're just doing it wrong". Most places are doing agile wrong but it's impossible to change because management has been told that agile will solve all their problems if they just follow some rigid principles. It's useless to say "you're doing it wrong" because management doesn't have a clue about how it's supposed to work and just love the micromanagement of standups and the rigid timescales of planning and sprints.

[@pb7379-j2k]

“Still working on X…just like yesterday”

[@fredmercury1314]

@@buxton5165I know. But in the right company, with the right team, Agile works and works extremely well. I'll never understand how people can equate "agile" and "rigid". You literally can't have one with the other... lol

[@MarianneExJohnson]

I'm not even an introvert. That's not relevant. Me having to be on a call every morning to tell everybody what I was working on yesterday and what I'm going to work on today *is a complete waste of time.* They don't care what I'm working on right now and I don't care what they are working on right now. If I need to talk to someone, I can walk over there or pick up the phone any time. Agile is BS, always has been, always will be, and everyone who says "you're doing it wrong" should just DIAF. Here's how you run a software project: use an issue tracking system, and have meetings once a week or once every other week to talk about whatever the team members want to talk about with the entire team, and to discuss if priorities need to be adjusted. There, done. And now put that useless Scrum Master to work on some actual coding.

[@markw.schumann297]

Very common for strict, top-down management to impose "agile" processes to make sure they have maximum control. The word "agile" has barely any meaning in corporations now.

[@What_do_I_Think]

Agile and processes are an contradiction in itself. Agile is oposed to processes. You need some processes, yes, but the first law of Agile is, People over processes. So all what those companies do IS NOT agile. It is the opposite most of the time -- and scrum is the means of companies to hide that they are not agile!

[@kristianlavigne8270]

The height of productivity and developer happiness was in the 90s and early 2000s with true agile, working simply from a backlog of roughly prioritised items and being almost completely autonomous in a lot of web agencies at the time, with simple tools and frameworks, just enough to get it done. Now everything has been bloated beyond comprehension. What used to take a dev a week now takes a month or more and multiples of engineers.

[@fredmercury1314]

EXACTLY THIS. Agile was killed by the management. This is not Agile.

[@mattvideoeditor]

As we get old, new stuff will always be annoying. It doesn't matter the decade, people from the 80s probably hate the 2000s

[@cleitonluiz7136]

Agile was corrupted by management and big corporations.

[@mortisoculi8943]

I recently got a new scrum master. They moved our daily stand up to right before lunch, and also made them less mandatory, and only require people to attend on Monday and Friday, for a plan of the week and weekly recap. Our team productivity and quality increased, and it also increased our team moral since we were getting ahead of schedule

[@errrzarrr]

👏🏻😊😊

[@Kandralla]

Not a dev but I am an engineer. I worked at a company where we were doing the intent of agile and I never even realized it until the next employer brought in a bunch of consultants and we all got trained in agile. The former was a breeze, we were extremely productive and things ran incredibly smoothly... The latter was a disaster... You had to have a scrum in the morning, you had to have a retrospective, you had to play that condescending planning poker. It took a six month project and made it take three years. You know what the defining featuee of the good one was.... One key phrase that was uttered frequently by the scrum master and product owner... "is anyone getting anything out of this or are we just wasting our time"

[@fredmercury1314]

@@KandrallaNo, you were doing Agile then you started doing Scrum. They're not the same thing. Scrum is for management, Agile is for customers and developers.

[@yoggg932]

so skipping 15 minutes of a call per day less improved productivity? sorry, I don't buy it.

[@boldvankaalen3896]

The way that i learned SCRUM is that it is not the job of the scrum master to organise the meeting, or to determine the when and where, only to make sure it happens.

[@jacoberinc]

Scrum really needs to do an introspective on itself. But I am afraid that the inevitable result would be that Scrum isn't doing Scrum right and if Scrum would just do Scrum right then all its problems would be solved and productivity would jump up by 10x.

[@recmtnbiker4368]

There is no right way to get bitten by a rattlesnake. It is better to just avoid rattlesnakes

[@CTimmerman]

"True Scrum has never been tried!"

[@fabiolean]

When all the excuses for scrum's widespread hatred sound exactly like the excuses as for why snake oil didn't cure my gout, it makes me wonder about what's actually being sold and who is benefiting.

[@CTimmerman]

@@fabiolean It gives useless managers something to do and track.

[@Nocare89]

Let's have a short 2 hour brainstorming meeting about this.

[@aaronbono4688]

Jira was not created to manage teams for product development it was designed initially as a support ticket tracking system. These are two things that are done very differently. When I first started using it years ago I could tell that it had been morphed and mangled into something that could be used to manage projects and it did it very very badly and it still does. This is why it's one of the worst tools to manage projects still.

[@someguyO2W]

Sadly, we moved to Jira from Asana after a merger. Hate it!

[@andynn6691]

Yeah, the "agile" process features were initially a plugin which was later aquired by Atlassian.

[@MK-lh3xd]

Depends on what you were using before. If you were MS Project, Jira feels a lot better.

[@aaronbono4688]

@@MK-lh3xd actually I disagree, Microsoft project was a lot easier to manage projects. The only real problem was it was hard to be multi-user and it was expensive. But jira has always sucked as a project management tool

[@johnmoe2806]

You should see what our organization uses Jira for. As a software developer I cringe when I see non developers with good Jira knowledge use it as a hammer where everything is a nail. Their non technical leaders seems to love it. So many processes and "applications" made with a ticketing system makes me wanna puke.

[@macnlz]

I tried implementing Scrum for a project a decade ago. About a month in, the feedback was “it’s way too rigid!” People were really unhappy. So I sat down with the team to listen to which parts worked, and which parts didn’t. We kept only the parts that the team didn’t mind, and it resulted in a rapid, focused, and ultimately complete bring-up of a new project, using only a small team. Our tailored-to-the-team “Scrum lite” really helped us stay focused and allowed us to quickly react to new insights along the way. Now I work in a much larger team, on well-established decades-old software, and Scrum would make zero sense here, I think.

[@spottedmahn]

I love that approach & is the fundamental principle of Scrum that I rarely see adopted. Scrum is a set of guides not rules. Use the parts that make sense for the team & environment. Plan your work & work your plan 🔁; usually in small iterations.

[@sebastianwittmeier1274]

Which parts did you keep, which did you skip?

[@puppe1977]

That's why you have retros, to adapt scrum to suit your team.

[@ifstatementifstatement2704]

I’ve used agile for years and understand what it is. But to me it has come to mean being asked every morning by someone who does not understand anything about programming, if I have finished the task yet.

[@boldvankaalen3896]

That sounds like a manager or product owner is at the daily. They should not be there. The daily scrum is only there for the team to identify bottlenecks and help eachother. If there is nothing special, the meeting can be over in one minute.

[@collenfisher3635]

​@boldvankaalen3896 This fact should be the primary element of the daily stand-up.

[@LukeBrady]

This absolutely this

[@duchampsrook]

Does the Agile team agree to their commitments each Sprint? If so the TEAM agrees on the work and attempts to get it done in the arms of the Sprint. To hard for you?

[@mikeryan2388]

Snake oil salesmen is what “Agile” coaches are. It’s just amazing how they have lasted this long, and largely succeeding. Not success is terms of their processes improving developer output, but success in raking in the dough without breaking a sweat.

[@mikeryan2388]

@@Rcls01 What's the difference? Developers need to code. The people you describe sound basically the same except the second is delusional to the point of believing the snake oil really works. They see themselves as a martyr that nobody appreciates. Whatever shielding they think they're doing is likely leading to critical information not making it to the developers because it's incorrectly relayed or blocked altogether. When done incorrectly things can go from good to bad, and then bad to worse.

[@elcapitan6126]

they tell management what they want to hear and give them what they want. that's why they make so much money selling bs.

[@piotrd.4850]

@@mikeryan2388 Actually, no. Coding is waste and should be eliminated. The less code and the cleaner design THE BETTER. But SCRUM 'oh-so-agile' requires metronomic pace, like slave-rowers on galleries, therefore some junk must be commited because "this is value!"

[@TheEvertw]

Same for "LEAN" coaches. Real LEAN coaches make sure the CEO is actually on board with it, and test this by publicly humiliating him, blaming him for all the dysfunction in an organisation. If he takes it on the chin, they will work for him. If not, goodbye. But most "LEAN" coaches butter up to the CEO and blame the workers instead of those who are actually responsible.

[@gaiustacitus4242]

@@elcapitan6126 A competent manager who understands cost accounting principles and sound engineering practices will see through the BS.

[@stephenwall9036]

Well said!! You struck a chord with me here. In my experience, it is a nasty micro-managing tool which pressures teams into a tedious slog. It removes any enjoyment from the job. If I say this , then there is always someone telling me that I wasn't "doing it right". Whatever...

[@recmtnbiker4368]

There is no right way to get bitten by a rattlesnake. It is better to just avoid rattlesnakes.

[@kristianlavigne8270]

Exactly right ❤

[@DudeWatIsThis]

I do agile in my company. - There is exactly 1 team meeting every 2 weeks - the sprint meeting. - I casually stand up once or twice a day and ask "Is everyone doing okay? Does anyone need anything?" - When something is difficult, we get into pairs. - No pull requests, no dev ops beyond having "master" for client-builds and "dev" for production. Everyone pushes and pulls in the branch they're working on several times a day, and solves the minutia daily by talking to others involved. - 2 to 4 times a year (depending on the person), I talk to every team member in a 1:1 to see how they're doing. - There is exactly 1 person from our company in client meetings - me. Productivity is good. We are fast. The clients are happy and keep hiring us. This is what agile is supposed to be, not some retard who cannot code calling you 3 times a day to ask for feedback.

[@jennyx5429]

I can't descript how much I hate agile. I feel I'm like a mice running on an endless mice wheel. I'm overwhelmed with all the meetings and processes. No time to think. Agile is harsh to developers. If you want to work life balanced job get out ASAP!

[@-Jason-L]

Agile and scrum/SAFe/etc are different things. Agile is defined in the agile manifesto, which doesn't say a single thing about meetings or processes.

[@therealantiarchitect]

@@-Jason-L actually it does. "Individuals and interactions over processes and tools."

[@rmworkemail6507]

Want to get out too. Where I can find those organisation doing proper engineering practices so they hire me? I am overwhelmed by Agile rituals.

[@jacoberinc]

This is exactly my experience. The 2 week Sprint rolling into 2 week sprint rolling into to 2 week sprint is just a nightmare. Tickets tightly estimated and packed into the 2 week period with daily progress reporting(often multiple times a day), leaving you feeling rushed with no time to actually think, plan and coordinate because you are to busy implementing, implementing, implementing. Trying to meet imaginary deadlines based on imaginary estimations of complexity that are always wrong. Nobody has time to actually communicate and collaborate because everyone is equally rushed on their own tasks and don't have time to actually discuss and plan properly one with another.

[@recmtnbiker4368]

If I was in college right now and majoring in computer science I would take extra math like liner algebra and electrical engineering courses to get jobs in more math intensive industries like inertial navigation systems because they tend to be more scrum proof. Agile scrum makes me glad to be nearing retirement. Working as a software engineer was better back in the 80's and 90's before agile scrum. I graduated college in 1982 with a degree in electrical engineering and worked as a software engineer since 1987. I started working exclusively as a contractor in 1990. Since I mostly work in real time embedded, safety critical software, I hadn't heard of agile scrum until 2016. I worked at a job that does agile scrum in 2021 to 2022 and it was like being a character in a dystopian sci fi movie, with all their cult like behaviors. Most of my career I worked autonomously and was treated like an adult. With agile scrum and the pointless daily morning meetings, employees are treated like six year olds. I just started working what will probably be my last contract job before I retire for good, with a former employer in the commercial avionics industry. The reason I went back there, and not some other companies is because they are not doing agile scrum. It is good to be able to work autonomously and be treated like an adult.

[@brandonpearman9218]

Fantastic. Great to hear that there are devs out there noticing the problems. It feels like everyone is just doing scrum and not questioning it. Lets keep up the push.

[@rmworkemail6507]

Where I can find those organisation doing proper engineering practices so they hire me? I am overwhelmed by Agile rituals.

[@brandonpearman9218]

@@rmworkemail6507 Scrum is a systemic problem, very hard to find a company that will actually adapt to each teams needs. A few things to think about 1. What is "proper engineering practices", every team/company is different and this changes over time, so the goal is to find a team that aligns with what you are looking for? 2. Agile does not prescribe any rituals, I think you mean scrum rituals? Scrum != agile But yeah, its a shit show at most companies.

[@Srulio]

Unquestioned because questioning the agile idolatry is a career limiting move in most companies.

[@brandonpearman9218]

@@Srulio first, scrum != agile most companies that do scrum are not agile (some are). Second, if your company is limiting your career because you are questioning your own ways of work, then leave. Companies like that need code monkeys, not engineers.

[@JeanPierreWhite]

If you don't question you have given up.

[@AllTheFasteners]

I'm 42 now, so I've seen several of these paradigms come and go over the years. In my humble opinion the fundamental problem of software development comes from demand being far greater than the supply of competent programmers. As a result, management are always looking for ways to scale the teams up using less capable people, which seldom works and can actually make things much worse. A single, competent programmer with design authority can often be more productive than ten average programmers being micromanaged. I used to part own a successful business with separate development teams - the team with just two highly competent individuals produced far more value far more quickly than the team with 20+ individuals who followed "Agile" practices.

[@jandejong2430]

This!

[@keithmarlow]

100% - 2 or 3 good focussed engineers can run rings around teams 20x the size made up of average people. Average people generate low leverage code and end up stuck in a mire of their own making.

[@sexygeek8996]

I try not to even hire average people. If I have to work with them then I'll assign them unimportant stuff that won't have disastrous consequences if they screw it up.

[@LordOfElm]

Seen this, experienced this, and consultants have even outright explained to me that this is their job (providing a way for companies to make a project work with less capable engineers because finding enough talent is more difficulty/expensive). Do you think that we lack proper mentorship in the industry, or is this just a fundamental difference between people?

[@AllTheFasteners]

@@LordOfElm That's a very good question. I think it boils down to the differences between people, but this is not necessarily due to personality but rather experience. I have found that software engineers (engineers in general) are much more diligent when they are personally responsible (or have been previously) for dealing with the fallout of their programming. People who have experienced the customer being distressed, or at least being demanding, are far more likely to do a better job as they are used to experiencing the consequences of not doing a sufficiently good job.

[@mofostopheles]

In 2000 the company I worked for hired Kent Beck to coach us in XP. That included paired programming, daily standups, user stories and test-first programming. Some people loved it (almost like a religion) and my career in SD definitely benefited from it. But, this methodology was quickly perverted into Agile and all it’s variants. Suddenly we had PMs and analysts acting as coaches who had no business doing so. Clients also didn’t like paying for double the number of programmers for only 1/2 the output and who can blame them. As the early 2000s progressed we often joked that Agile was just a label that meant: we have no real process or discipline, because we’re so agile!

[@LastStar007]

Pair programming pays off in spades for debugging and coming up with good design early, and it's the best way to spread knowledge across the team, but management just sees 2 people at 1 computer and thinks we're pulling the wool over their eyes.

[@BigMichael78]

Agile turns software engineering into a cycle of desperate scrambles plus your attempts at recovering from the same. When I went into software it was somewhere in between research and production-line work. If you were good at it, you could have "good days" while pacing yourself through the ebb and flow of the creative process, adding up to high productivity overall. No more. The work has lost most of its dignity and you find ways to survive it. Nowadays I mostly watch my investments waiting for the right time to retire.

[@elcapitan6126]

meh it's "easy" to cruise by now since it is so process and rules heavy. as long as you don't forget it's all a bit pointless you can just enjoy the ride and even tinker with more fun stuff while working.

[@dgmstuart]

Scrum does that. Scrum is not agile.

[@fredmercury1314]

@@dgmstuartIt's amazing how many times I seem to have to tell people that. Agile is not "agile", which is the word co-opted by middle managers so they can sound cool.

[@SurmaSampo]

The Agile crowd think that they are self managing and will produce gold if they can ignore business constraints like governance requirements and risk controls. Far too many Devs are Prima Donna artists masquerading as engineers who believe they should never have to provide evidence of defensible decisions or show alignment with strategy. Way to many development projects turn into burning money pits that never delivers reliable tools (yes software is just a tool) for people to perform productive tasks. Without process there is no quality nor governance and without those the risk of catastrophic failure ending up in court is greatly increased. That what process is ultimately for, stopping the practitioner from destroying their customers and organisation.

[@fredmercury1314]

@@SurmaSampoUntrue. Agile is *built* on business constraints, and working with the client to produce what they need, not what they want, without the need for a BS spouting middleman who makes bad promises that can never/should never be fulfilled. Plenty of Prima Donna devs in the world who don't use Agile... I know because I've worked with them.

[@rajdivecha]

I once worked at company where they were using Agile. It was an awkward experience and there I learned that if a team uses Agile, run, don’t join that team, let go of that job as they are babies in the world of project management who are being curious about a toy and like to play with it. They are long way from actual managing a project!

[@LucasSilva-dr6lu]

That's the skill all managers should have: the ability to adapt or pivot their processes according to THEIR TEAM's current needs, and not just copy and paste a "methodology" that is supposed to work for every company/team. An open-minded and experienced manager worths much more than an average Joe with a dozen Agile/Scrum certificates.

[@jenniferhunter7629]

Agile is not a Methodology just fyi. Agile isn't defined by a set of ceremonies or specific development techniques. Rather, agile is a group of methodologies that demonstrate a commitment to tight feedback cycles and continuous improvement. And yes you should adapt to your teams needs.

[@-Jason-L]

@@jenniferhunter7629 agile is a set of values and principles put forth in the agile manifesto.

[@JeanPierreWhite]

Agreed. How the team self organizes is a team decision, not senior management. Finding companies willing to ceed that level of control....... I suggested once that individuals should have a say so in which team and which products they worked on. That was WAY too radical. Managers don't like to ceed that control, but they need to to make agile successful. Therein lies the problem for many organizations.

Omg, I really hate those processes. I changed some processes in my team and later we were obligated to go back to do daily meetings. As a manager I decided to use those daily meetings to talk about flags issues and conflicts from the previous day. Sharing those issues with the entire team. It was 100% more productive than talking about our tasks for that day.

[@NotOnlyCode]

What you mention is the worst part for me - I find some process that works for the team, works for me, works for product owner, but the agile coach says that everyone has to follow exactly the same setup, so now we're all stuck in a meeting that we find useless. Glad you found some productive way to use this time, though!

[@jenniferhunter7629]

you should be flagging issues, impediments, conflicts. Just do it right and don't blame it on a framework perhaps, which actually you are doing.

[@pablog5738]

Forcing processes on teams and not allowing to change is the definition of NOT agile.

[@rmworkemail6507]

@@NotOnlyCode Ironically the Agile Manifesto says to be open to change and adapt. However, the agile evangelists are the most rigid and unwilling to adapt people I've met in the industry. Almost to a cult practice.

[@IceBlueBeard]

@@anthonypaulin1853 But they ALWAYS end up as status meetings. Are you telling me that in your next stand-up you can just say "no blockers for me". Of course not you will be expected to clarify what tasks you have been doing and what tasks you will be doing. Stand-ups are daily status meetings and examples of micro management hell.

[@B00h44]

What I hate most is the fact that 1-3 devs have to do all the work while scrum masters/PO/PM/analists/governance analysts/etc just get away with planning meetings that don't really go anywhere all week and get to send 'sorry not going to make this dsu i have another meeting'

[@elcapitan6126]

yep and they go home on time and are promoted through management. skilled devs are treated as factory / IT support workers

[@litjellyfish]

@@elcapitan6126don’t pull in the Producers and Product Owners into the mess they hate AGILE more than anything. Funny part is that AGILE was done by developers for developers. Key thing is for big waterfall bank projects it was probably good. Where they made plans 3 years into the future for almost only data handling software. With no UI or real user interaction etc. Then the AGILE moment spread and was embraced by devs at it actually empowered them. Problem is that over the years the devs that did the least, liked to discuss architecture and solutions the most instead of coding is the one who used it. As it protected them from the “evil” PM who wanted them to work. Creating an even bigger wedge (I mean in some scrum then don’t see the PM as part of the team - pushing it away from them) Then this spread to other sectors. People taking 3 days courses to be scrum masters, AGILE PM, Agile coaches etc etc. again people who mostly like to talk and discuss and feel important. This is for me the real problem with AGILE. Not AGILE itself that has pretty ok standings But let’s be fair one can summarize AGILE like this Talk to each other on the team. Break down things. Prototype. Don’t commit to things to far ahead in time. Talk to the end user. Try to be cross discipline. Talk to each other about progress. How you solved things. Shout if you have a problem. Share knowledge. Test asap in real world scenarios the work if possible. Or even shorter. Communicate cross and up and down. Test and iterate. And well… this is what normal funcional teams have been done since the 70s… it’s just did not have any name as those teams was focusing on doing and delivering stuff instead of having meta coffee talks all the time. I ain’t bitter no

[@Srulio]

Those meeting have a very important function: planning the next meeting!

[@markbooth]

You would hope developers doing one project at a time are the main focus of a meeting. PM ls can be managing 5-10 different projects.

[@litjellyfish]

If you think that the only work those roles does is planning meetings then you can’t have worked a lot in development. Or have not cared to know the roles more. Also calling the programming / code engineeeing part “all the work” also is very off

[@martinvirando5651]

I once brought up in a planning meeting that by the time we've spoke about it, I could have built and released the component. I was then shouted at "YOU MUST FOLLOW THE SCRUM MASTER" and I removed the swear words. It's become a cult, as a developer I think it actually slows down development.

[@puppe1977]

Research "cargo cult".

[@comicmaster5057]

I was in similar situation... I quit that job.. I suggest you do the same...

[@juliep1122]

Exactly. If you had just given me the project and the requirements, I could have already had it done by the time we were done discussing when we should do it.

[@keim3548]

Do you honestly think that manager who shouted at you would not do so if it wasn't agile but some other set of rules?

[@aw7603]

What you are describing is not scrum.

[@MelindaGreen]

All of these mechanisms are not about creating efficiencies but rather to allow management to feel like they are in control of developers they don't understand or trust.

[@antonfurman5570]

So funny to hear this now! I used to work as a PM some time ago at small level enterprises and it was pretty easy job for me (at least, at that level, cuz it's basically all about listen and talk). When I decided to move to other city and find a better paid job there, I came across with that obstacle, that people call Agile. The moment I started reading about it, I was like "Wait, this just makes things more complicated and adds tons of new vocabulary, both things are unnecessary. I don't like it." And guess what, I couldn't find the job, I got rejected so many times, that it just put a cross on my PM career. I see this topic being raised right now, in 2022, but good to know I wasn't the only one all this time. Maybe I can finally find a normal job again?

[@lfos31]

Scrum is a product. Period. Of intents of profit. They need to keep certifying Scrum Masters, sellings books, selling courses and consultancy services.

[@litjellyfish]

Remember that JIRA started out as a issue tracker for bugs and support teams. Not development. I mean it took JIRA a long time until they even had support for AGILE

[@FAYZER0]

When we were trained in Agile, we were repeatably told not to let the process get in the way. Use what makes sense. We had meetings once a week, and the daily stuff was just typing what you were working on in a sentence or two in a teams chat. Agile absolutely did transform our efficiency in our case.

[@jabr0nicus]

I wish lol. The bad companies insist on at least 1 pointless meeting per day. And God forbid you're contributing to more than one team, you're gonna have multiple standups plus whatever dumbass reviews and planning meetings fall on that day. I dunno how some people tolerate it for years and years but I guess you get accustomed to the inefficiency

[@ericpmoss]

There is agile, and there is Agile(tm), and they bear almost no resemblance. Being agile is like having the Golden Rule. Agile(tm) is a giant religion complete with priests, holy writ, incantations, sins, penance, and Inquisitions. They would declare your agility to be heresy in the same breath they declared it to be their very goal, and they would absolutely drive you out. I have witnessed senior developers be treated like 4 year olds who shit on the carpet because they said a task was harder than a “5” rating but easier than an “8”, and that wasn’t allowed. This from a billion $ company who spent millions on indoctrination and brags about it to this day. Count yourself lucky.

[@jomama55ful]

Agile can work, IF: the team is accountable to each other and communicates well, the Scrum Master keeps management out of the process, Management "Buys" into the methodology, The backlog is "properly" converted into good stories, and that the work is not broken down into hours instead of "story points". Since that is a pretty tall order, it usually fails. I been on teams where it works, and where it doesn't.

[@pjuliano9000]

The really hilarious part about agile is most companies employ it, but still put a line in the sand on the due date

[@khialaaloocompany590]

Exactly - it’s just a veiled way to capture aggressive due dates while appearing flexible.

[@SurmaSampo]

Without a due date most development projects never deliver and nobody can plan around the delivery.

[@JeanPierreWhite]

Sometimes the due date is all important. Think Y2K. One project I was involved with it became obvious that the ability to deliver the product by year end with all the features was not going to happen. We gave the business leaders two choices. Allow us to take longer or remove features to hit the date. They chose to remove features, we delivered on time. It was considered a success by all.

[@whistler9]

​@JeanPierreWhite that's not how it ever works though. Instead you're told to deliver it a day early with more features that weren't planned because the customer asked.

[@JeanPierreWhite]

@@whistler9 It worked that way at a place I worked at that I gave an example. Maybe your experiences have all been at companies that don't respect their workers as they should. If you are given ultimatums you are working at the wrong place.

[@tzampini]

Thank you for this video. 10 years ago, I actually quit a job because they were moving more and more towards agile based development. It was slowing my development down and substantially reducing the quality of the code I produced because I was so distracted by all the BS. I hated it.

[@sourenasahraian2055]

Let me share an amusing tale from my days at a renowned company in 2014, right in the prime of the scrum master era. Our scrum master, much like his peers, was a staunch advocate of conducting scrums while standing - aptly named standups. One day, I chose to remain seated during a standup, sparking his disapproval. Curious, I questioned the rationale behind this practice. He proudly cited numerous studies claiming that standing boosts focus and productivity. I couldn’t help but retort, “And what do you suppose developers do all day?” This moment highlighted the glaring disconnect between these so-called experts and the real movers and shakers who drive progress.

[@puppe1977]

Maybe they would be more productive if they did their work standing up. If you haven't tried and measured it, you don't know.

[@cornchild1]

Yes agile is a whole industry. The agile training industry is a joke. Why do you need 16 hours to tell me how to write a user story or use a sticky note... Is all bs to make $$$ I spent at least 4 hours a day in bs meetings

[@elcapitan6126]

there's so much money to be made exploiting management naivety. managers wouldn't buy it if it was brutally honest (e.g. if we said "estimates are bs")

[@arnoldvanhofwegen2255]

Yes and there is always money for these BS trainings and they are not cheap, but no money for a real training (are they afraid you run off is you can do more than or better material, office chairs, stand-up desks, larger monitors, the right software to work with.

[@CoachMitchellh]

I couldn't agree more. I can't get any work done in agile methodology. Just way too many meetings.

[@recmtnbiker4368]

Scrum should be outlawed for safety critical products. It puts unnecessary time pressure on developers and testers, which could make them overlook latent bugs in the code. I have worked as an engineer since 1982 and as a software engineer since 1987, mostly in safety critical real time embedded software in the commercial avionics and medical device industries. Agile scrum is incompatible with embedded safety critical software. In making big architectural changes, a task can take much longer than a silly two-week sprint with nothing to show for it until the task is completed to some degree. The same can be said when working on low level software that interfaces the hardware, such as when you have to spend time in the lab using an oscilloscope to verify the data coming across a shift register. Sure, it doesn’t interfere with your work when doing something trivial like changing the layout of a few buttons on a GUI, but even then, with all those pointless meetings, it is a colossal waste of time. In my first DO-178 (safety critical standard) job, by not being rushed and micromanaged, I was able to discover latent bugs in an avionics product that was written in assembly language that other engineers had overlooked. It was usually a comparison statement using a variable using indirect addressing versus direct addressing. That is similar to misusing a variable that is defined as a pointer to an int as an int or vice versa. The data that was in that location just happened to be a value that coincidentally would work, but it was subject to change to something that might not work in the future. Getting things done FAST should NEVER be the primary goal in safety critical software. And I am not anti-process. Safety critical standards like DO-178B in aerospace and IEC 62304 in the medical device industry define the SDLC, but the things they deinfe make sense, like requiring 100 percent path coverage in testing flight code, because you don’t want to be flying near an airport and find out the altitude reading froze up because the code is stuck in a while loop. All the things I see being done name of agile scrum make no sense. Unfortunately, even some aerospace companies are starting to do this agile scrum nonsense. It has the look of - All the cool kids do agile scrum, so the cool kid wannabes emulate the cool kids to try to be cool themselves. Fortunately, after starting a new contract job that will likely be my last job before I retire, they aren’t doing agile scrum. I actually sent a resume to them because I figured they weren’t doing that nonsense and didn’t send a resume to some other companies advertising for SW engineers because they said they were agile. Things that make me glad to be nearing retirement: Agile scrum and open office seating arrangements. Working remote at least mitigates open office seating arrangements. Fortunately, working in what will likely be my last contract job before I retire, working on a safety critical product in commercial avionics, they are not doing agile scrum.

[@errrzarrr]

Please, speak up more👍 we need this

[@gdofred]

Yes! I understand moving away from waterfall development, but I think having spiral development provides those intermediate milestones without abandoning the fleshing out of requirements and coding to requirements instead some user story a coder wrote based on a five minute read of those same requirements. I'm also 30+ years of safety-critical software development.

[@fredmercury1314]

Agile without the Scrum is what you want. Scrum is clutter.

[@ericpmoss]

Agreed - Agile(tm) priests deemphasize the most important part of the manifesto, which itself only touches on what is truly critical - deep comprehension of the problem space. Agile(tm) treats every project like it’s just adding web pages - rethinks simply don’t fit.

[@MrEdrftgyuji]

Some elements are good, such as avoiding the trap of spending months writing all the design documents up front and leaving all the development to the end. The issue is, management see agile as "daily stand ups" and "two-weekly sprints" only.

[@josefknaus9709]

I am at the end of my career. I did software and firmware für nearly 35 years. Each 5 years our management wanted to add an new process or methodoligy. Not knowing what the problem really is. I like your video. The developer who do the job becoming less and less. The reporter become more and more. It's true!

[@Arhnuld]

I teach software development at a university and I use Scrum to coach the first student projects. I find it a good learning tool for students who haven't worked together on a project before. It's better than having them reinvent the proverbial wheel. On the other hand. I see it as a phase you go through. The faster you can move away from it, the better. I cannot see myself working at any organization that still uses Scrum in a professional context. And I absolutely hate the concept of professional Scrum masters (who can't even do the actual work) with a passion. For at least 80% of workplaces it's a bullshit job scam, plain and simple.

[@dgmstuart]

100% this: Scrum is as good a starting point as any, but the goal is to iterate away from it towards something which works for your team.

[@gaiustacitus4242]

Scrum is a good approach for defining bite-sized tasks that unskilled developers can be assigned, but this is not suitable for a professional environment.

[@JeanPierreWhite]

Good organizations allow each team to choose their agile practice. Scrum, Kanban, Scrumban etc. When the choice is made by management that's where things can come unglued as practices don't match team maturity and ability to self manage. As a scrum Master it was always my goal to make myself unnecessary. My ability to accomplish that depended upon the corporation's approach to agile. In one organization I was only able to manage one team due to practices imposed on me and my team, which was silly, in others I could help 3 teams before my day was full.

[@gaiustacitus4242]

​@@JeanPierreWhite How teams choose what to work on isn't the problem, Agile is. Teams can't work efficiently when there isn't a formal specification for the entire program. Agile ensures that development will be inefficient, will cost more than budgeted, and will either face schedule delays or have features eliminated in efforts to deliver something on schedule. The use of Agile is almost a guarantee that a project will fail. Over the years, I've witnessed poor software project management destroy entire divisions of large corporations. At its core, Agile is a failure to plan (at least beyond the very near future). There is an old adage that goes, "Failure to plan is planning to fail." It is impossible to measure progress and success when all requirements are not known.

[@JeanPierreWhite]

@@gaiustacitus4242 What you are describing with a full and complete formal specification is akin to waterfall approach. This approach has had many of the failings you listed in your reply, especially on large complex projects. For shorter projects of 6 months or less waterfall may make sense and even be preferable when it *is* possible to know all the requirements with a reasonable degree of certainty. Once a project continues beyond 6 months or is part of an ongoing open ended product development over many years then waterfall is almost sure to fail, agile was created for such long and complex projects where requirements cannot reasonably be expected to be known. Even if the requirements are well known today, if the project is over many years those requirements will most likely change anyway requiring a flexible development methodology, not a rigid one. A good portfolio manager worth his/her salt will be able to determine at project initiation if waterfall or agile is appropriate. I would agree that using waterfall for all projects or agile for all projects is a mistake, there is a decision that needs to be made upfront. It doesn't have to be either or.

[@akiwoo5205]

TLDR: The value of SCRUM depends on the team and management. I think it really depends on the environment. When the team is fairly large with a lot of junior developers, the per-team standup can help a lot. There are too many times where a junior developer had been stuck for two days and didn't tell anyone. Even worse if they were redeveloping something that already existed in the framework or they didn't like the implementation of. Our PM's were generally not invited or optional. Each person is limited to no more than two minutes. It can pull a dev out of the flow, but the value out weighed the ~15 minute remote call. The review can be another useful item. It depends on the environment, but there are times when management doesn't verify that what was delivered met their expectations. It's not uncommon to have course corrections after a sprint review. It generally boiled down to management not having time to verify at the delivery, but had time later to say the signed off spec is not what they wanted. Or if there was a misunderstanding (which we devs never, ever have ;) ) On the down side, sometimes the review took too long since a system may need to be setup in a certain configuration to show all of the functionality. However, it was much easier to do so when it is still fresh in the dev's mind rather than months later. As you have mentioned, it can be a long process to change how management does things, if at all. Especially if venture capitalists have purchased the company and removed a good portion of the staff to make the company valuation look good. (Hint: That's a good time to find a new job.) I think the worst part was the planning. The meeting can bring in too many resources for too much time. It worked best for small teams which have a smaller feature set to deliver per sprint. I've never seen a SCRUM Master as the only thing a person did. The role was generally handled by the team lead or a senior QA member to simply keep the process on the rails. In summary, IMHO, it depends

[@Paul-uy1ru]

That’s my experience too. It really depends on the team dynamics and the concrete implementation of the meetings. For my employer scrum was a solid step forward in terms of productivity overall.

[@alxk3995]

Yep. I have to agree. We pick what works for us and leave things out where we see no benefits. Daily meetings range from 10-15 minute "everybody is on track, nothing big came up" to 40 minute "ok this is important we need to collect Infos and assign tasks".

[@Eff917]

IMO The same concept applies for project management/workflows as for tools. Choose the right one for the project, don't try to force the project into the tool. Same here, choose the workflow for the project/team, not the other way around.

[@menninkainen8830]

Bluntly, for the most time scrum works best, when the team is most successful in ignoring it. It's just yet another process.

[@senso9378]

No, it's a fail by design

[@julkkis666]

Thinking about my experience with scrum meetings is that the meetings where we look throusgh the board i personally zone out quite a lot since there are too many people doing too different things that are not relevant usually to me, as in entierly different systems. The best recuring meetings are between those you actually work with where you bring up what's going on and think of a plan for the day based on that. I do think that the jira scrum whatever meetings have their value in gettibg the team updated on what's going on. For some people it might work vetter than others.

[@-Jason-L]

I'm no big scrum fan, but what you mentioned is not part of scrum.

[@stephenwall9036]

I agree with every word you say. The troubling thing about this is that there are many smaller companies who are adopting these more formal and bureaucratic working practices. I know, I've worked in them. You have to wonder what their motives are.

[@mjackstewart]

Compared to Waterfall, Agile looked GREAT! But you're absolutely right: In the era of CI/CD, the effort necessary to conform to Agile processes takes time away from development and testing. Communication and documentation should be done via your development management system. And if you have a separate problem reporting/ticketing system, they should be integrated, instead of having to key work requests into two separate systems.

[@donng7560]

I feel so frustrated with Agile in our company, the scrum takes 45min EVERY DAY (with 35min only for the manager to rumble the same things over and over), and we are a small team of 4 people. When we add the sprint planning, the sprint review, the sprint retrospective, the backlog, we are literally burning 93hours per month for nothing... Without this we could almost hire a new developer, but yeah agile is for efficiency...

[@sealsharp]

Jesus christ, that sounds horrible. Our daily is 10 - 15 minutes and my bosses are fine with me asking them to move their long speeches to the end of the meeting so we can go do actual work.

[@mk1roxxor]

@@sealsharp Your bosses should not even attend the daily meeting.

[@sealsharp]

@@mk1roxxor that is true.

[@_Mentat]

I've been there. Best ever was a 23 person morning scrum (in a very small office). Went straight to lunch afterwards.

[@errrzarrr]

Correction: 93 hours per month PER PERSON. Keep that in mind

[@oliverurbanik9647]

Good! My B. Sc Thesis was about Scrum and Agile - thought it would be a good idea back in 2012. After 7+ years in Software Development, witnising the Jira Madness every day my view has changed a lot. Agile and Scrum were ment to empower the Developer - and don't give the management another tool to play arround and meassure ppl's speed and productivitiy. Scrum has become an abomination. And yes - Jira IS a bloated dystopian Nightmare. The workflows i've seen.. give me nightmares to this day. My workplace is using the same methods. Switched from Development to a more support role. Its not perfect either, but i can sleep a bit better.

[@kpbarrow]

The problem with SCRUM is that it looks like a way to convince the managerial staff that they have oversight and control over development. What actually happens in practice is managerial staff are adept at managing, so they turn the process round so it becomes a way to convince developers they are doinng agile while actually doing all the corporate bullshit.

[@mnap1595]

Having recently joined a large organization from a small one, I couldn't agree more. In the last 18 years, I've never felt less productive than I do now.

[@richie5um]

Agile philosophy (i.e the manifesto) is critically important. Agile process is an anathema to 'agile philosophy' - quite literally, it is the first (and most important) point 'Individuals and interactions over processes and tools'. I'm sad that 'agile' has been co-opted into what many experience today.

[@JeanPierreWhite]

Hear hear.

[@futuza]

Exactly

[@brian-lau]

Thanks for sharing! Personally I really hate dealing with various processes when I was asked to deliver outcome in a tight schedule

[@NotOnlyCode]

Right?! Once I spent the whole day on planning session because people were arguing for 30min about estimation of every user story, and that was in a start-up that was rushing to launch a new product

[@inastew1]

What a relief to see this. I thought I was the only one who thought this way. The University I worked for adopted Agile and it has resulted in bloating of administration staff and redundancy in those on the front line ( Academic, Technical staff and department embedded front office staff). I can't imagine why they thought it would work in a University. It seems it is something designed for improving productivity of a single product ie piece of software or widget from a factory. It was never going to work in an organization that has diverse out comes ie multple subject papers and research projects. The first I heard of Agile was when a telecom company adopted it maybe around 2002 when it had a 50% market share ( though this had been dropping ). Redundancies soon followed and 10 years later their market share was 32%. Hardly a success story for Agile.

[@baron1405]

I completely agree with you and your assessment of agile. Unfortunately, I have seen and experienced the degradation of productivity due Agile and its dogma. I often tell my colleagues what an airplane would look like if the Agile process was followed. It would have a fuselage and wings but no engines. When asked why the engines are missing, the engineers would say it was not in the story.

[@ana_carol89]

The agile manifest makes it clear that agile was not designed for traditional engineering. Therefore, it would be against agile principles itself to want to use it to manufacture an airplane.

[@alichamas63]

it's almost like programmers know more than managers when it comes to the best way to build software. Crazy!

[@Hannodb1961]

It is the concept of being promoted into incompetency. People who does their job well get promoted into roles with different job descriptions that they are not suited for.

[@thegeneralist7527]

That is because they do. The hardest move to make is from programmer to manager. Its almost like you have to unlearn one skillset and learn a new one. A person who is good at both, and can keep up with new technology, that person is gold. If you can make that transition you will be very valuable wherever you work.

[@thegeneralist7527]

@@Hannodb1961 Yup. The two skill sets, programmer and manager, are almost like oil and water. Difficult to achieve, difficult to maintain, very rare thus extremely valuable.

[@recmtnbiker4368]

We are living in a time in the software industry that historians will eventually refer to as the “Agile Scrum Inquisition.” Seriously, I see things going on that make me think of the Spanish Inquisition with the way this nonsense is forced on everyone these days.

[@ericpmoss]

I said this same thing, and… was driven out, after writing code that made several people (not me) very very well off. I refuse to work under it, and if that means starving, fuck it - the stress of it killed my best friend and nearly killed me.

[@jabr0nicus]

I feel so validated lol. This completely matches up with my (limited) experience of how scrum/agile-oriented companies are in practice 👏

[@butchdean]

If there is anything that I absolutely hate about software development it’s Agile. I hate the artificial timelines it imposes, like feeling the need to work flat out on a delayed task by the end of sprint. I really f*king hate it. 16 years in the industry, btw.

[@rommellagera8543]

Yes common sense driven development should be the norm. Think/plan - do - check - think/plan again cycle. Most fail to think along the way. Processes does not exempt you from thinking/focusing on the problem and the solution. Agile is a myth, good software always takes time to develop.

[@NotOnlyCode]

I totally agree! I often think that processes stiffle thinking, they try to standarize everything, ignoring that every team is different and works differently

[@jacoberinc]

One of the results of Agile/Scrum is they leave no time to think. Which results in far more wasted time in the end. (although velocity is looking real good)

[@recmtnbiker4368]

That is how we did it in the eighties and nineties when developing software in the avionics industry. Apparently we were doing something similar to waterfall, but we never called it that. We just called it doing our jobs. After working on my first agile scrum project a couple of years ago I decided to only work on math intensive real time embedded software such as inertial navigation systems because it tends to be more scrum proof. Agile scrum makes me glad to be nearing retirement.

[@lhpl]

Common sense seems very underappreciated in IT - and has been so since the first "methodologies" were made up. I like to think that my preferred "methodology" is madness. Methodical madness, to be precise. Arguably, if you take the Agile Manifesto, it really says nothing, so it isn't even wrong. Of course that has never prevented "professional" pm consultants etc to construct a dogmatic reading and a way to ritualise processes, making it about form rather than content. Scrum, is one such construct of rites. Now, using rites - and, less severe, routines - is not intrinsically bad, it seems a very common pattern in human behaviour. Saying "good morning" is a kind of rite. Also, rites are a good way to allow slack - as long as you do the rites right, you don't need to do anything else. I like to compare this with some of the elements of ITIL. (Disclaimer: i am certified in ITIL v2, and have no idea of how it carries over in later versions, I don't even know what version ITIL is at.) This is how I see it: If a Incident is a Known Problem, it means there is a rite for it. Like the help desk mantra, which I now can only recall mentally with an Indian accent: "Pleaserebootyourcomputersir." There is no objective reason to believe that it will solve whatever problem I have, but in some cases it might, so therefore this is the first rite of help desk. And it doesn't matter that I _know_ the problem is not with my computer, as everyone in the office has the same problem, indicating that the problem is the building's network. Helldesk doesn't care - rites must be followed. We are more prone to rites and magical thinking than we like to admit. A smart pm consultant would make conscious use of that. A good one would use it to promote sane, sensible routines. A less good one will promote Scrum.

[@jakubrogacz6829]

@@recmtnbiker4368 Waterfall has the problem of being implementation of complete product via the design. It is inflexible. We should do something in between. But if dev team says that running java 1.5 is probably bad in 2023 it probably is best to listen to them not try to push for another feature. We do software nowadays to whims of investors ( which is fine but along the way there is no quality because investors aren't coders, they won't know untill the bugs cause massive exhodus of users or make a data leak )

[@Tioko]

I’m a digital marketing specialist. I’ve had three bosses in different companies trying to implement SCRUM… for marketing 🤦🏻‍♀️ Thankfully, all three practices fizzled out.

[@nicolasjochem1814]

Yeah, you said it well: careers depend on it. We have so many people higher up, that actually decide whether the knowledgeable developer can or can not do something (e.g. use a certain os or app in the company). It's such a bogus bloated system, but we're not gonna easily get rid of these roles because the people in these roles will do everything they can to protect the for-them-convenient status quo.

[@xlerb2286]

You have described the company I'm at to a T. It used to be worse but we're moving (slowly) in a better direction. The main thing slowing us down is we've had is too many people that think the current process and tools are the only way to go. But the team that bought the company a couple years ago has a solution for that - adapt or leave. It hurts to see some talented people leave, but if they're no longer a match it's better for everybody (I've left a couple companies on those terms and yes, it was better). Our biggest problem now is how to deal with a mountain of legacy code that was squeezed out in two week chunks over a course of several years without anyone ever going back and doing any cleanup/refactoring. Because you know, a new feature always trumps technical debt :) They're off to a good start but I won't see it completed. I'm calling it quits come spring, a bit sad to retire, but not much.

[@fi1689]

I don't even need to see this video, I fully agree 100%

[@RichGilbert]

Very good commentary and very true! I’ve heard so many executives tell me they want to be an agile organization having no idea what it means.

[@markd.9538]

Agile and scrum never ask “why”. They are only “do”. the two need to be together, entwined, at every stage. Agile and scrum divorce the why, because the appearance of productivity is more important than quality and effectiveness.

[@DIYDaveOK]

I originally bought into the Agile koolaid. The reality is that *practical* agile/scrum really boils down to waterfall\stepwise refinement with more meetings and more charts. Worse is that bug fixes almost always get downrated for priority in Agile sprints in favor of short term new "low-hanging fruit." It boils down to users saying "implement this, fix that" and developers doing it in the best priority order they can. Agile makes for pretty charts, but software still boils down to define/implement/test/release/repeat. You can package it all kinds of ways, and that makes management happy, but reality eventually settles in.

[@brianligat9493]

In one company, the first thing a new project team did was to get themselves exempt from having to do Scrums.

[@erikaleksandermoe1634]

I’ve been a developer for 25 years and most of that time was using the RAD method, for which I am very grateful. Later I worked at a company that used the waterfall process rigorously which I felt was really wasteful and never worked as planned. There was always something unexpected that occurred and meant we had to rework and rethink much of the implementation. When I started to work in agile teams I felt I was getting things done, the team felt like a team. But there have been times when I was part of an Agile team where the scrum master didn’t know anything about scrum and we actually used rough estimates (or story point) to estimate and plan the sprint. So there are bad and good examples of implementing Agile. I would say that the core idea of Agile is good but the implementation has become bloated. We should go back to basics and let the developers in the teams decide what works for them and let the reporting be done by the facilitators to shield the developers from unnecessary interruptions and noise. If the team decides that stand ups are a waste of time, scrap it. That goes for any other ceremony.

[@boomergames8094]

I've seen "Agile" and "Scrum" used as excuses to not be productive and get stuff done on time. All new requests, even emergency bugs, have to go on the backlog for quarterly grooming and prioritization and get some points assigned and then not get done. I worked in one group which got a new Director who was all "agile is our savior" and did daily standups. None of us worked on projects together, we all worked matrix with other teams, so communication between us was 99% useless. :)

[@ggananth]

Pretty true, the moment we tried to make the projects 'Agile' our team was less agile. But Agile helps to keep our clients happy because we can record decisions and dependencies in a easy way and deflect blame when things don't go as planned.

[@aaronbono4688]

I have to remind my team members that the purpose of Jira is not to help them do work but rather it is to send reports to management. When you think of it this way then it's a lot easier to use the tool the way the company wants you to use it although it's still useless to developers.

[@ericpmoss]

It’s funny(tm), since I used Jira to tie bug descriptions to committed fixes and improvements, and to explanations of them. But as you indicate, management didn’t care about that - they paid for the Big Brother bullshit like burn down charts. Sigh.

[@MikeCorvin-x4p]

Gregory, you're rant is totally on the mark with all your points! Especially how a good set of core ideas behind Agile has been bloated into a whole *industry* and often mutates into rigid corporate hierarchies and power structures - exactly opposite of the original intent (communicate, create, validate)!! It is exactly the same thing with CMMI, where the intent of defining how a team does their stuff made total sense but in many organizations it becomes onerous (and "just check the effing box!"). Or how obscenely bloated The UML (and SysML) became while the whole point of drawing pictures is to clarify and express aspects of something (fully specifying s/w in pictures is a fools errand... s/w can only be fully specified by.. code!) I can't say enough AMENs to your point about automating the shyte out of everything (that's what I do with our CMMI PIIDs... and many other things). If it's a recurring process it should be automated so all the humanoid brain cycles are spent doing the nonrecurring, hard engineering. As you point out, at least the growth of automated CI/CD has mainstreamed the concept, but not everyone makes the leap to it being generally applicable to any engineering. And PS, totally agree with your comments about Jira... although if you go through the pain of implementing a few simple, custom workflows and stick with that it's ok (don't get me started how Atlassian has f***ed-up Confluence tho... we're ditching it and going to XWiki). cheers!

[@poekiemanpoekieman9224]

Some 25y ago I was involved in a large software project at a bank. No agile and scrum nonsense in those days, but there was corporate bs of course. A very clever guy who was working on it too and on whom many things that actually needed getting done depended always used to say about management: keep them confused! That was excellent advice.

[@Dmittry]

OMG, you are my hero! Now I know I'm not the one who tired of redundant things that take my time instead of doing real job. I'm a developer.

[@Retep4565]

I'm currently hired by an organization that introduced SAFe about 2 years ago. That organization values satisfying its processes over creating value. I can spend almost all my time in mostly pointless meetings. SAFe is in my opinion the opposite of agile. Many times I've been told that they cannot respond to a customer request or an unanticipated situation because it hasn't been planned in the quartly PI planning, and that they cannot deviate from plan because every planned epic needs to be signed off. This means that even a request for a trivial feature takes at least 2 quarters before it can be delivered. Personally I don't see the point of all the overhead. All I need is a prioritized backlog. And when a feature is ready to be demonstrated why wait for a (unfocused) sprint review meeting to gather feedback from stakeholders?

[@stevecarter8810]

I got crushed in a corporate merge and now I'm agile coach watching a SAFe rollout. Every week I say to someone: agile means deliver working software in small batches without breaking the team. I'm here to support your operational goals during the SAFe rollout. If it comes down to a choice of conform Vs deliver, go ahead and deliver and I'll support. We're actually in a place where even safe might help, because we build feature releases twice a year, and don't ask the integrators what they think before locking down the platform code.

[@chimayo]

I said this precise thing earlier when explaining to someone I was interviewing why Scrum has no place in our team. Nicely articulated!

[@JeanPierreWhite]

If Scrum does not fit, you must acquit. IOW choose your own poison, if it ain't scrum it has to be something else.

[@nidavelliir]

My company somehow managed to make an even more bloated version of Scrum. Deploying a single change to production is a nightmare

[@JeanPierreWhite]

That sounds like strict deployment controls, has nothing to do with scrum.

[@tanvirkazi6889]

Hell yeah - agree 100%. Agile/Scrum is a godawful process and i wish companies could see this. I detest having to work in frantic two week cycles to meet some velocity ‘points’. What a stupid way to approach software development

[@mk1roxxor]

I 100% agree with all of your views. Scrum might be a good idea in theory, but it just adds a lot of unnecessary overhead. And when I have to explain to a so called Scrum Master why it is important to address technical debt and that very Scrum Master replies with "How can we track that?" you know that you just don't want to deal with any of this. People over processes? Right... The part where you showed that bloated chart really made me laugh, it shows in such a simple and easy to understand fashion what's actually wrong with development in large companies.

[@IvanGarcia-cx5jm]

I find the JIRA sprints very useful. Without it I would easily forget many things I have to do. It can help me prioritize, and eventually get rid of the tasks that are not relevant anymore. I love the interface to move task in and out of the sprint as priorities change. I also can see what other group members are doing. For example, I can see if a task from them I depend on is prioritize or not, and if not, I could have discussions with them to align priorities. I don't see the sprint as driving our process, but and aid to prioritize the tasks and remembering what has to be done. Nothing else.

[@marna_li]

The main problem with all "Agile" as practiced is that its commercialized towards Project Management, as Scrum and SAFem and not target at software developers who see an actual benefit from it. In this current state of the industry it is hard for find a company that understand the values of the manifesto, let alone having self-organizing product teams who are engaged and empowered to make decisions. Who want to be responsible. Developers are simply coders who wait for instructions from Management, just like with traditional project methods. Just that the processes are different.

[@jakubrogacz6829]

Yeah, problem is software is just not a job like producing nuts and bolts ( although CNC is fun too, but at a large scale it's just running the same thing over and over )

[@marna_li]

@@jakubrogacz6829 Exactly, but that is sadly how it is treated. Not as the creative and collaborative process it should be. I have seen many developers who live for their work - are very good at getting stuff done- but they always maintain that it is just a job. Creating this barrier between work and home. Not coding or learning new things outside work.

[@MaartenBlij]

I asked some colleagues if they’ve ever read the agile manifest. One answered he didn’t have time for it. He was under the impression it was some kind of big manual. Great job on explaining what is wrong with agile.

[@MasterSergius]

Sometimes it seems like Scrum was invented by managers who are don't know sh*t in software development, but want to control software engineers to pay less )

[@galaxya7091]

Was not invented for software development, even not for product with a real customer !

[@TheHeavenArt]

I get your arguments, as a SM, I've felt similar things, though it is also my experience that SMs are hired kinda like enforcers. Like with the responsibilities of PMs, but without the powers, which usually lie with the POs. Personally I've had issues with Leads and other superiors because I've refused to implement changes which were both less efficient and the team was against it. Also the principles of agile often get lost under the need for reporting and standardization, the need to command an control coming from the top and sometimes the SMs or POs is in my view quite common and something one should look for always. When it comes for your opinion with dailies, although I understand that everyday might be a bit over the need, I do see the need for it to exist, depending on the project you might be able to work with more of less dependencies, and dailies help allot getting those sorted up, also specially for remote teams, the daily is the single moment were one has space to get people to know each other and smooth personal relations between the team, AKA actually have a team and not a bunch of randoms working on the same thing. I would agree that an stable team with no changes in the people in it will be much less dependent on the daily. The need for daily meetings is also real just to keep up with those who don't really act like adults, although not common I've had them in my teams, and the only way I've got to vouch for the team with Leads is by observing the daily, which is much less intrusive than other options.

[@anastasios.pappas]

At last, someone points out the obvious! Imagine being in a team where your task takes a day or two then you have to wait for a few days doing absolutely nothing because the other moving parts with longer tasks, are also required to be present to discuss the specs of your new task. Meanwhile you attend daily meetings and watch other people talking.

[@TermoMST]

Great Video, I can sign in on everything you say. In my experience there are additional reasons why we see "Scrum by the book" in so many projects nowadays. Due to lack of experienced team members and/or due to management trying to stay in power, Scrum can provide simple guidance of how to get over with that annoying and scary agile thing. I see many inexperienced product owners blindly following scrum rituals and communicating "See, I did everything that was asked for." to upper management. I've never seen truly experienced teams doing Scrum by the book, but always adjusting it to the point it gets unrecognizable., if using it at all. Every team is unique, so should the processes be. Again, you nailed it.

[@malekith6522]

I hate making demos for sprint assessments. In embedded development, many of the features or things I’ve worked on are challenging to showcase, often reduced to a few lines in the logger. It feels like a waste of time preparing demo scenarios just to prove to the CEO or other managers that I wasn’t useless in this sprint.

[@euden_yt]

Yup, this pushes to avoid refactoring which is a big issue. Refactoring can’t have demos because the product looks the same. As it should. But now Management is gonna think nothing is being done. 🤦🏻‍♂️

[@S_Shant]

This video is strongly well done. The explanation is clear and logical…with a nice encapsulation of the history and where we now are. Excellent!

[@DudeWatIsThis]

The only problem with agile is that it was conceived by smart software engineers, for other smart software engineers, but is being led and implemented by idiots who grew up in a house with a swimming pool, surrounded by money, and with an economics degree their father bought in some expensive place.

[@JeanPierreWhite]

A little harsh maybe, but yes, many organizations who implement agile do so very poorly without regard to the needs of the team members that actually do the work.

[@robertbeckman2054]

You are awesome. I worked in software for 18 years. Earlier in my career, I was productive, innovative, and created good products. As time went on, more and more Afile, Scrum, Jira, Kanban took over, and I became less and less productive as well as less and less interested in programming. Then came the burnout…complete and done.

[@seinfan9]

This whole thing about mandating a specific type of planning process has to be the dumbest idea ever adopted by corporations. Requirements are always changing due to budget constraints, deadlines, a bottleneck dependency, newly discovered information about a design path that presents a dealbreaking compromise... Projects need to be handled fluidly with a specific person or group of people that must call the shots for the bigger picture while the weeds of the details can be sorted out by the developers and designers in the trenches. You can't just plan on doing anything of substance given all the unknowns that can and will pop up.

[@NotOnlyCode]

Absolutely. Once I worked at a place where my whole department (300+ people) had to start and end the sprint on the same day. There was absolutely no room for any flexibility, and the only happy people were the SAFe consultants that introduced this process

[@seinfan9]

@@NotOnlyCode I work on the hardware design side of our products and they try to shoehorn this process onto us. Most of us don't even bother updating our stories because of how complex our dependencies are. Software has the advantage of releasing things even in buggy states as long as they don't break anything else. A mistake on our side is costly in terms of both time and materials, so we can't exactly "release" anything during our sprints. They essentially just use this whole thing as a product lifecycle tracker and hoping people will just micromanage themselves to have visibility on how far along we've gotten. A simple status meeting every week could accomplish this, but somehow they think the SAFe process is amazing and necessary for whatever reason.

[@dgmstuart]

⁠@@NotOnlyCodeOMG SAFe is the least agile thing that has ever existed. It’s a monstrosity. So gross

[@seinfan9]

@@dgmstuart "Here's tons of work that got piled on after our fake planning sessions. By the way, we are going to have you do all sort of microdocumentation to track your progress and we are going to hold regular meetings about how you aren't getting anything done as fast as we'd like."

[@marcblum5348]

In the business for 30 years. The agile / SCRUM by th book settings I were in, were the most inefficient imaginable. On the other hand the most successful (always a melange of efficiency and effectiveness) and quickly moving settings had the spirit of agile at their core but out of experience, not ideology.

[@liamhotspur9182]

I avoided that Scrum thing and I outlived it. What I hear here 12 minutes in is micro mgmt. Nothing is worst in every sense than micro management with micro managers... We started pair programming back then which was efficient if you have the right partner, so small teams with people who know and respect each other. There are also a lot of pros on waterfall methodologies but the two most important ones are: think it through as far as you can in the beginning and a good option for competitive biddings for contractors.

[@danejohannescaldwell7999]

In my experience, a customized Kanban approach worked marvelously for the team I was on. Too bad management wanted a standardized system for their own ease of tracking progress, so we were forced to adopt the much less productive Scrum, with all its less-than-ideal ceremonies.

[@JeanPierreWhite]

Kanban is a great practice when implemented by a mature team. Shame your organization imposed a practice on your team.

[@AndresGalavisBorden]

Well, I'm a program manager that does not employ Scrum or AGILE and I face a problem of always shooting at a moving target. Priorities change and it feels like you are always putting off fires. There is certain calm in taking a step back and planning the work for the upcoming week or two and having the ability to commit resources to important things that would not be worked on because of "urgent" things that arise. The idea of sharing your progress on a daily basis is also good as it helps you prevent people from getting stuck and correct course. So as long as you think about the purpose of the tools and techniques presented by these methods and do not follow them blindly, I think that these are great ideas. Also, depending on your market, companies need a release cycle that can be the used by other areas in their planning and execution. True that now continuous integration and deployment are available, but they are not silver bullets either. I agree that flexibility is key, when paired with using the right tools for the right reason.

[@jakubrogacz6829]

No, problem isn't in method. Problem is that it isn't used as method but as a tool to measure performances or budget the payments.

[@chriscarter2101]

I was a product developer for a major US manufacturer. We introduced Agile-Scrum about six years ago for a chemical-engineering product development project. Yes, several patents were filed in quick fashion, but I saw no product at the end of the project. It seems the methodology is designed for those with established tools; however product developers are actually developing such tools as they move forward: the very known-unknowns and unknown-knowns that Agile-scrum just isn't designed for.

[@fareedezzedeen8017]

I hate how peoble misuse Agile, Agile will not work unless you have a good coverage of the whole requirements, and a well designed system Archeticture and guidelines from the beginning, You should minimize important requirments discovery and technical decisions while on the go.

[@jacoberinc]

This exactly. Agile has become an excuse to not spend the time you should on proper requirements gathering, planning, and architecting. Agile doesn't have to result in ugly software and unnecessary stress on dev's do to large scale architectural changes halfway through the project because a crap job was done of the planning steps at the start of the project.

[@recmtnbiker4368]

Up-front architectural design is very important in safety-critical systems. On air data inertial reference units, there is partitioning in time and memory space. These partitions both produce and consume data used by other partitions. The lists of producers and consumers of data are in xml files. This is done to protect the most important data producers in the system. For example, the sensor monitors like the gyro life monitor is a "nice to have" partition that is used for preemptive maintenance to replace a part before it fails. The inertial reference partition that produces the pitch, roll, and yaw angle of an airplane produces data that is safety critical. By using this partitioning, if the sensor monitor gets stuck in a while loop, it won't prevent the inertial reference partition from producing its data. The air data component that produces altitude and airspeed is on a separate circuit card, with a different processor and different compiler to eliminate any potential common mode failure source. On medical devices I have worked on there are similar architectural decisions that have to be made up front. Usually there is a "front end" GUI and a "back end" embedded component. The back end is safety-critical and tested to a much higher standard and it is understood that since the front end isn't tested to the same standard, the back end validates any messages received from the front end for safety. Up-front architectural decisions like these don't fit nicely into these infantile little sprints and daily scrum meetings.

[@ModernTenshi04]

Scrum: Don't think of card points as units of time, think of them as units of effort! Also Scrum: How many of these effort points can you get done in the next two weeks?

[@QDSGames]

As so often the main problem is the implementation. The framework itself has fewer problems, it's rather a set of ideas and mindsets. Scrum is one of many agile development models but are used synonymously which is bad. Regarding Jira: If I would have to change my job I would ask whether Jira is used first. If yes, I'd immediately look for another job.

[@martynhodge6164]

I am a certified Scrum Master and I ..... agree. I was an engineer and took the role because I'd seen first hand how badly it could be done. Not saying I have it figured out but things seem to be going in the right direction.

[@philCTO]

Well said. I am one of founders of Investiocity . We have been looking for funding to expand to more cities and surprisingly, some people we have talked to want to know if we follow scrum and it has turned them off that we don't. Don't care. Scrum is not for developers, its for management and no one will convince me different. I spent a lot of time in the last 20 years in large multi-billion dollar companies that ran scrum to a tee. Including quarterly 4 hour meetings to review the manifesto. Hour long stand-ups were not uncommon. It was common to have regular meetings and sprint reviews of 30-50 people. Absolutely ridiculous. So when a potential investor asks me if we do scrum now I just answer that we do what the developers need on any given day to get things done. We push out code when we feel we have something cool to push and we don't let anyone who doesn't code get in any meeting, status update or email chain when the discussion is about code or estimated deliverables. Everyone is happy and our code quality is great.

[@secretchefcollective444]

This will more than likely be the model after another 20 years of pain - the way I see it, 20 years for Agile to become the 'thing' that normie companies have to adopt, this is where we are now, then the 20 years of experience (well, of pain that those of us who were early adopters have experienced) for the realization that it doesn't work quite right. You're way ahead of the curve.

[@ericpmoss]

OMG I am so happy to hear such a place exists - I didn’t know if any company had resisted the curse. In addition to all its technical faults, Agile(tm) is a most impersonal process for all its claims of enlightenment. Software leaders should have instead read Philip DeMarco’s “Peopleware”. It addresses all the things we need as people who find fulfillment in creating beautiful code.

[@evilDMguy]

I'm sorry you didn't have a good agile experience. I did and the agile team I was one taught me the most about programming, efficiency, and making managers happy. Just as my anecdotal experience won't convince you, or anyone, that agile can work, your anecdotal experience didn't convince me to throw out agile. I am sympathetic to the fact that wherever you have worked, you have had the worst parts of agile.

[@TimothyNyota]

Read your comment again

[@m12652]

I’m an old developer and I have to say this as I’ve seen it in pretty much every large organisation I worked. Some methodologies, Agile, Scrum, Lean etc. are better than others however none of them can compensate for bad management. If you’re thinking about changing management methodology you should first ask if you need new managers. If you don’t you’ll lose a lot of money.

[@deepti0905]

Thanks for sharing this video. I am so happy that there is someone resonates with my view. To be frank Agile seems more like a cargo cult

[@brandonpearman9218]

I think agile is pretty good, but scrum is a shit show. I think most companies which say they are agile are not, giving agile a bad name. Companies think because they do sprints and standups they are agile, which is wrong.

[@jacoberinc]

​@@brandonpearman9218 There is "Agile", and "agile". "Agile" is a business, cult, and religion. "agile" is just a set of values that should facilitate agility in project development. The problem is Agilists often use agile as a shield so they can always claim "you aren't doing real agile". Now if you will just hire one of our "Agile' certified coaches then they will make your company truly agile and you will finally see the 3x productivity boost.

[@brandonpearman9218]

@@jacoberinc Yeah, agreed. The problem is agile is taken over by non devs, its a scam business now.

[@michaelionita]

Agree with you. That’s why I like leading tech departments in startups. There I can shape it the proper way so it is as productive as possible. Good video.