Видео

I have seen and experienced issues with agile and have always been sceptical of some of the processes. However, it would be good if the video could provide quantity reasons or data highlighting the issues. At the beginning of the video, you say daily scrum is "COMPLETELY unnecessary." But then immediately follow up with "it works for some teams and not others", which is contradictory. Regarding sprint rews, not all product owners are going to be part of your scrums everyday. Jira is just a tool. You can design a building in Revit but it doesn't make you a good architect. It's just a tool. It'd be valuable el if you can give practical recommendations on how these tools can be used. If you work in a large organisation, reporting is just a reality. But management can put in place more actionable and streamline reporting processes. The chart.. well.. its just a bloated chart put together by a consultant to highlight the ethos and says very little about implementation. It's not even a process chart so has no real impact on day to day SW development. Time tracking is non valuable adding, but it's almost impossible to manage a large team without tracking peoples time. I'd love to see a follow up of this video with more practical and quantifiable recommendations.

Agile is shit

The only thing that is surprising to me is that it took this long for people to realize how ridiculous and non-Agile Scrum is. It was obvious to many of us from day 1.

For better or worse JQuery is still used ubiquitously! I still use it is a number of places. If it's the right tool for the job then use it.

Thanks! I thought I was going mad. But it’s nice to meet someone who knows what it’s actually like 😊

nowadays I only attend to dailies when I need something or at mondays. it's way better and I free more free

The problem with Agile methodologies are that they are derived from Extreme Programming which has a disdain for deadlines and fixed feature sets. Thus the methodologies are by design not functional in any environment where delivering specific features by a date is important. This would include delivering software to any Fortune 500 company or the federal government. If you're writing software for some bullshit free website you can do what you want; this is where agile shines. Managers start micromanaging agile teams because they need to deliver software and the agile teams can't tell them if they'll be done on time. That's where you get managers converting story points to wall-clock hours. They're desperate. The next iteration of Agile will include mechanisms for deadlines and commitments.

So basically story points are just ways to say how much more you should be paid I mean two coders who put out the same product and the exact same product one does it in a day and one does it in 100 days that guy who did it in a day should be paid more because he put in more effort therefore he put in more story points is that correct

Agile is like communism. It sucks because you're not doing it right. ( /s ) Or rather, not doing it at all, as I don't consider scrum to be agile, if anything it's the exact opposite. It's iterative and incremental which is better than waterfall, sure, but it's not agile. Agile is when the team gets to decide their own process, nothing more, nothing less, period. I worked in a place that was actually like that and it was glorious. We barely had any meetings, maybe like 2 hours a week in total plus whenever we needed help from each other obviously. We got so much fucking work done not being bogged down by process. And good work as well, as the objective wasn't to meet an arbitrary deadline at whatever cost, but to deliver quality. Granted sometimes things got a little bit chaotic, but it wasn't nearly as bad as scrum masters would have you believe. Something I don't think managers understand is that software development is very much a creative process. You need to be in the right mental space and your performance sort of ebbs and flows. And being unhappy is definitely one of the biggest productivity killers. It's actually insane how much more and better I code on days when I'm in a good mood. When everything just clicks and difficult problems are easy. Well I think I can count on one hand how many such days I've experienced in a corporate environment.

Scrum is also stripping away a layer of responsibility. Only way to 'grow' is as Scrum master or Product owner, roles a true dev does not want to achieve. No senior dev, opportunity, the pay is less and not your manager gets the blame but you, for the responsibility is shifted (without increase in salary), even if the estimates are completely off because complex tasks need thinking and sparring with competent co-devs, but they are occupied with other tasks in the sprint. The agile manisfesto is filled with commonalities that you think make sense but it is deceptive like the talk of the salesmen that sold encyclopediae, who did not need one? Many good comments on your rant.

If you read the Scrum Guide, you might see that all of the problems that people describe with it don't come from Scrum but from managers and Scrum Masters that are applying all the crap that has been added to Scrum courses for the Scrum courses to last more than an hour.

Scrum is not Agile, and Agile is not Scrum.

With so many processes and procedures there’s no time for software development

One of my acquaintance fron India mentioned that his company is using alterd version of Scrum to micro management!!

It has to do with market size as well. I know China are paying fresh grad devs six figures USD in Tencent,Baidu to compete with silicon Valley. This is unheard of in UK or Australia. Like fresh grad almost never make six figures usd

What corporations call "agile" is not agile.

About Jira, agreed. There are best ways to think systems, and they are needeed because business goals, costs and efforts must be managed and changed as needed, unfortunately, and data about results are essential to this.

