Agile and Scrum: What Are Your Thoughts?

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

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

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.

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.

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

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.

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.

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