How well acquainted are you with these methodologies? Have you ever been part of a team that followed these approaches? Share your experiences, ins...
For further actions, you may consider blocking this person and/or reporting abuse
Unfortunately, rulesets for development processes are riddled with marketing BS. There are a few takeaways, though.
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
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.
We probably have a different work experience.
A tale of two teams
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.
Scrum never worked for me.
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.
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.
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