loading...

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

radiomorillo profile image Stephanie Morillo Updated on ・1 min read

Hi all,

As someone who works in an organization that has adopted "Scrum-like" practices but is still waterfall, what is it like working on an Agile (especially Scrum) team? What has your experience been? What works well and what hasn't worked well?

I can't help but wonder if becoming a Scrum organization will help us innovate quicker, especially by having a self-organized and cross-functional development team.

Do you have insights? Share your thoughts in the comments!

UPDATE The Stack Overflow blog published a blog post in response to a question they saw in their forums: "Does scrum ruin great engineers or are you doing it wrong?" Curious if anyone has thoughts about this!

Discussion

markdown guide
 

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.

 

I appreciate the response, thank you!

 

Scrum has helped us keep distractions at bay because the ceremonies have specific agendas. That is a huge benefit that enables innovation. The teams start to feel comfortable with the consistency and can better plan or execute, which is where Scrum really shines IMO.

Our development and design teams use scrum but they don't both use agile. The design team follows an agile approach to projects, they iterate over a design strategy until it reaches a comfortable MVP state with the stakeholder. Following that, they work to get it out there to the website and enhancements after that are data driven changes. Our development team is given full requirements about 95% of the time, which is waterfall.

Projects for us include global theme experiences, page redesigns/experiences, or at the smallest size, component experiences. If you have designers that produce explicit designs, then it's difficult to have your developers follow agile with regards to their coding. They may be able to follow agile in terms of engagement with other teams though. (e.g individuals over process)

Overall, I like both scrum and waterfall, but scrum is awesome at what is designed for which is to empower individuals and teams for getting things done.

 

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.

 

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.

 

Great insight, thanks Ricardo!

 

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

 

Thanks Alexandre! Definitely interesting to get your perspective. (Also glad to see your consultancy employs Scrum.org professionals; I recently passed the PSM-I assessment. :) )

In your post, you mentioned the following:

Having said that, we do have clients (most of them), even non-IT ones (where IT is not their core business) that we are successful on applying agile methodology.

What are some characteristics these clients share? In other words, what are some qualities that companies who successfully apply Agile have? I know this is as much as a mental shift as it is a process/systems one.

 

I can surely state: open mindset. The client company, as a whole, must be open to change the way they work, the way they think about their business.

These companies understand that the market is not stable anymore and that they need to be fast and flexible enough to be able to keep afloat, to inovate.

Of course, some clients are resistant to change things internally. Our job is to try to make them see the benefits. Unfortunately, we're not always successful.

This is very insightful; thank you so much again for your response. 🙏🏽