DEV Community

Cover image for Agile and Scrum: What Are Your Thoughts?
Ben Halpern Subscriber for CodeNewbie

Posted on

Agile and Scrum: What Are Your Thoughts?

How well acquainted are you with these methodologies? Have you ever been part of a team that followed these approaches? Share your experiences, insights, and questions. How effective are they, in your opinion, in driving successful projects?

Share your thoughts in the comments!

Follow the CodeNewbie Org and #codenewbie for more discussions and online camaraderie!

Top comments (11)

Collapse
 
lexlohr profile image
Alex Lohr

Unfortunately, rulesets for development processes are riddled with marketing BS. There are a few takeaways, though.

  • estimations have zero value for developers, and their value for management is mostly exaggerated
  • transparency costs time, but also saves time – try to at least break even
  • every development process is a compromise; don't be afraid of implementing changes and revert them if they don't work
  • deadlines are always arbitrary; challenge them for good reasons if you must
  • own your process like you own your code; if management intervenes, defend it against unreasonable changes
  • management should only ever set goals, deciding on measures is work for engineers
  • reasonable limits can help to increase overall velocity – start with low limits and increase if necessary
Collapse
 
jmfayard profile image
Jean-Michel 🕵🏻‍♂️ Fayard • Edited

The confusing thing to understand is that there are two radically different things called agile.

There are the Enterprise ready serious detailed all encompassing one size fits all Agile TM frameworks sold by Agile consultants like Scrum and SAFE

And then there is agility as a compass where each team constantly redefines its rules for its own specific context, taking inspiration from the general principles from the agile manifesto


Also agile is now usually a synonym of agile project management, while initially it was 50/50 between that and agile software development.

Knowledge from XP etc is not exactly widespread nowadays

Collapse
 
cjlebel profile image
Carl J

The two Agiles you shall of, are one and the same (well, excluding the "one size fits all part").

The whole point of agile, is to be, agile. It's meant to change to fit the teams' needs, as no two teams are the same.

The first one you mentioned is to get you started, but I'm willing to bet that an Agile coach worth at list half his pay, will not come in and tell the team that this is exactly how things should be done.

Collapse
 
jmfayard profile image
Jean-Michel 🕵🏻‍♂️ Fayard • Edited

We probably have a different work experience.

A tale of two teams

  • Team A: What are you talking about this? During the standup we need to ask the three questions, what have you done yersterday, what are you doing today and what is blocking you? That's Scrum's best practice, so please keep that offline, let's get back on track. (The people were not at all beginner at agile, and the standup was not working well).
  • Team B: I don't feel like the standup is focused on something meaningful. We talk but don't seem to make progress. Also everyone seems to be busy preparing to talk about what the heck he's gonna say instead of listening: Any idea on how to improve that? Yes me, in a previous experience we decided to do a screen sharing of the Jira board and that allows us to have a regular picture of how the project is working. Other: ok, let's try it for two weeks, shall we?

And that's the best case scenario of an Agile(tm) vs agility divide.

Worst case scenario is Agile Consultants selling very expensive SAFe all-encompassing solutions with plenty of nice-looking slides to make sure that every team in the company is working the same way.

Collapse
 
bbkr profile image
Paweł bbkr Pabian • Edited

Scrum never worked for me.

  • Sprints. This concept is good for decomposable, easy to estimate tasks, without external dependencies. I do a lot of R&D, a lot of Proof-of-Concepts, entangled projects, often must wait for other teams. My work almost never aligns with sprint window well.
  • Dailies. I work in backend team and we have individuals specialized in certain areas of the system. That makes daily meeting boring AF as we do not share common goal.
  • Planning. I can deal with next sprint planning, but quarter plannings with estimates and guesstimates are pure waste of time due to imprecision.
  • Backlog is weird concept. Common mistake I've seen countless times is too early estimation of tasks from it, making some illusion that schedule is under control. It is not. When task finally hits the sprint noone remembers details and it must be estimated again (including environment changes made meantime).
  • Backlog is junky by nature. This should have some TTL - if something was not done within 1/2year it was apparently not needed.
  • Process is too heavy. There are too many meetings and bureaucracy.

I can imagine teams and projects where Scrum may be implemented successfully. I'm not in one of these. Scrum is getting in my way, decreasing productivity significantly.

Collapse
 
bradtaniguchi profile image
Brad

Buzzwords that give names to processes that are more about the process itself than actually creating end-user value.

Are you agile if you have priorities determined weeks or even months in advanced? You are just waterfall, but under time crunch. Day to day your entire job will be the opposite of agile, balancing un-planned work against the planned "agile" work. And this is if you are lucky, and can respond to unexpected bugs day-today. You might actually be agile if you have basically no un-planned work, everything is planned in the near future and execution occurs within the expected timeframe. I doubt anyone is actually doing that, even if everyone says they are "agile".

SCRUM has similar pitfalls, except provides even more processes and structure that may or may not actually help anything. Take for example the daily standup, if your team doesn't have internal inter-dependencies, it usually devolves into a team-wide status update that means nothing to most people on the team. Sprinkle this aspect into all of the rituals, and you suddenly have a large portion of everyone's time being wasted on unnecessary syncs.

In both, the issue isn't so much the concept, but rather the process's structure being designed for broad strokes of teams and broad strokes of work. Today there is also a large amount of "async" and unplanned work being performed that isn't taken into account. Modern tech stacks are more easily broken up, and suddenly a majority of work isn't "internal team dependent", rather it requires external dependencies, which just means more meetings, and less reliance on the original "agile planning".

Basically both of these systems assume you have more control over the work you need to perform than you actually do, making them essentially a waste of time.

Collapse
 
namenotavilable profile image
Adam Markiewicz

Agile requires generalists wanting to constantly learn and teamwork, for a special breed of people I would say and then if its people you always need oversight but looks to me like Agile methodology in software development circles is just expanding and it was adopted as valid by software companies because of significant amount of various frameworks and technologies developed in recent years. Its nothing new though. Beginner Generalist

Collapse
 
v_bird profile image
vbird

agile development is terrific for a team full of engineers who really want to build something. to those teams most of their members who only code for a living, it would be a disaster. for the latter the only feasible development methology is assigning tasks to each one of them and command them to finish the task without any delay. If not, you fire him. If any unforgivable mistake, you fire him. If any whinning, you fire him.

Collapse
 
danbailey profile image
Dan Bailey

Ooh, as someone who made a foray into project management for far too long, I feel actually qualified to comment on this.

Agile/scrum are great when you don't have a clear idea of requirements up-front or when you have a client who is very fluid with their needs over the course of a project. A PM has to be seriously buttoned-up to make agile work well as it can spin out of control pretty easily if you're inattentive.

Traditional waterfall methodologies are better if you have concrete requirements and a PM strong enough to prevent scope creep.

Collapse
 
cjlebel profile image
Carl J

Whole point of agile is to get constant feedback, and pivot when there's issues and/or the client decides that they no longer like a feature or the project.

Traditional waterfall gets you the clients feedback sometime in the distant future when it could be too late and costly to make changes.

Collapse
 
leob profile image
leob

I'm for it as long as you just keep it extremely simple - as soon as you need to hire a Scrum Master then know already that you've done it wrong :-D