Well, I'm a Scrum/Agile student, but also experienced in dealing with team management/effectiveness and I understand where it comes from. But it is important to say that there are MANY things said in the video that do NOT correspond to Scrum Guide/best practices (those are in fact the opposite to what Scrum Guide defends, like PO even attending Daily Scrums, or releasing only at the end of the sprint). From my experience dealing with change management and other roles, It's pretty clear that the problem is probably fake/dysfunctional, top-down micromanagement contaminating agile efforts, leadership/stakeholders not wanting to change their own paradigms and behavior, etc. That said, of course that everything should be able to be inspected and adapted, but lets drive the conversation more about why are high level stakeholders and managers faking agile while keeping the same non-realistic expectations and visions about people, work, resources and priotities.

Tons of super solid points, very reflective of my own experience as a software developer for 20 years.

Working for more than a decade in various software development roles and 3 companies with different backgrounds, scrum worked fine for me. We made scrum fit for the team and stakeholders, not force scrum to them. It wasnt perfect. We had issues too, but we resolved them through communication and proper strategizing. Not sure why it worked fine for me compared to the others.

I remember working across three medium sized projects - my day started with an hour and a half of stand-ups. Then there were all the other meetings, then "cross functional" meetings, then every the idiotic change "manager" decided she needed a stand-up ... I probably did a couple of days work in the 14 months I worked there ...

One part of the problem is, that corporations have identified Agile with scrum. But scrum is not Agile. Scrum is just another process -- maybe more lightweight than others, but it is a process. So the implement a process -- and again violate the first rule of Agile. People over processes. Even the best implementation of scrum (and the most are simply not good) is not Agile, because it is a process. I see it that way: Scrum was invented as an excuse for corporations not to implement Agile. They took elements from manifacturing (particularly the car manifacturing industry in Japan) and formed it to a nice Sdev process, that sounds agile. But it is not, the ideas where invented to make car manifacturing more productive by creating peer pressure on manifacturing workers. But computer engineers are not manifacturing workers and I personally oppose the technique of using peer pressure at all! So, IMHO scrum is NOT an agile technique, because Agile never used such inhuman techniques and instead relied on the fact that most people want to be productive and do meaningful work -- but the technique of peer pressure completely twists it into not trusting people and instead enslaving them.

Thank you. I agree with you 100 percent!

I worked in a company whose "managers" were actually using Jira for performance reviews. So much for mentoring time. Oh, what did these managers do? They were Jira experts!

For a small SW startup, if not Agile/ Scum, what is the other efficient & effective development methodology?

If you listen to uncle Bob - who made agile - all these meetings and corporate shit is not Agile.

Halleluja, you are speaking to my heart!

A good amount of scrum masters are rather on a level of scrum apprentice, that is the problem. If you have more than 1 meeting per week, you simply waste resources and have less time to do actual productive work.

Agile (and Scrum) often receive a fair amount of criticism, and I understand why. However, much of this criticism reflects the actions of leaders rather than the process itself. Agile is a spectrum; it isn't simply black or white. If you dislike "meetings," it's not Agile's fault; it's your leader's fault for not understanding the value (or lack thereof) of those meetings. If you find Agile "too rigid," it's likely because your leader doesn't know which tools to use and which to ignore. When implemented correctly, Agile allows for iterative development at a sustainable pace. But what does "correctly" mean? It varies, as every environment is different. Stop trying to blindly implement activities and focus on understanding the underlying principles and value that Agile, as a toolset, brings to any project. And no, Agile didn't fail devs, their leaders did.

As so often the main problem is the implementation. The framework itself has fewer problems, it's rather a set of ideas and mindsets. Scrum is one of many agile development models but are used synonymously which is bad. Regarding Jira: If I would have to change my job I would ask whether Jira is used first. If yes, I'd immediately look for another job.

Meetings are a nightmare for introverts. That's why they become good programmers, they don't waste time talking to others.

Agile did not follow waterfall. You're skipping 30 years of other alternative approaches.

Agile is the socialism of software development, it shows that is unnefective, severlal companies are droping it and now are having amazing results, I'm currently working without agile and it amazing, I was about to stop working as a software developer because agile and his people "scrum-minion(masters)" are like religious fanatics, until I found a company that gives the control of planing to the developer no scrum or agile cr@p! we just organize what has to be done and in the right amount of time, so... agile must disapear

If scram is not fit for you may be it is good idea to try Kanban?

EU is USSR 2 and as such produces not competitive products and services. Look at national debts of EU countries and you will see the southerner are on board of sinking ships and Germany birth rate has consistently been negative meaning the motor of EU is getting old and dying. So salaries for slaves not having a future is low because oligarchs owning the EU economies through national debts want a new world order modeled on China and thus want to get rid of most white. Same deal in the US btw. Massive immigration to repopulate with hard working, not thinking young slaves. Those who work for low wages, low benefits and have high birth rate.

