A study was done by a consulting firm,
which found that software engineering projects that were developed using agile
methodologies had a 268 percent higher failure rate than those that do not. Now this study is probably biased. They surveyed 600 software
engineers from the UK and the US. And it does seem like businesses
love Agile but software engineers, the actual workforce that has to
implement Agile, software engineers hate what Agile has become. Agile is a development methodology
that focuses on two main areas. The idea of doing projects in small
continuous cycles rather than one big cycle and it needs to follow the Agile
manifesto, which can be seen here. And look, if you actually
read the manifesto and the definition of Agile, it's good. That's not the problem. The problem is that businesses have come
in and they have followed the principles blindly without any project context
and have basically destroyed agile. Nowadays, Agile is practiced like this. Devs get a list of tasks that
they need to complete within two weeks, also known as a sprint. Objective one is to get the product out
to the customer as quick as possible. And objective two is to communicate
continuously and consistently. And I think that is problem number one. an Agile environment, if you are
following Scrum, which is a framework of Agile, you have a few meetings. You'll have a sprint planning meeting,
which happens before your two week sprint. Then you have daily standups
or scrums every day. then after the two weeks
sprint is complete, you have a sprint review to discuss the
completed items that you've done. You also have a sprint retrospective. This is where you reflect
on the past two weeks. you have something called
backlog grooming, which is where you review the backlog. And there's a whole bunch
of other meetings too. You have presentations, demos, one
on one meetings, company meetings. There is a lot of communication. And are all of these meetings actually
mentioned in the initial manifesto? No. In fact, this is the only
thing the manifesto mentions. At regular intervals, the team reflects on
how to become more effective, then tunes and adjusts its behavior accordingly. This was on the subreddit ExperienceDevs. Since switching to Scrum, my entire
days are nothing but meetings. This is my fifth company I have done Scrum
with, so I'm pretty familiar with it. However, since switching to
Scrum, the entire department has experienced one huge problem. All we do is go to meetings. Our daily standups are 15 minutes, which
is great, but then we have grooming for 1. 5 hours, sprint planning for 1. 5 hours, long retros. Demos, process meetings, values
meetings, side discussions, meetings, peer meetings, one on one department
meetings, and all company meetings. For reference, prior to Scrum, I
had three hours of meetings a week. Now I average 13 hours of meetings a week. again, I don't think Agile here
is the problem, but how companies actually interpret Agile. And interestingly in this thread, a
lot of developers have agreed and said, yes, they have worked in an environment
that has done the exact same thing. This person responded, Just left a
job that was like that.Safe Agile e. That's another framework. What a effing farce. Literally 60 percent of sprints
are spent in pointless ceremonies. Great username there as well. but often one of the major complaints
with Agile is there are too many meetings. Like with this post, it says, Team
rebels against too many meetings. What can I do? Someone responded, Too many meetings
usually means too many meetings. It means that meetings aren't effective. Figure out why they don't think meetings
are effective, I agree, if meetings aren't effective or nobody's learning anything
new from it, why bother having it. and the issue here is that often
developers will bring this up. This is a conversation that I've
been part of a lot of times. They will bring up the issues of
having too many meetings to the scrum master or project manager. And often the scrum master or the project
manager will shut it down and say, sorry, that's agile, that's the framework. Which leads me to my
next point of discussion. So this Reddit thread is titled,
since switching to scrum, my entire days are nothing but meetings. And someone asked OP, what would
happen if you decline the meetings? If you aren't getting or
contributing value, just don't go. And the response from OP was
the following, I actually brought this up in the retro. the people on the team were
very supportive of the idea. However, the engineering manager,
they attend all our meetings. And the scrum master were
very much against the idea. So needless to say, I haven't
seen anyone decline a meeting. And yes, you can be vocal about
it and decline your meetings. Project managers just
don't seem to listen. The project managers or Scrum Masters of
Agile, that role is so interesting to me. And please let me know your opinion
on what I'm about to say, because I've always thought this, but I was
so scared of voicing it because I obviously don't want to hurt the
project managers or scrum masters. But the way that role is set up,
It feels like they're planted by leadership to be spies. I feel crazy for saying that. And I obviously don't think
that, but it feels like that. It just feels like they are imposters. Just the way that they interact
and the role that they need to do. It just feels like they
are never part of the team. Like they're just meant to go
and tattletale to the bosses. The other thing as well is that
a lot of them aren't actually developers with experience. So it is hard for you to get actual
help from them when it comes to creating tasks, chatting about
deadlines, because it almost feels like they don't know what's going on. and all they do is care
about updating their JIRA. And don't get me wrong. I've known some amazing project managers,
but most of the time, the amazing project managers are often really experienced
developers, which is another issue, right? Because the pool of experienced
developers are small. And then the pool of experienced
developers who actually want and enjoy project management is even smaller. This Medium article titled Good Scrum
Master, Bad Scrum Master puts it nicely. And the person who wrote it
is actually an Agile coach. Good Scrum Masters care for people,
Bad Scrum Masters focus on numbers. He goes on to say, they try to get the
team to estimate and plan everything as detailed as possible to create
accuracy and optimize velocity. But this approach doesn't pay off because
in the end you have an optimized feature factory and an unhappy zombie scrum
team with stressed out team members. this was a popular thread on Reddit where
a lot of developers actually expressed their frustrations with project managers. anyone else getting taken over by
project managers and feel all is lost. The poster says that their company
has hired a new project manager and they go on to say this. This person came from a company
of 340, 000 employees to our little company of 800 employees. Spent a few weeks reconfiguring
Jira and basically put a microscope on all the development teams. She and her direct report, the Scrum
Master, are both old school enterprise IT PMs that went out and got a Scrum
slash Agile certs to stay relevant in the job market and seem to have no trust or
respect for software development, possibly because they really don't understand it. And the responses below were pretty sad. They were concerning. One developer said, I've been
through these types of reorgs twice. You have no say whatsoever. You either get in line and play
the game or get another job. fighting this will brand you as hard
to work with and they will out you. Harsh reality, but the
straightforward truth. And the response to that was, Second
that, I am 100 percent on same situation as OP and I believe scrum masters are
the herpes of software engineering. I try to keep this channel PG
because I'm a small channel and I'm trying to grow and I think the
algorithm doesn't like adult things. But some posts on Reddit
are just too good to censor. So, in the same thread, another dev responded. I am in a similar situation. In my 10 years of experience, I
never felt like I was burning out. But with this new management
style, I am being harassed every day to finish my tasks quicker. And I feel burnt out. My life feels like it
revolves around sprints. and the life restarts every
first day of the sprint. And there were so many responses of people
saying, I'm in the same boat as you. So what do we as software engineers do? I don't really have a
way forward with this. I can't say if your company is using
Agile and it doesn't work, speak up. Because the job market is terrible. So if you do something like that,
or if you push back, often you're branded as a developer who is
hard to work with and not Agile. Cool. And not fitting the core
principle values of the company. And when it comes to layoffs,
you're first on the list. and is that fight really
worth fighting for? and sure, I'm sure there are other
frameworks that work better, but Agile done right is fine most of the time. this post is titled
Client Runs on Waterfall. Waterfall is another project
management framework where each phase must be complete before
the next phase actually starts. With little to no overlap or
iteration and your phases are generally much larger than Agile. Waterfall is older and it does
have some issues, but this div is actually loving it. They say, I'm secretly loving it. This is the first contract where
I'm not rushing around every sprint, trying to piece together half baked
features and pushing them out the door. Everything is regularly
tested and documented. Nothing gets released until
all requirements are met. No sprints. We celebrate every release. Client gives feedback. Someone responded with
such a good one liner. They said, Waterfall done well
is better than Agile done poorly. and the entire issue is that
Agile is done poorly a lot. Not that Agile is a bad methodology. someone also said, you're just describing
how an Agile process is meant to be. True Waterfall is designing
the system up front. Agile is doing it feature by
feature and having small releases. Scrum gets a lot of hype, but
sprints and other scrum peculiarities are not what Agile is about, So is a time to move on from
agile, new Agile, definitely. If someone could come up
and market an Agile 2. 0 that actually puts the developers
and the development process first and not the company or the customers,
that might be a way better option. thank you so much for watching. If you like my content,
please like, and subscribe. I'll see you on the next one. Bye.
