It’s time to move on from Agile Software Development (It's not working)

Summary

The video discusses a study indicating higher failure rates in software projects using Agile methodologies compared to non-Agile ones, highlighting potential biases and widespread dissatisfaction among developers. It criticizes the excessive meetings and misinterpretations of Agile principles by businesses. Developers express frustrations with Scrum practices, feeling overwhelmed by meetings and misunderstood by project managers. The video suggests that while Agile is not inherently flawed, poor implementation is common. It concludes with a call for a revised Agile approach that prioritizes developers and the development process.

Takeaways

• 📊 A study suggests that Agile projects have a 268% higher failure rate compared to non-Agile projects, indicating potential issues with Agile methodologies in practice.
• 🔍 The study may be biased, as it surveyed only 600 software engineers from the UK and the US, limiting its generalizability.
• 🏢 Businesses often favor Agile, but the actual software engineers implementing Agile may dislike its current state, highlighting a disconnect between management and developers.
• 🔄 Agile focuses on small, continuous project cycles and adherence to the Agile manifesto, which is generally well-regarded, but its implementation is often misaligned with its principles.
• 📈 The primary objectives of Agile are to quickly deliver products to customers and maintain continuous communication, but the execution often falls short.
• 🗓️ Agile, particularly Scrum, involves numerous meetings such as sprint planning, daily standups, sprint reviews, and retrospectives, which can be overwhelming and time-consuming.
• 📚 The Agile manifesto emphasizes regular reflection and adjustment for team effectiveness, but many companies overlook this in favor of rigid meeting structures.
• 💬 Developers often complain about excessive meetings under Agile, feeling that they detract from actual development work and contribute to burnout.
• 👥 The role of Scrum Masters and project managers in Agile can be contentious, with some developers perceiving them as disconnected from the development process and overly focused on process rather than people.
• 🚫 Developers may feel powerless to change the Agile process due to fear of being labeled as difficult or non-collaborative, which can impact their job security.
• 🌊 Some developers express a preference for traditional Waterfall methodologies, finding them less stressful and more structured compared to poorly executed Agile practices.

Q & A

What was the main finding of the study conducted by the consulting firm regarding Agile methodologies?

The study found that software engineering projects developed using Agile methodologies had a 268 percent higher failure rate compared to those that did not use Agile.

What are the two main areas of focus in Agile development methodology?

Agile development methodology focuses on doing projects in small, continuous cycles rather than one big cycle, and following the Agile manifesto.

What is the perceived problem with how businesses implement Agile according to the video?

Businesses follow Agile principles blindly without considering the project context, leading to a misinterpretation and ineffective implementation of Agile.

What are the common meetings involved in a Scrum framework?

The common meetings in a Scrum framework include sprint planning meetings, daily standups or scrums, sprint reviews, sprint retrospectives, backlog grooming, presentations, demos, one-on-one meetings, and company meetings.

What is one major complaint from developers about Agile, as discussed in the video?

One major complaint from developers is that there are too many meetings, which consume a significant portion of their time and are often ineffective.

How did the engineering manager and scrum master respond to the idea of declining meetings?

The engineering manager and scrum master were against the idea of declining meetings, leading to a situation where no one felt comfortable skipping meetings.

Why does the speaker feel that project managers or scrum masters might seem like 'spies'?

The speaker feels that project managers or scrum masters might seem like 'spies' because they are often seen as not part of the team, mainly interacting to monitor and report back to leadership rather than contributing to development.

What is the perceived issue with many project managers or scrum masters in Agile environments?

Many project managers or scrum masters lack actual development experience, making it difficult for them to provide meaningful assistance or understand the development process, and they often focus more on updating tools like JIRA.

What is the difference between 'Good Scrum Masters' and 'Bad Scrum Masters' as described in the video?

Good Scrum Masters care for people and focus on the well-being of the team, while Bad Scrum Masters focus on numbers, detailed planning, and optimizing velocity, often leading to an unhappy and stressed-out team.

What was a developer's experience with a new project manager who reconfigured JIRA in a small company?

The new project manager reconfigured JIRA and micromanaged the development teams, leading to a lack of trust and respect for the software development process and contributing to a negative work environment.

What is the general sentiment of developers towards Agile and Scrum based on the Reddit responses shared in the video?

The general sentiment of developers towards Agile and Scrum is negative, with many expressing frustrations over excessive meetings, lack of effective communication, and feeling burnt out due to poor implementation of Agile principles.

What is the contrasting opinion on Waterfall methodology mentioned in the video?

Some developers prefer Waterfall methodology because it involves thorough testing and documentation, no rushing to meet sprint deadlines, and a more structured approach, contrasting with poorly implemented Agile practices.

What conclusion does the speaker suggest regarding the future of Agile methodologies?

The speaker suggests that it might be time to move on from current Agile practices and develop a new version, 'Agile 2.0,' which prioritizes the developers and the development process over the company or customer interests.

Outlines

00:00

📈 Agile Methodology's High Failure Rate

This paragraph discusses a study revealing that software projects using Agile methodologies have a significantly higher failure rate compared to traditional approaches. The study, which surveyed 600 software engineers from the UK and the US, suggests a disconnect between businesses' love for Agile and the actual workforce's dissatisfaction. Agile is described as a development methodology focusing on small continuous cycles and adherence to the Agile manifesto. However, the real issue is the misinterpretation and over-application of Agile principles by businesses, leading to a heavy focus on meetings and ceremonies rather than actual development work. The paragraph also highlights the frustration among developers due to excessive meetings, which are not part of the original Agile manifesto but have become a norm in many Agile implementations.

05:01

🤔 The Role of Project Managers and Scrum Masters in Agile

This paragraph delves into the perception and role of project managers and Scrum Masters in Agile environments. It explores the idea that these roles might feel like 'spies' for leadership, often not being part of the development team and focusing more on reporting than on contributing to the team's success. The paragraph also touches on the lack of developer experience among some project managers, which can hinder their ability to effectively support the team. The discussion references a Medium article that contrasts good and bad Scrum Masters, emphasizing that good Scrum Masters care for people, while bad ones focus on numbers and process optimization. The paragraph concludes with anecdotes from developers expressing frustration with project managers who micromanage and enforce a strict adherence to Agile processes without understanding the development process itself.

10:03

💧 The Appeal of Waterfall in Contrast to Agile

In this paragraph, the speaker contrasts the Agile methodology with the Waterfall approach, highlighting the benefits some developers find in the latter. Waterfall is described as a more structured and less iterative process, where each phase must be completed before the next begins. The speaker mentions a developer's preference for Waterfall due to its predictability and the absence of the pressure associated with Agile's sprints. The paragraph also includes comments from developers who appreciate the regular testing and documentation in Waterfall, as opposed to the rushed and often incomplete feature releases in Agile. The discussion suggests that Agile, when done poorly, can be less effective than Waterfall, and there is a call for a new approach that prioritizes developers and the development process.

Keywords

💡Agile Methodologies

Agile methodologies refer to a set of principles and practices that guide software development projects to be more flexible and adaptive. In the video, it is mentioned that projects using Agile methodologies had a significantly higher failure rate compared to those that did not. This highlights a potential issue with how Agile is implemented in practice.

💡Agile Manifesto

The Agile Manifesto is a set of principles that underpin the Agile development approach, emphasizing values such as customer collaboration and responding to change. The video discusses that the manifesto itself is good, but the problem arises when businesses blindly follow its principles without considering the project context, leading to misinterpretations and misuse of Agile.

💡Sprint

A sprint is a time-boxed, short-term phase in Agile development where a set of tasks is completed. The video script mentions that developers receive a list of tasks to complete within a two-week sprint, emphasizing the pressure to deliver quickly, which can lead to issues if not managed properly.

💡Scrum

Scrum is a framework within Agile methodologies that structures the development process into sprints and includes regular meetings like daily standups and sprint reviews. The video criticizes how Scrum is often implemented, with excessive meetings that can detract from actual development work.

💡Meetings

The video script frequently mentions meetings as a significant issue in Agile environments, particularly in Scrum. Developers report that their days are filled with various meetings, which can hinder productivity and lead to frustration, as meetings are often seen as unproductive or unnecessary.

💡Project Managers

Project managers play a crucial role in overseeing Agile projects, but the video suggests that their approach can sometimes be problematic. Developers feel that project managers, especially those without a deep understanding of software development, can impose too much process and oversight, leading to a stifling of creativity and productivity.

💡Backlog Grooming

Backlog grooming is a process in Agile development where the project backlog is reviewed and refined. The video script describes this as one of the many meetings that developers must attend, contributing to the overall burden of excessive meetings.

💡Waterfall

Waterfall is a traditional project management framework where each phase of the project is completed before the next one begins. The video contrasts Agile with Waterfall, suggesting that some developers prefer the predictability and structure of Waterfall over the perceived chaos of poorly implemented Agile.

💡Burnout

Burnout is a state of chronic stress and exhaustion, often resulting from overwork. The video script includes developers expressing that the constant pressure of Agile sprints and meetings can lead to burnout, affecting their mental health and job satisfaction.

💡Agile 2.0

The concept of Agile 2.0 is mentioned in the video as a potential solution to the issues with current Agile practices. It suggests the need for a new approach that prioritizes the needs of developers and the development process, rather than just the company or customers.

💡Developers' Frustration

Developers' frustration is a recurring theme in the video, stemming from the mismanagement and overemphasis on process in Agile environments. The script includes numerous examples of developers feeling overwhelmed by meetings and the lack of respect for their work, leading to a desire for change.

Highlights

A study found that software engineering projects using agile methodologies had a 268 percent higher failure rate than those that do not.

The study surveyed 600 software engineers from the UK and the US, suggesting a potential bias.

Software engineers dislike Agile due to how businesses have implemented it, deviating from the original Agile manifesto.

Agile focuses on small continuous cycles and adherence to the Agile manifesto, which is generally good in theory.

Businesses have misinterpreted Agile principles, leading to its misuse and negative perception among developers.

In Agile environments, developers are given tasks to complete within two-week sprints, prioritizing quick product delivery and continuous communication.

Agile involves multiple meetings such as sprint planning, daily standups, sprint reviews, and retrospectives.

The Agile manifesto only mentions regular intervals for team reflection and behavior adjustment, not the numerous meetings practiced today.

Developers report that switching to Scrum has led to an increase in meetings, consuming most of their workdays.

Some developers feel that Agile meetings are ineffective and do not contribute to learning or productivity.

Developers often face resistance when they bring up concerns about excessive meetings with Scrum Masters or project managers.

The role of Scrum Masters and project managers is perceived by some as being more about monitoring and reporting to leadership rather than team support.

Many Scrum Masters and project managers lack the developer experience necessary to effectively support the team.

Good Scrum Masters are described as caring for people, while bad ones focus on numbers and optimizing velocity.

Developers express frustration with project managers who enforce excessive meetings and do not respect software development processes.

Some developers feel that challenging Agile practices can lead to being labeled as difficult and facing potential job loss.

Waterfall, an older project management framework, is seen by some as more effective when done well compared to poorly executed Agile.

There is a call for a new Agile framework, Agile 2.0, that prioritizes developers and the development process.

Transcripts

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.