The full SCRUM methodology seems like it was designed to motivate school children in a classroom situation.

Agile is not failing, people implementing agile are. Scrum is not agile! Agile is about learning, not ceremonies.

Accurate, and how funny is it to get looked down at, reprimanded or even fired for not being a 'culture fit' because of this opinion.

scrum is a waste of time and it sucks.

It's amazing to me that we started with the Agile Manifesto and landed on the scam that is SAFe. Oh, how the mighty have fallen... It's a powerful sentiment when the original authors of the manifesto actively advocate against all of these frameworks. Also Agile was not founded on Lean principles which came later.

Everyone whines about management and tools. Then you become a manager and you see it aint easy. That is why these processes are and frameworks are necessary. By the way, showing SAFe as an example is a strawman. SAFe is basically waterfall. Showing SAFe as an example of scrum shows you do not understand scrum at all. However, I automate the hell out of everything. That's how I enable my teams.

So use Kanban then...

So I’ve been thrust into all this because I have an exam on “Software Processes”, which basically boils down to agile. My teacher seems to be in favor of agile, but constantly mentions that there is a dark side to it, and that we should be careful to not fall into it. Having seen a couple videos on people who, like this, are against agile and scrum, what I’m taking from it is: agile, and the agile manifesto are, in principle, goof ideas, it’s a good framework to follow. However, scrum and other such processes have ended up adding bloat and going against the principles of agile, so in the end, when people use these processes to be agile, they are actually failing. I take it that this is what my teacher means by the dark side.

Try ipad mini

Pointing out the downsides of agile frameworks and processes in organisations that have lost their way with it helps to make people think. However, it is even more valuable to jump right to the positive side and focus on improvements. You mentioned some improvements like "avoid or automate the hell out of all time consuming and non productive processes". A cohesive set of this kind of improvements like that would be helpful today. Perhaps we need a new manifesto? With things like "We value automated processes over manual processes" and "We value daily stakeholder engagement over sprint reviews" and "we value non restrictive tools over restrictive ones" or something like that.

- 1) **Daily standup** is intended to be a very short, high quality, face to face synchronous communication period. Can asynchronous communication replace it? Also, there is nothing that says the work of the day cannot start before the standup starts. In fact it's extremely common for global teams to have only a single standup per day and it occurs at different parts of the workday depending on the locale - 2) **Sprint concept is outdated because of CI/CD** and since your work is typically done before the end of the sprint you see redundancy in having a 2 week sprint. There is obviously a practical limit of how often you can demo to stakeholders. Also, the tendency is to exclude stakeholders to make arranging the demo easier. This is a sign of an organization focused on production output over business impact and very common. This is a primary cause of why most software features don't give good ROI to the business. You keep doing this and you end up investing a lot of iteration on features outside of the "vital few". In extreme cases the entire product is compromised and killed off. - 3) **JIRA** came way after Agile and so obviously nothing about Agile claims that particular tooling will result in good practices. Agile is above all a mindset, secondly principles, thirdly best practices that are intended to evolve, and nothing else. - 4) **Time tracking**. Heavy emphasis on timetracking is a symptom of fake agile, most likely driven by non agile contracts. - 5) **Scrummaster**. If your scrummaster is not shielding the team and you are having to do it, then you're actually the scrummaster! You didn't mention this, but a dedicated scrummaster is probably not needed with an experienced team who doesn't need coaching, where little customer interaction is happening and priorities are stable. However, ask yourself also if all your critiques could be applied to any project management methodology that may exist and not just agile. If yes, then it's a symptom of confirmation bias where anything related to project accountability, management and insight is scorned. If I have a bunch of money to spend and one team gives me visibility and the other does not, which one am I going to pick? - 6) **Reporting** How much time do you think agile actually requires for reporting? With CI/CD tools and so on, it should not be that much actually. And in my experience, teams that reject oversight and just produce watermelon reporting eventually get bitten.

You hate Jira? Please use Octane. After that, you will love Jira ;-)

Wonderful video for engineering managers.

I am sorry to hear about your bad experiences with Scum and Agile. I have nearly 15 years of experience in Agile and can vouch for the requirement for Agile to deliver complex projects. Unfortunately it seems the agile has been misinterpreted or misused in the projects you have worked with and I can understand your frustration. It is not to increase the productivity but to deliver the most value to the customer. Both are different. I have seen agile being used as a stick to increase the productivity and efficiency but that is BS. Those are anti patterns.

I understand your complaints about Jira, but could make a suggestion in replacement of Jira?