Agile is the recognition that that in the modern world, especially in digital products, we learn new information faster than we can act on new information, and so we benefit from structures and "processes" that allow us to discover and act on information as quickly as possible. "Processes" is in quotes there because this usually translates to a _lack_ of process. Formalized process slows things down and agile wants to act fast. Agile prefers for us to live and communicate in the moment rather than through some structured form. This is also why agile tends to be a bottom-up organizational structure, giving the most agency to the people doing the work rather than managers and middlemen.
Scrum is weird, and very, _very_ misunderstood. Scrum, at its heart, is trying compensate for one of agile's "weaknesses"--or at least, what many organizations might view as a weakness: disempowered management. Most organizations aren't willing to adopt the agile values that allow them to move fast because it means higher ups have less direct control and visibility into what's going on. Scrum tries to compensate for this by introducing an agile-flavored framework that isn't really agile, but can provide organizations that won't adopt agile values with structure that can still give them a bit of what they want (namely visibility) while providing some of agile's benefits.
Scrum's Achilles Heel, however, is a tragic one: Organizations that aren't willing to adopt agile's values aren't likely to adopt Scrum's values either. So despite all the effort and "restructuring" organizations put into place to "do Scrum", they end up with the same values and processes they were already using, but now with a Scrum-like vocabulary. This is why Scrum gets a pretty bad reputation: At its best, it's not as good as agile, and at its worst, it's twisted into a mask for the processes that were the original problem. You're usually better off either doing straight agile or not bothering with either.
As for the pros and cons of the concepts and meetings, let's clear up what each of them is about:
Standup - Often used as a daily check in. This not the intended usage and doesn't do the team much good. A well-used standup is simply an opportunity for team members to expose any blockers they're encountering so that others might jump in and help if they're so able. If the team has good communication habits already, a daily stand up won't bring them much benefit. That said, it's also serves as an opportunity for shy team members, or those who don't want to bother people, to regularly get a chance at communicating their problems, so it can be practical depending on the team's personalities.
The Sprint - Most teams think of the sprint as a unit of time around which they should plan work. This is incorrect; in fast paced environment, there's no such thing as planning work reliably enough that you can assign just enough for the sprint's duration. There are too many unknown unknowns for that to work.
A sprint is the maximum amount of time the team goes between syncs about the priorities, current problems, and what works needs to be done. Sprints aren't about planning out work and getting to it, they're about making sure the team regularly aligns itself on the important things. To accomplish this, we usually have two meetings per sprint:
Grooming - A session in which the team comes together and reviews all the upcoming work, changes, etc. The goal is for everyone on the team to be familiar with what's being worked on, how the product should behave, and that product definitions/specs are clear enough for work to begin.
Retro - A session in which the team can explore organizational or other obstacles getting in the way of productivity, and then collaborate on solutions to these problems.
Checkmarks, point systems, velocity tracking--these do not contribute to productivity and are not worth incorporating into your team. Usually, the people that benefit from these are not the people who benefit from productivity, but the people who want to have "data" they can use to prove to _their_ manager that they're doing a good job (and deserve a raise/promotion).
There's a lot of depth to agile, and done properly it can be a huge boost to fast-moving teams. But it's also very easy to get lost and go down a bad road that satisfies no one. Agile is worth pursuing, but only if you have a good guide that can keep you on the right path, and the full buy in of the organization, so they don't pull out on you halfway through.
Credentials: I'm a certified level 1 Scrum master.
Agile is the recognition that that in the modern world, especially in digital products, we learn new information faster than we can act on new information, and so we benefit from structures and "processes" that allow us to discover and act on information as quickly as possible. "Processes" is in quotes there because this usually translates to a _lack_ of process. Formalized process slows things down and agile wants to act fast. Agile prefers for us to live and communicate in the moment rather than through some structured form. This is also why agile tends to be a bottom-up organizational structure, giving the most agency to the people doing the work rather than managers and middlemen.
Scrum is weird, and very, _very_ misunderstood. Scrum, at its heart, is trying compensate for one of agile's "weaknesses"--or at least, what many organizations might view as a weakness: disempowered management. Most organizations aren't willing to adopt the agile values that allow them to move fast because it means higher ups have less direct control and visibility into what's going on. Scrum tries to compensate for this by introducing an agile-flavored framework that isn't really agile, but can provide organizations that won't adopt agile values with structure that can still give them a bit of what they want (namely visibility) while providing some of agile's benefits.
Scrum's Achilles Heel, however, is a tragic one: Organizations that aren't willing to adopt agile's values aren't likely to adopt Scrum's values either. So despite all the effort and "restructuring" organizations put into place to "do Scrum", they end up with the same values and processes they were already using, but now with a Scrum-like vocabulary. This is why Scrum gets a pretty bad reputation: At its best, it's not as good as agile, and at its worst, it's twisted into a mask for the processes that were the original problem. You're usually better off either doing straight agile or not bothering with either.
As for the pros and cons of the concepts and meetings, let's clear up what each of them is about:
Standup - Often used as a daily check in. This not the intended usage and doesn't do the team much good. A well-used standup is simply an opportunity for team members to expose any blockers they're encountering so that others might jump in and help if they're so able. If the team has good communication habits already, a daily stand up won't bring them much benefit. That said, it's also serves as an opportunity for shy team members, or those who don't want to bother people, to regularly get a chance at communicating their problems, so it can be practical depending on the team's personalities.
The Sprint - Most teams think of the sprint as a unit of time around which they should plan work. This is incorrect; in fast paced environment, there's no such thing as planning work reliably enough that you can assign just enough for the sprint's duration. There are too many unknown unknowns for that to work.
A sprint is the maximum amount of time the team goes between syncs about the priorities, current problems, and what works needs to be done. Sprints aren't about planning out work and getting to it, they're about making sure the team regularly aligns itself on the important things. To accomplish this, we usually have two meetings per sprint:
Grooming - A session in which the team comes together and reviews all the upcoming work, changes, etc. The goal is for everyone on the team to be familiar with what's being worked on, how the product should behave, and that product definitions/specs are clear enough for work to begin.
Retro - A session in which the team can explore organizational or other obstacles getting in the way of productivity, and then collaborate on solutions to these problems.
Checkmarks, point systems, velocity tracking--these do not contribute to productivity and are not worth incorporating into your team. Usually, the people that benefit from these are not the people who benefit from productivity, but the people who want to have "data" they can use to prove to _their_ manager that they're doing a good job (and deserve a raise/promotion).
There's a lot of depth to agile, and done properly it can be a huge boost to fast-moving teams. But it's also very easy to get lost and go down a bad road that satisfies no one. Agile is worth pursuing, but only if you have a good guide that can keep you on the right path, and the full buy in of the organization, so they don't pull out on you halfway through.
Credentials: I'm a certified level 1 Scrum master.