Have you ever, or do you currently, work on an Agile team?

In my experience, not many companies go fully "true" Agile but instead adapt some of the ceremonies and processes to their own needs. Before commiting to Agile, I'd take some time and look at how your company works and why you think you might need Agile.

In broad terms, management tend to like agile because they get lots more insight into the teams progress with both daily standups and the backlog/sprint user stories. Developers have mixed opinions in my experience, with the daily standup becomming a chore if done incorrectly or the stories being over/under developed, not broken down enough etc.

Other ceremonies can help but again it depends on your company. Adding in sprint retrospectives have always seen a net positive in my experience. Taking the time to discuss what went wrong and what went right (and tracking it for next time!) is a great way of incrementally improving everyones experience.

I've also seen demo sessions (or "show and tell") work well too, but this can highly depend on the personalities of your developers. Some love being noticed and appreciated for their work while others hate the attention and want to be left alone! :)

Switching to cross-functional teams can be very useful as well, although there is usually some confusion at first as people settle into the new team, especially with regards to who/when they should communicate with. But communication is generally improved and with that, increased efficiency.

From a personal point of view, I've worked in both waterfall and agile and always prefer the agile approach for it's increased visibility into work, faster communication and quicker turnaround and iteration of work.

For what I've seen in the field (and I'll be clear that my only experience so far is with software development and software management) not all companies go FULL SCRUM, or something like that, specially if currently all areas of the company are on the waterfall method.

What actually happens is that the enterprises rather have a foot on the terrain they already know (waterfall) than dive in head-first in something they are not even sure if works. What I've experienced so far is something like a "We're trying to implement Scrum, and we tell people that we use Scrum, but actually we still do a lot of things in the old fashioned way". And that is not something terrible.

What I can tell you is that agile is a great way to work and I absolutely love it! By no means I'd tell my squad to go back to waterfall. However, some people on the same company, but in a different area - for example finances - may disagree with me.

I think that what I'm trying to say is that sometimes we have a distorted vision on Scrum and other Agile concepts. The Agile may not be the fuel that will make your organization grow. But it may be. Agile is not the only option! (But I love it with all my heart).

What I think is really important is taking a time to understand if your organization will really benefit on using this practice, in the end, even waterfall may work on your team, if they really like and dive into it.

In my last job, I worked on an agile (scrum) team. I think my first internship/job was one too but I didn't realize it at the time. I know in my last job though, it was called a scrum meeting. And I thought for our team it was really useful because we were all on the same page as everyone else. I really enjoy the agile environment so far. Although I agree with another user that most company go fully "true" agile. I do agree that there is a lot of mix depending on how old or young the company is and how flexible the team members are.

I'll echo what others have said. Done right, Scrum can be a positive experience. Done poorly (like anything) it's a nightmare.

My very first exposure to Agile was attending a retro at a shop that did it poorly. It was a toxic environment to begin with. A wall was covered with post-its, most complaining about people and process, none constructive or professional. I learned people dictated their comments to a friend or partner or wrote with their off hand so the handwriting wasn't identifiable (with the exception of two resignation notices). That's not how to do it.

Since then I learned to appreciate the retro. It's an opportunity to constructively reflect, speak up and improve process. Some teams/individuals have difficulty with the idea, even feeling attacked. Having a capable Scrum leader helps soothe and moderate the conversation. A Scrum leader is more than a project manager or lead and I recommend finding someone with the training and temperament needed to manage the work and personalities. That person can make or break your Scrum!

To your question on cross-functionality, I'm a database engineer and not a developer and embedded with many cross-functional teams over the years. In a waterfall or traditional system I'm an SME, isolated from the day-to-day. My interactions are at a high level or responding to direct questions and my exposure is limited. In Scrum, I'm aware of everything going on and what's coming down the line. Scrum gives Ops/SME folks more view and voice in a product, project or application. That affords greater ability to intercept poor design and code decisions early, when there's still flexibility, vs. trying to accommodate bad code.

I've worked Scrum on Ops/DevOps teams, too, and while the implementation is usually different (longer sprints, 1x or 2x weekly vs. daily stand-ups, more Kanban style) I prefer it to waterfall. More awareness, more visibility, better measurement and reporting. My tech career goes back to 1989 and the (properly done) Scrum/Agile teams/environments were consistently more productive, performed better, got along better, and more enjoyable.

Hi Stephanie, I shared a little of my experience and thoughts here, on another post: dev.to/ale_jacques/comment/115o0