I remember in my school (we were like 16 at the time) we had an "agile workshop", we had to build a paper plane using agile We had a buzzer that went off every time we had to do a mock meeting and stuff like that. After some time everyone just ignored it and kept on building the plane during the mandatory meetings. Probably a lesson in there
I'm required to attend a daily stand up with the engineering team (I'm the IT guy), 99% of the time I ignore everything about the meeting other than which person is currently talking so that I can say my part on time. Other than that I continue doing my actual work on my laptop.
i work for a fortune 50 company and agile is rammed down our throats but what we do is agile in name only. redundant scrum ceremonies, meetings about meetings, and an obsession with jira metrics, we're continuously pestered and micromanaged over arbitrary statistics that have no bearing on the work getting done because it ruined someone's graph. we do quarterly waterfall planning and people freak out when a task we had planned 4-6 months prior "spillsover" into the next quarter. we are a major proponent of the agile industrial complex. my agile lead recently took a long vacation and for the first time in years i actually began enjoying being at work, it was strange and bizarre and, unfortunately, temporary
The purpose of agile is to force higher skilled devs to drag the lowest tiered out sourced devs. It has nothing to do with quality and everything to do with forcing economics outside of the industrialized countries.
This is my exact experience on every company i worked for for the last 5years. And I switched quite a lot due to the bullshit conditions one must endure in this terrible environments. One thing that amazes me is the obsession with micromanaging even overperformers.
Agile sucks just because it doesn't defeat the inertia of late stage corporate cultures. Execs can take anything with some brand recognition and just twist it into a profane version of itself that aligns with the interests the execs always had.
yea, I was at a fortune 500 and the scrum meeting was run by the department head, and he had his assistant and product managers in it too. we would go around the room and everyone would say what they are working on to him. and he is non technical so he has no clue what any of what we are saying even is
Consultants suck because they only function as legitimising forces for the owners of capital to point to to justify insanely harmful business practices, and provide the exculpatory safety net for management to point to when it inevitably fails.
Doesn't it mean that the agile idea itself is good but late stage capitalism just transforms everything into something abhorrent no matter what individuals try to do?
@@jeffwells641 "Individuals and interactions over processes and tools" It was literally called agile software development as a defence mechanism for trying to derive a process from it ... yet here we are. In a world with certified "scrum masters".
@@sacredgeometry Everything is a process. "Code -> See if it works -> Release" is a process. Individuals and interactions over processes and tools means that *if there is a conflict* you should always follow the people, rather than the paper. That's it. It doesn't mean that there never should be any process to anything.
@@SkywalkerWroc Where did I indicate that I thought that there shouldnt be a process. What I said was that prescriptively creating a process and calling it agile then having people subscribe to it as if its the correct way to "do agile" is literally contradictory to one of the few things written in the Agile manifesto.
@@sacredgeometry No it doesn't. The manifesto ends with "That is, while there is value in the items on the right, we value the items on the left more." The manifesto is stating that we should value individuals and interactions over processes and tools, not that there is no place for process and tools. If we are considering integrating processes and tools, we should make sure it's worth it.
@14:00 there's a good example of when NASA tried to go through the engineering documentation to build the Saturn 5 engines. At that point, most of the engineers were retired and done passed away. The tattoo would be akin to reverse engineering, even with the documentation. In docs, you write down the difficult parts that you encountered. The obvious or the happenstance doesn't get documented but it is crucial for somebody who's skipping all the research that came before the final version.
2:26 I'll do you one better: True capitalism has never been tried because businesses hate competition and free markets/capitalism are all about competition. The big corpo's only means of survival is govt to protect their massive mergers and acquisitions.
True capitalism is impossible in any functioning democracy. It's fundamentally incompatible with a charter of human rights. You'd have to devolve into pure anarchy, to allow for capitalism.
Truth: Bad managers plus Agile equals bad management. End of. The business world does this with everything. Don't blame Agile. For example, my wife just started at a major company that uses a 1920s personality system (like pre-MBTI) for their management stuff. Like you get classified as a Type 1 and your manager is a Type 4 and that's how you're supposed to relate. Obviously this is dumb and bad and doesn't help the company. And good managers ignore it. Just like how they should be ignoring any parts of Agile that don't work for their team. Like YOU SHOULD NOT BE IN LONG MANDATORY DAILY MEETINGS. They're called standups because they should literally be so fast you can do them standing. Just "any blockers? No? Cool get to work."
I remember reading the manifesto and couldn’t help to think: “this is exactly how we worked at the technical department for research and my first software house that I worked for”. And we didn’t even have sprints, and sprint planning and standups. Everybody had their project specs and they just worked on it. And if we got stuck or had other ideas we discussed it adhoc. And we decided what to do. We all worked in a part of the system. And only when they needed to integrate we had a little discussion about the interfaces. And these were mission critical systems even! And nothing could plan these in waterfall. Because nobody knew how much a battery would deteriorate at -45C continuously. We knew it wasn’t great for a battery, and we found to our shock, that the two batteries didn’t even loose capacity at the same rate being encased made it even worse. And another colleague said: “you should also add a massive fan to chill one side more then the other, as those are the conditions on Antarctica. Suddenly we had a massive head scratcher where we had batteries with a 23% potential difference, discharging the other battery as a result. So we had to think to something to keep the batteries at the same temperature. In an agile way, we decided to test if we could change batteries to individual cells and alternate the two separate sources’ cells. That way we would have similar temperatures. Managent doesn’t understand that engineering is basically finding problems, solving those problems. They think it’s a conveyor belt of standard worked out solutions. Or it was, we would’ve bought the product/parts. And those two departments I worked at, were ran by engineers 35/40 years experience. They have been there themselves, they know that given enough time a problem will be solved. And their experience knows when you explain a “problem” how complex that problem is. And they would either say: “Cut this wish! Try this! Iterate though!”
I was working for an Agile consultancy firm. We couldn't even stick to Agile in our own internal work. Agile only added a layer of process complexity, stress, micromanagement and meetings about meetings. I tried raising important questions about us turning more client-centric and actually listening to their needs, but no... we had things in the Kanban board to work on.
The problem with Agile is that it ranges from "Do a good job" to "You can't do waterfall with a service since it never finishes and often needs to evolve", so once you remove the sugarcoating you basically have what employers do, a circular development model to work with a service (quality of work varies, it's great engineers writing the best code but business works on good enough and velocity, see "marketing team selling features we don't even have"). As for it itself, it's a fine milestone of people realising software is a service not a product (or imo, software itself changing from a product to a service), but it's nothing more than that. What people normally attribute to Agile (et al systems) is more about team science and workplace science. The issue of meeting and "how long will X take" isn't due to the Agile boogeyman itself, but simply that a circular development model requires constantly keeping people in the loop (preferably in a scheduled manner, hence weekly meetings) and effectively project scheduling on a regular basis. I think way too many people suffer from the SWE problem that "no you're not a one man team, you don't work in a bubble" and that makes people think that Agile allows "you can just disappear for 2-4 weeks and appear with the product at the end" without socialising with anyone on the matter until then. For a company to work there needs to be management who have insight to their team, and to get that, that requires meetings and time estimates to be made. I came from a mechanical engineering background so while reclusive like SWEs, not as much, likewise everyone understood the importance of the bureaucracy aspect of the work. I do think this was influenced by both the fact mech. eng is waterfall (as per products) so the Sisyphean burnout doesn't quite occur as often, and also because mechanical engineering can be incredibly complex with a lot of blindspots unless you explicitly train/work in it, you're forced to be a team player, hence the "one man team" issue is ironed out early in your career if not during uni.
My team is the good agile and I can't imagine a better way to work. We choose our own processes. Every other Friday we discuss whether our processes are serving us, whether they can be improved, etc. We've reduced recurring meetings, crushed our backlog, and our manager regularly expresses gratitude for our ability to manage ourselves. Other teams worry about "sprints", quality is eschewed in favor of scrambling to meet arbitrary deadlines, and features don't get delivered on time anyway.
Whoever manages that team you better treat them to a great lunch once in a while as that sounds too good to be true. I've made dozens of attempts to constructively head off problems and concerns, or call out productivity flaws, or make subtle ways to how we do the whole Agile thing and every time it is met with dismissal, denial, or even nihilism by management who say its above their paygrade and nothing will change.
Same here, and we even do relatively rigid scrum, but the key is that we also review the processes constantly and cut or change stuff that doesn't work for us. Yes agile can suck, but it's by no means inevitable.
2:15 The reason for this issue of Agile "In Practice" falling apart is that it's a Management Problem being solved by applying changes to Not Management people. Developers would just develop using Go Horse and get things done. But management would be lost and lose a lot of its purpose in that model. So Agile is the method of making management relevant to the level it always thought it was.
The international large enterprise I work at introduced both Agile (in the form of SAFe) and "Software Development Process Landscape" at the same time. These processes are so detailed that they even tell us how to write commit messages and how many times in the day to push our code. Yah, go figure, it's all been massively downhill since that.
Holy moly. I feel like the tools around agile in the end got used for what management wants more and more control and nothing else. How do they expect people to deal with this? And my condolences to you.
15:04 I write tests at the module level(not units), all tests limits their calls to a central facade that sits in front of the module's classes. After writing a parser for a DSL. I told the team that, the best way to learn how this works is to change or comment out code and see which tests fail. You're also free to refactor as long as the facade remains intact (which means no changes to the tests), if the test suite passes then you have not broken anything.
I have said it before and will say it again, managers have to be outside of the team and it needs to be run by the developers, and QA - if your team has one, and they need to have the developers to buy in to the work and they give the timeline. Once management is dictating that timeline, it isn’t Agile and is just a reimagined Waterfall and it will fail. I worked in a team that did control the process and did meet the our epics multiple times in a row, and the manager said that was the first time he had seen a team do that and that confirmed that the process does work when it’s not management really controlling it. When the team runs the team, we would cancel stand ups when it didn’t make sense to have them, but retrospectives were always required and was highly encouraged to attend - this would then require actions that must be taken by the next retrospective and did result in improvements in the process. Planning poker ended up being very useful and we had a great time making sure that the requirements were clear and complete during this time, and this had to be clear to everyone.
Velocity, planning poker and the rest is all Scrum or Kanban stuff. Agile says teams should reflect on how their are working and iterate on their process to get more productive. Then some other people started writing books about "How to do Agile", making up stuff like Scrum.
I still wonder what the alternative is. Not the alternative to "agile", but rather: Do you seriously think that the problems with "agile" go away without "agile"? Or were introduced with "agile"? What is the alternative reality without "agile" that is better than "agile"?
Iterative Waterfall. It's basically everything that the corporate world needs. Stable releases and deadlines that allow for planning for things such as a marketing campaigns or financial predictions. But it uses the evil world - "waterfall" - and no self-respecting developer wants to work in 🤮waterfall 🤮.
@@James-gm9cs Minus points for not even reading my post. Sounds like the worst alternative. The problem isn't heirarchies nor does holacracy do away with them, the problem is rather what happens when the size and scope grows beyond what the person in charge can handle. A holacracy just introduces the exact same problems that comes with "agile".
@@JohnDoe-sq5nv I'm currently working in an organisation that's struggled to implement a good change management structure due to managerial/executive-level bottlenecks. The whole point of a Holacracy is to remove managerial beauacracy, empower those who know what they're doing to make decisions, and work in cross-functional teams. It's a principle I'm trying to push to implement where I work. Because once we can do that and we can make the decisions we need to, then we can implement agile correctly, make quicker decisions, and increase our capacity to deliver high quality change. Scope increase is only a problem where you have process bottlenecks that can't be fixed by adding more resources to a project. In my case, hiring more devs or pm's or ba's won't fix anything because the managerial bottlenecks built into the process will always limit how much we can do.
@@James-gm9cs >The whole point of a Holacracy is to remove managerial beauacracy And it doesn't. Because in a Holacracy everything will need to be alligned to the bigger whole anyway thus you will never get away from the same problem. The real problem is that the company is too big for its own good.
This "no true scotsman" thought terminating cliche needs to stop. A thing is, what a thing does. If you think you are/are doing X, but are in truth doing Y, you're Y.
SAFe is not Agile, despite having "A" in the name. It's a process above individuals or interactions. It's fundamentally against even the very basics of Agile. If you think SAFe has anything to deal with Agile, you clearly *never* read the Agile Manifesto.
Sometimes it's because the thing has evolved beyond the scope it's original creator envisioned Sometimes it's because the creator was and remains just straight up wrong See: Graphics Interchange Format
Nobody examines the problem domain in the beginning anymore; the WHAT of the program is kicked down the road as technical debt to be solved later. I blame "cloud enablement" and ransom note architecture. Literally architects throw-up a diagram with AWS service icons linked together with arrows, quite proud they have it in Miro, but nothing else. ALL of the heavy lifting is tech debt that gets kicked out until it's time to deliver the product and then the team turns around and goes, "Well, we're almost out of time, which of these features do you absolutely need?" Terrible.
@@TheLucanicLord I'm really glad I'm not the only one "seeing" this. The people propagating this are always so confident in the success of their terrible code that never scales, never does core stuff the client needs, barely addresses any data concerns other than storage and performance? "Hey, if it's slow we can just pay for more performance, it's serverless!" I thought I was going insane
Thriving Technologist here had a good video on how the Agile Manifesto was written and used to mess up the point, making it about "going faster" rather than SDLC agility.
I had a VP of Engineering who had no clue how to do agile, how to code, what the product should look like, what the product was, the state of the product... pretty much everything. That was why I (and 5 other senior engineers) left within months of each other. It was so bad when there was an actual dumpster fire outside the office we all pointed to it and said "look the physical manifestation of our company"
The cure to agile is to get all the C-suits to adopt agile and scrum for a 2 week sprint for all their stuff 2 days in and they will yeet that shit straight out the window
4:00 yeh its literally that. im 51. before agile it was a mess too. as i was told early on... head office never blames head office for being over budget / late / poor quality. back in those days people were just assumed to know what they were doing and there were long times before any feedback could be introduced to affect any changes. changes were usually rolled up into a new project. the solution? management consultants to come up with a saviour plan. agile does have some great concepts and i love MVP. if the answer is no, dont be afraid to say no. alas agile is used by managers as a buzzword orgy. where are the checks and balances for management in agile? there are plenty for engineering. when things go wrong management always double down on more management and more process.
The main issue with Agile as per the manifesto's view is that it implies something quite nice and simple, but quite practically unfeasible. Cooperation. And much like the prisoner dilemma, while it's mutually of best interest to cooperate, in practice everyone is lining their ducks to be the first to fsck the other guy over. It's the time honored "permanent retaliation" strategy. Sane minds would point out that it's also the same thing as Mutually Assured Destruction, but hey... This obviously makes the "agile works best at startup" point quite relatable, because its a smaller group of people, that usually like working together and while they might differ on subjects, they WANT to cooperate. As the group expands, it becomes every man for itself, cooperation is gone, and here we go... p.s. this is the same for business/clients. Both the startup and it's first clients are more willing to cooperate, because it mutually profitable. As the business expands, you get more and more clients, who aren't all that friendly, and in turn you become more unfriendly, to mitigate risk. And... here we go...
Tribal knowledge is tricky, and worst of all hard to quickly propagate - one colleague left who was responsible for maintaining sharepoint integration, a week later he was rehired part time to work on emerging issues with sharepoint
Agile hinges on devs having autonomy. It is ruined by management who does not want to give this autonomy and turn scrum etc into a progress report. After everythings a progress report the very essence of agile is gone and its just better to not have agile at that point.
Main issues with Agile is mangers, who don't want to understand development process, but want to have full control and understanding what current state of the project is. More that anything else it's unwillingness to have more than one plan and always trying to plan specifically for most optimistic outcome possible. That inevitably creates failures with not spare time/resources to adjust to them, which in turn compromises the whole project. Instead of accepting reality of impossibility 100% predictive planning, managers keep looking for instruments to increase control to achieve it. This is also might be a reason to avoid nuanced understanding of development, because nuances describe incompleteness of available information, which in turn does not allow for hard planning.
I started a three day fast this morning. Thank you for this message.i'm 47yrs old $73,000 biweekly and I'm retired, this video have inspired me greatly in many ways!!!!❤️❤️
Hello, how do you achieve such biweekly returns? As a single parent i haven't been able to get my own house due to financial struggles, but my faith in God remains strong.
I raised 75k and Kate Elizabeth Becherer is to be thanked. I got my self my dream car 🚗 just last weekend, My journey with her started after my best friend came back from New York and saw me suffering in dept then told me about her and how to change my life through her.Kate Elizabeth Becherer is the kind of person one needs in his or her life! I got a home, a good wife, and a beautiful daughter. Note: this is not a promotion but me trying to make a point that no matter what happens, always have faith and keep living!
@@marybradleyblack-fThis is a definition of God's unending provisions for his people. God remains faithful to his words. 🙏 I receive this for my household
Agile done right is fantastic. Currently we have two extremes with product management on the one hand with their mutated version of agile, Vs dev teams which never want meetings or recording tasks on any level.
I think there's no better proof of that than SpaceX, which uses at least Agile inspired strategy for its iterative design process. They are the apotheosis of move fast and break things
As somebody who worked on the UML 2.0 standard, I totally understand where the original agile people came from. However, what they did lose sight of is that after a certain point, you actually need more and more structure. Yes, it is slower, but it is way more likely to get you there. The current problem is companies want the low failure rates of structured development but with the high risk timelines of agile projects. The hard part to accept is that nobody will be happy with development methodology that works on a large scale. Developers will regret the time spent on documentation and shoring up shared knowledge for the future. Managers will regret that there still are no real metrics to measure or dials to turn to "optimize output". Most of the people putting together frameworks these days just don't have the discipline needed to actually design something good. They don't need it, they can just release the next version after next to fix things until developers look for the next shiny thing to save them from having to just make boring, understandable and maintainable code. And I don't blame them. Nobody wants to just grind for 50 to 60 hours and beyond. Which is why agile had the 40 hour work week rule. Which is also wrong, it needs to be 30 hours of actual work and no more than 10 hours of overhead, with the goal of making the overhead go away. But, the pay is still good enough and capitalism being what it is, people will still grind themselves down in programming jobs. Refusing to organize to prevent the worst abuses of companies (you know, massive hiring and firing cycles, outsourcing, abuse of H1B workers and so on) because they think they are special and unique and are just one gig away from never needing to work again.
I think we all misunderstand the original agile people. Agile is a good strategy to maximize money gain in short term and run away before the ship sink without taking any form of accountability. And this is exactly what they want.
This whole 286% article was to promote book... You should hear also another guy who pushes agile through whole organisations not only developers Allen Holub ("No estimates" video)
dave farley looked at how the report was done because it did not make sense, and totally ripped it to shreds for bad methodology. it was a report done to produce selling points for the book.
I used to be in management at fedex. and I can flat out tell you that the difference between a good manager and a bad one is very clear. let the people do the work, verify the work done is up to standards and provide advice and help when people are struggling. but above all, don't get into the way of your workers. if your stopping them from doing work and their work is up to standered, why the hell are you stopping them. that's wasting your team members time. that being said, as a manager you still must verify the work done meets standards and part of that is, let the crew know what the standards are, be available to re explain them many times over. and be able to have your time wasted with stupid questions, cause they are not stupid for the people asking you about them. that's basically the core of good management. right then and their.
"Startups don't have tech debt". Like chat said, they only have tech debt. What they don't have is maintenance of a long running mature product where people have forgotten why 80% of the technical decisions were made.
Scrum effectively prevents me from doing what I believe is right in the moment, in favor of waiting till I get approval the next day... And if it slips my mind the next day? Well, bye bye doing what's right.
23:51 I am very curious in what this is referring too. I have not encountered any class specific hate. I would love to hear the argument those people make
I work at a start up that's been on the market for about 9 months and I've been here since the first month and you are right on point everything we wrote, we wrote just to get the shit done, we started refactoring some things but we are still writing 5 times more dumpster code than we are refactoring. You basically called us out there.
Socrates never wrote anything down because he was convinced that if you write things down people will missunderstand your point and just stick with your practices. He preferred to just walk around and speak with people in order to keep a productive conversation going. Aristotle did write a lot down (although much has been lost) and he did improve our thinking in major ways. Western civilization owes a ton to him as well! Unfortunately he also had some wacky ideas and because they were written down and Aristotle was so respected they became codified and possibly kept Europe in the dark ages longer than necessary because nobody dared to say that the great genius was wrong (in some areas). TL:DR - learn from the masters, but don’t treat them as Gods and don’t keep (all) their practices if they don’t work for you. Their general approach might be useful but most likely not all the details. Stay “Agile”!
Mid to small companies with trusted and skilled engineers can do agile effectively. They have enough trust, and they have light processes that respond to their needs. It's when the company grows big that everything falls apart. Suddenly there's a need to perform in front of investors, the management hierarchy has grown enough tall and wide that the top doesn't trust the bottom anymore, consultants are hired and cumbersome "agile" solutions are sold.
A lot of times, teams come to us with with result that they want. We stop them, redirect the conversation to "what are you trying to accomplish and do you have any constraints" This is infinitely better than what they were expecting, because we don't allow them (and by extension ourselves) to shoot themselves in the foot We plan for the future, and make sure we aren't cornering ourselves too badly
Agree so much with tribal knowledge. I built a majority of the multi year project. Colleagues came and gone. They are able to eventually debug to an issue but I know in my guts exactly which line of code is causing that bug that appeared on the bloody demo to stakeholders. That shits my baby even tho I hate it's living guts.
I've seen agile work and work VERY well. However, it was only at small startups because we were able to actually be agile. Lots of very close collaboration with everyone. Once you go a an existing business, the business processes are somewhat antithetical to agile process. So the business is always trying to push software creation to be more like business process. So the question comes down to who determines process. If you let the business do it then you're not going to be agile.
1:55 technically by that definition, all companies are agile because all companies are teams of people each with their own bespoke systems, rules, and processes.
You have to consider the incentives outside of these 'agile' feature teams. Maybe there's not always an incentive, or even priority to truly optimise for outcomes and productivity, but safety and predictability is the priority. Devs won't have this view, but companies need to report their own version of reality, and it's easier to abstract reality via Agile process
I'd say the Rafale jet was developed in an agile way over the course of multiple decades. It's got its most value-added feature first, which is to fly, then they added more and more military capabilities to it, slowly, while the product was already used by the army. The F-35 development was an enormous V-cycle since it had a enormously ambitious spec from start, and flying flawlessly was a late-completed feature.
13:10 Yeah this isn't "research". The team that did this "research" clearly doesn't know how to do research. You need an amount of people in your dataset proportional to the entire set of people possible. In the case of software engineers you want to ensure you have a balance between age groups & location, not just English speakers, but also include mainland Europe and maybe Asian / South America. And at least 10000 participants(more is always better). And you want multiple measurement times, preferable at least an entire years worth, so a survey once a month or twice a month. And without fixed dates, so dont' do every 20th of a month, it should be a little varied and avoid Fridays, Mondays and dates just before or after holidays to avoid those "special" days from influencing how people "feel".
8:10 - 26.9 million Software engineers form a noticeable part of the workforce around the world. There are an estimated 26.9 million professional software engineers in the world as of 2022, up from 21 million in 2016. questionable statistics ever wondered why software is broken ? 24 October 2023 This data ranks the top 100,000 names from the more than 8 million scientists considered to be active worldwide, taking into account 22 scientific fields and 174 subfields.
Actually Agile and Scrum works there are company who do it right the problem 80 to 90% do it wrong. This what my PM trainer said who works also as a company consultant. I have found multiply RUclips video which came to the same conclusion . Web Cody also made a video who he tells how it for him and the company he is in it works. Inheritance good luck to get away from it HTML is inheritance until the root document . In general its okay when you know how it works and you know the problems and don't over do it.
It comes down to the project management. Agile must not be seen as a religion! There are cases, where waterfall is the right way, sometimes one can do an agile light is the right fit. It is about the specific project.
I think there are some good ideas in there still: work incrementally, produce something working often, don't plan too far ahead, implement fast (automated) testing, have a trunk based version control strategy, be on good terms with the customer/stakeholders, establish friendly and collaborative team dynamics, don't rely on abstract stats about teams and people. Then there's a bunch of ritualistic meetings, scrum masters, jira stats and other nonsense. This allows companies to call themselves agile while doing none of the good ideas in there. I work in sprints. This segments the work, but since we don't release at the end of sprints is does little to make us work iteratively.
Fun game for when people start talking about charts and agile. Try and sneak discussing the dot product and cross product into the discussion and keep a straight face. Bonus points if you can make project managers do a heap of this as part of the regular process.
I don't know if prime is going to talk about or defend the manager's point of view since there is a reason why those companies eventually all bow down to managers. There is a reason why managers is actually stuck in the middle, the good manager and bad manager isn't that different. Being technical doesn't necessarily makes it the manager doesn't need certain metrics to protect themselves and also satisfy its own existence.
If I had to play devil's advocate, most companies have an IT department as a center of cost to support the main business, and because IT engineers are expensive, we need to provide metrics to justify why we are paid so high. So those corporative methodologies because a necessity for us in order to provide those metrics and to show we are doing our work.
Snowbird is a nice place. I've only been there in the summer. You can hike in the mountains. And have a hotel room waiting for ya. They had a convention there multiple years. That's why i was there.
Agile is mostly used to micromanage My teams have one, sometimes two, developers who know exactly what they are doing All that is necessary is a meeting with the business owner to explain their requirements
I feel like project managers and middle managers like agile because its something they can do and get technical and nit pick about. it always seems to be non-technical people who spearhead it and run the agile meetings / standups. when in reality its supposed to be for developers only with NO managers or project managers. yet somehow those people always end up running the scrum and turn it in to a spring planning / assignment of tasks meetings. idk why agile is this whole special concept. it could be said as just "we have a weekly meeting to assign new tasks and track progress of the current tasks"
If we as humans were capable of planning that far into the future we wouldnt need agile in the first place. Sometimes the best way to do something reveals itself in process and pre-ordained protocol will always get in the way of that.
This is funny. I had my mid-year 1:1 with my manager, and for my development opportunities, i mentioned i want to get my PMP and they recommended that i look into SAFe Agile certification instead
I honestly don’t believe that there’s anybody in my team who is incapable. Sure, there are some people who are more lazy than others, but they are capable. Maybe I’m the incapable one?
I wrote the (scrum/agile) software development process for our company, and it didn't include any of those meta-level topics. No waterfall, no burndown charts, no tracking. I don't even know what CI or STD means. It's just the hands-on stuff, so new employees can read it and instantly understand that we basically do the things they learned at university and know which level of information is needed at which point in time. This way, the company can act instead of react. We had stuff like which documents does the service technician need to check the instrument, or when exactly do you have to start taking notes if you change something. You know... because people have to take your stuff and run with it. Isn't that the most important thing?
Agile at my workplace (30 yo company) means: no planning, no discussion in the team, no talk at all about the project except that the boss comes in in the morning (who has no clue about Software engineering) saying what he thinks is good for the project and we should make it work now. No matter what. Oh yes: "today is demo day, so make it work and stop everything else". And a senior that also worked in this company for 30 years, never used a modern framework with state management and is constantly nagging about it (we use flutter. Yes actually one of the rare cases where flutter makes sense, so at least that was a good decision). No architecture, no lifecycle management, no nothing. That is in their eyes agile. Please rate my workplace where 0 is hell and 10 is a devs dream. edit: pushing to prod is "hey, can you push to prod? thanks dude."
One of the great ironies of my life was seeing Agile morphing from a developer-friendly methodology into a set of iron chains holding developers down and endlessly wasting their time, because nobody understood what it actually was and they went with their gut instinct, which was to exert more control over creatives instead.
You cant avoid knowledge silos. And its a good thing. You should still try to mitigate them with trying to walk people through them and documenting where possible but its impossible to get everyone on the same level of understanding as the "maintainer"
Even waterfall was bastardized. The original papers talked about iterations and just use your fucking head. Of course managers come around say: "so you're telling me you know when its done?"
Agile is one of several methodologies to choose from. How is it possible that it happens to be the best fit for such a diverse range of companies? I'm asking the same question of cloud. There's a lot of adopters who only signed up because their friends did.
Non-tech people who are directly involved in development process or decision making process on lower levels are the real issue. I think that even scrum can work if ran by engineers
Process is just a shim to fix communication problems. Since we do this with every process, maybe we should agree that there is no process that solves for the problem of perfecting communication.
Thought I just wasn't white enough or had never been anywhere with enough snow and sun at the same time to need them, but even prime don't know what they are.
![Seungmin "그렇게, 천천히, 우리(As we are)" | [Stray Kids : SKZ-PLAYER]](http://i.ytimg.com/vi/kAzmhLHePqU/mqdefault.jpg)
I remember in my school (we were like 16 at the time) we had an "agile workshop", we had to build a paper plane using agile
We had a buzzer that went off every time we had to do a mock meeting and stuff like that.
After some time everyone just ignored it and kept on building the plane during the mandatory meetings.
Probably a lesson in there
I'm required to attend a daily stand up with the engineering team (I'm the IT guy), 99% of the time I ignore everything about the meeting other than which person is currently talking so that I can say my part on time. Other than that I continue doing my actual work on my laptop.
@@tankerkiller125you should play games instead, they want you in a meeting so you should be justified not giving that time to work
Well, you adopted your process in order to get things done. You followed Agile perfectly.
must be one elaborate paper plane
Having a zillion meetings over a paper plane is the exact opposite of Agile. That's just normal bad management.
i work for a fortune 50 company and agile is rammed down our throats but what we do is agile in name only. redundant scrum ceremonies, meetings about meetings, and an obsession with jira metrics, we're continuously pestered and micromanaged over arbitrary statistics that have no bearing on the work getting done because it ruined someone's graph. we do quarterly waterfall planning and people freak out when a task we had planned 4-6 months prior "spillsover" into the next quarter. we are a major proponent of the agile industrial complex.
my agile lead recently took a long vacation and for the first time in years i actually began enjoying being at work, it was strange and bizarre and, unfortunately, temporary
sounds like hell, any chance to go to a smaller company without this bullcrap?
The purpose of agile is to force higher skilled devs to drag the lowest tiered out sourced devs. It has nothing to do with quality and everything to do with forcing economics outside of the industrialized countries.
Agile ≠ scrum. Two *very* different topics that you seem to confound.
This is my exact experience on every company i worked for for the last 5years. And I switched quite a lot due to the bullshit conditions one must endure in this terrible environments.
One thing that amazes me is the obsession with micromanaging even overperformers.
Do you work for my company?
Agile suck because every concept will inevitably get molested until it fits corporate culture. Consultants suck because the customers demand it.
And thus, Scrum was born. The ultimate deviation of agile.
Agile sucks just because it doesn't defeat the inertia of late stage corporate cultures. Execs can take anything with some brand recognition and just twist it into a profane version of itself that aligns with the interests the execs always had.
yea, I was at a fortune 500 and the scrum meeting was run by the department head, and he had his assistant and product managers in it too. we would go around the room and everyone would say what they are working on to him. and he is non technical so he has no clue what any of what we are saying even is
Consultants suck because they only function as legitimising forces for the owners of capital to point to to justify insanely harmful business practices, and provide the exculpatory safety net for management to point to when it inevitably fails.
Doesn't it mean that the agile idea itself is good but late stage capitalism just transforms everything into something abhorrent no matter what individuals try to do?
1 scrum a day will keep productivity away
hint is in the name ... scum
Amen
Truer words cannot be spoken
Just one? I've had to deal with 12 a week once and one of my uni buddies had 3 a day...
Why? What did you do yesterday? Because, do you have any blockers? What will you do today?
Agile as a philosophy ✅
Agile as a methodology ❌
The hilarious thing about this is "Agile as a Methodology" immediately contradicts "Agile as a Philosophy" by even existing.
@@jeffwells641 "Individuals and interactions over processes and tools"
It was literally called agile software development as a defence mechanism for trying to derive a process from it ... yet here we are. In a world with certified "scrum masters".
@@sacredgeometry Everything is a process. "Code -> See if it works -> Release" is a process.
Individuals and interactions over processes and tools means that *if there is a conflict* you should always follow the people, rather than the paper. That's it. It doesn't mean that there never should be any process to anything.
@@SkywalkerWroc Where did I indicate that I thought that there shouldnt be a process. What I said was that prescriptively creating a process and calling it agile then having people subscribe to it as if its the correct way to "do agile" is literally contradictory to one of the few things written in the Agile manifesto.
@@sacredgeometry No it doesn't. The manifesto ends with "That is, while there is value in the items on the right, we value the items on the left more." The manifesto is stating that we should value individuals and interactions over processes and tools, not that there is no place for process and tools. If we are considering integrating processes and tools, we should make sure it's worth it.
You can get snow blindness from reflections off of the snow/glaciers. There's more the the glasses than meets the eye.
hahahah nice!
@14:00 there's a good example of when NASA tried to go through the engineering documentation to build the Saturn 5 engines. At that point, most of the engineers were retired and done passed away. The tattoo would be akin to reverse engineering, even with the documentation. In docs, you write down the difficult parts that you encountered. The obvious or the happenstance doesn't get documented but it is crucial for somebody who's skipping all the research that came before the final version.
In many companies Agile is Waterfall with milestones spaced two weeks from each other.
2:26 I'll do you one better:
True capitalism has never been tried because businesses hate competition and free markets/capitalism are all about competition. The big corpo's only means of survival is govt to protect their massive mergers and acquisitions.
True capitalism is impossible in any functioning democracy. It's fundamentally incompatible with a charter of human rights. You'd have to devolve into pure anarchy, to allow for capitalism.
Heck off, commie!
Truth: Bad managers plus Agile equals bad management. End of. The business world does this with everything. Don't blame Agile. For example, my wife just started at a major company that uses a 1920s personality system (like pre-MBTI) for their management stuff. Like you get classified as a Type 1 and your manager is a Type 4 and that's how you're supposed to relate. Obviously this is dumb and bad and doesn't help the company. And good managers ignore it. Just like how they should be ignoring any parts of Agile that don't work for their team. Like YOU SHOULD NOT BE IN LONG MANDATORY DAILY MEETINGS. They're called standups because they should literally be so fast you can do them standing. Just "any blockers? No? Cool get to work."
Except for that stand-ups are a practice of scrum,.not anything to do with agile...
I remember reading the manifesto and couldn’t help to think: “this is exactly how we worked at the technical department for research and my first software house that I worked for”.
And we didn’t even have sprints, and sprint planning and standups. Everybody had their project specs and they just worked on it. And if we got stuck or had other ideas we discussed it adhoc. And we decided what to do. We all worked in a part of the system. And only when they needed to integrate we had a little discussion about the interfaces.
And these were mission critical systems even! And nothing could plan these in waterfall. Because nobody knew how much a battery would deteriorate at -45C continuously. We knew it wasn’t great for a battery, and we found to our shock, that the two batteries didn’t even loose capacity at the same rate being encased made it even worse. And another colleague said: “you should also add a massive fan to chill one side more then the other, as those are the conditions on Antarctica. Suddenly we had a massive head scratcher where we had batteries with a 23% potential difference, discharging the other battery as a result. So we had to think to something to keep the batteries at the same temperature.
In an agile way, we decided to test if we could change batteries to individual cells and alternate the two separate sources’ cells. That way we would have similar temperatures.
Managent doesn’t understand that engineering is basically finding problems, solving those problems. They think it’s a conveyor belt of standard worked out solutions. Or it was, we would’ve bought the product/parts.
And those two departments I worked at, were ran by engineers 35/40 years experience. They have been there themselves, they know that given enough time a problem will be solved. And their experience knows when you explain a “problem” how complex that problem is. And they would either say: “Cut this wish! Try this! Iterate though!”
I was working for an Agile consultancy firm. We couldn't even stick to Agile in our own internal work. Agile only added a layer of process complexity, stress, micromanagement and meetings about meetings. I tried raising important questions about us turning more client-centric and actually listening to their needs, but no... we had things in the Kanban board to work on.
The problem with Agile is that it ranges from "Do a good job" to "You can't do waterfall with a service since it never finishes and often needs to evolve", so once you remove the sugarcoating you basically have what employers do, a circular development model to work with a service (quality of work varies, it's great engineers writing the best code but business works on good enough and velocity, see "marketing team selling features we don't even have").
As for it itself, it's a fine milestone of people realising software is a service not a product (or imo, software itself changing from a product to a service), but it's nothing more than that. What people normally attribute to Agile (et al systems) is more about team science and workplace science. The issue of meeting and "how long will X take" isn't due to the Agile boogeyman itself, but simply that a circular development model requires constantly keeping people in the loop (preferably in a scheduled manner, hence weekly meetings) and effectively project scheduling on a regular basis.
I think way too many people suffer from the SWE problem that "no you're not a one man team, you don't work in a bubble" and that makes people think that Agile allows "you can just disappear for 2-4 weeks and appear with the product at the end" without socialising with anyone on the matter until then. For a company to work there needs to be management who have insight to their team, and to get that, that requires meetings and time estimates to be made.
I came from a mechanical engineering background so while reclusive like SWEs, not as much, likewise everyone understood the importance of the bureaucracy aspect of the work. I do think this was influenced by both the fact mech. eng is waterfall (as per products) so the Sisyphean burnout doesn't quite occur as often, and also because mechanical engineering can be incredibly complex with a lot of blindspots unless you explicitly train/work in it, you're forced to be a team player, hence the "one man team" issue is ironed out early in your career if not during uni.
My team is the good agile and I can't imagine a better way to work. We choose our own processes. Every other Friday we discuss whether our processes are serving us, whether they can be improved, etc.
We've reduced recurring meetings, crushed our backlog, and our manager regularly expresses gratitude for our ability to manage ourselves.
Other teams worry about "sprints", quality is eschewed in favor of scrambling to meet arbitrary deadlines, and features don't get delivered on time anyway.
Whoever manages that team you better treat them to a great lunch once in a while as that sounds too good to be true. I've made dozens of attempts to constructively head off problems and concerns, or call out productivity flaws, or make subtle ways to how we do the whole Agile thing and every time it is met with dismissal, denial, or even nihilism by management who say its above their paygrade and nothing will change.
do you discuss why no work is being done?
Same here, and we even do relatively rigid scrum, but the key is that we also review the processes constantly and cut or change stuff that doesn't work for us. Yes agile can suck, but it's by no means inevitable.
@@TheBswan sounds toxic
2:15 The reason for this issue of Agile "In Practice" falling apart is that it's a Management Problem being solved by applying changes to Not Management people. Developers would just develop using Go Horse and get things done. But management would be lost and lose a lot of its purpose in that model. So Agile is the method of making management relevant to the level it always thought it was.
The international large enterprise I work at introduced both Agile (in the form of SAFe) and "Software Development Process Landscape" at the same time. These processes are so detailed that they even tell us how to write commit messages and how many times in the day to push our code.
Yah, go figure, it's all been massively downhill since that.
Holy moly. I feel like the tools around agile in the end got used for what management wants more and more control and nothing else.
How do they expect people to deal with this?
And my condolences to you.
15:04 I write tests at the module level(not units), all tests limits their calls to a central facade that sits in front of the module's classes.
After writing a parser for a DSL. I told the team that, the best way to learn how this works is to change or comment out code and see which tests fail. You're also free to refactor as long as the facade remains intact (which means no changes to the tests), if the test suite passes then you have not broken anything.
I have said it before and will say it again, managers have to be outside of the team and it needs to be run by the developers, and QA - if your team has one, and they need to have the developers to buy in to the work and they give the timeline. Once management is dictating that timeline, it isn’t Agile and is just a reimagined Waterfall and it will fail. I worked in a team that did control the process and did meet the our epics multiple times in a row, and the manager said that was the first time he had seen a team do that and that confirmed that the process does work when it’s not management really controlling it.
When the team runs the team, we would cancel stand ups when it didn’t make sense to have them, but retrospectives were always required and was highly encouraged to attend - this would then require actions that must be taken by the next retrospective and did result in improvements in the process. Planning poker ended up being very useful and we had a great time making sure that the requirements were clear and complete during this time, and this had to be clear to everyone.
Velocity, planning poker and the rest is all Scrum or Kanban stuff. Agile says teams should reflect on how their are working and iterate on their process to get more productive. Then some other people started writing books about "How to do Agile", making up stuff like Scrum.
I still wonder what the alternative is. Not the alternative to "agile", but rather: Do you seriously think that the problems with "agile" go away without "agile"? Or were introduced with "agile"? What is the alternative reality without "agile" that is better than "agile"?
Iterative Waterfall.
It's basically everything that the corporate world needs. Stable releases and deadlines that allow for planning for things such as a marketing campaigns or financial predictions.
But it uses the evil world - "waterfall" - and no self-respecting developer wants to work in 🤮waterfall 🤮.
Holacracy
@@James-gm9cs Minus points for not even reading my post.
Sounds like the worst alternative. The problem isn't heirarchies nor does holacracy do away with them, the problem is rather what happens when the size and scope grows beyond what the person in charge can handle. A holacracy just introduces the exact same problems that comes with "agile".
@@JohnDoe-sq5nv I'm currently working in an organisation that's struggled to implement a good change management structure due to managerial/executive-level bottlenecks. The whole point of a Holacracy is to remove managerial beauacracy, empower those who know what they're doing to make decisions, and work in cross-functional teams. It's a principle I'm trying to push to implement where I work. Because once we can do that and we can make the decisions we need to, then we can implement agile correctly, make quicker decisions, and increase our capacity to deliver high quality change.
Scope increase is only a problem where you have process bottlenecks that can't be fixed by adding more resources to a project. In my case, hiring more devs or pm's or ba's won't fix anything because the managerial bottlenecks built into the process will always limit how much we can do.
@@James-gm9cs >The whole point of a Holacracy is to remove managerial beauacracy
And it doesn't. Because in a Holacracy everything will need to be alligned to the bigger whole anyway thus you will never get away from the same problem. The real problem is that the company is too big for its own good.
This "no true scotsman" thought terminating cliche needs to stop.
A thing is, what a thing does. If you think you are/are doing X, but are in truth doing Y, you're Y.
you're never safe with SAFe
Boeing practices SAFe
SAFe is not Agile, despite having "A" in the name. It's a process above individuals or interactions. It's fundamentally against even the very basics of Agile. If you think SAFe has anything to deal with Agile, you clearly *never* read the Agile Manifesto.
"Creator of _____ doesn't like what _____ has become." Happens every time.
Sometimes it's because the thing has evolved beyond the scope it's original creator envisioned
Sometimes it's because the creator was and remains just straight up wrong
See: Graphics Interchange Format
He should bring that up in the retrospective meeting
Nobody examines the problem domain in the beginning anymore; the WHAT of the program is kicked down the road as technical debt to be solved later. I blame "cloud enablement" and ransom note architecture. Literally architects throw-up a diagram with AWS service icons linked together with arrows, quite proud they have it in Miro, but nothing else. ALL of the heavy lifting is tech debt that gets kicked out until it's time to deliver the product and then the team turns around and goes, "Well, we're almost out of time, which of these features do you absolutely need?" Terrible.
So what are you working on? An accounting system? A multiplayer game?
_I don't know, that's BDUF. We do agile and I've only been here 6 months_
@@TheLucanicLord I'm really glad I'm not the only one "seeing" this. The people propagating this are always so confident in the success of their terrible code that never scales, never does core stuff the client needs, barely addresses any data concerns other than storage and performance? "Hey, if it's slow we can just pay for more performance, it's serverless!" I thought I was going insane
Thriving Technologist here had a good video on how the Agile Manifesto was written and used to mess up the point, making it about "going faster" rather than SDLC agility.
I had a VP of Engineering who had no clue how to do agile, how to code, what the product should look like, what the product was, the state of the product... pretty much everything. That was why I (and 5 other senior engineers) left within months of each other. It was so bad when there was an actual dumpster fire outside the office we all pointed to it and said "look the physical manifestation of our company"
The cure to agile is to get all the C-suits to adopt agile and scrum for a 2 week sprint for all their stuff
2 days in and they will yeet that shit straight out the window
in mountaineering the glare is substantial especially on glaciers so you use the side panel to block the sun reflection off the ice/snow
Seeing this first picture I'd LOVE to see Prime do a video in the style of Peter Zeihan's hike videos
4:00 yeh its literally that. im 51. before agile it was a mess too. as i was told early on... head office never blames head office for being over budget / late / poor quality. back in those days people were just assumed to know what they were doing and there were long times before any feedback could be introduced to affect any changes. changes were usually rolled up into a new project.
the solution? management consultants to come up with a saviour plan. agile does have some great concepts and i love MVP. if the answer is no, dont be afraid to say no. alas agile is used by managers as a buzzword orgy. where are the checks and balances for management in agile? there are plenty for engineering. when things go wrong management always double down on more management and more process.
The main issue with Agile as per the manifesto's view is that it implies something quite nice and simple, but quite practically unfeasible. Cooperation. And much like the prisoner dilemma, while it's mutually of best interest to cooperate, in practice everyone is lining their ducks to be the first to fsck the other guy over. It's the time honored "permanent retaliation" strategy. Sane minds would point out that it's also the same thing as Mutually Assured Destruction, but hey...
This obviously makes the "agile works best at startup" point quite relatable, because its a smaller group of people, that usually like working together and while they might differ on subjects, they WANT to cooperate. As the group expands, it becomes every man for itself, cooperation is gone, and here we go...
p.s. this is the same for business/clients. Both the startup and it's first clients are more willing to cooperate, because it mutually profitable. As the business expands, you get more and more clients, who aren't all that friendly, and in turn you become more unfriendly, to mitigate risk. And... here we go...
Tribal knowledge is tricky, and worst of all hard to quickly propagate - one colleague left who was responsible for maintaining sharepoint integration, a week later he was rehired part time to work on emerging issues with sharepoint
Agile hinges on devs having autonomy. It is ruined by management who does not want to give this autonomy and turn scrum etc into a progress report.
After everythings a progress report the very essence of agile is gone and its just better to not have agile at that point.
Main issues with Agile is mangers, who don't want to understand development process, but want to have full control and understanding what current state of the project is.
More that anything else it's unwillingness to have more than one plan and always trying to plan specifically for most optimistic outcome possible.
That inevitably creates failures with not spare time/resources to adjust to them, which in turn compromises the whole project. Instead of accepting reality of impossibility 100% predictive planning, managers keep looking for instruments to increase control to achieve it. This is also might be a reason to avoid nuanced understanding of development, because nuances describe incompleteness of available information, which in turn does not allow for hard planning.
I started a three day fast this morning. Thank you for this message.i'm 47yrs old $73,000 biweekly and I'm retired, this video have inspired me greatly in many ways!!!!❤️❤️
Hello, how do you achieve such biweekly returns? As a single parent i haven't been able to get my own house due to financial struggles, but my faith in God remains strong.
I raised 75k and Kate Elizabeth Becherer is to be thanked. I got my self my dream car 🚗 just last weekend, My journey with her started after my best friend came back from New York and saw me suffering in dept then told me about her and how to change my life through her.Kate Elizabeth Becherer is the kind of person one needs in his or her life! I got a home, a good wife, and a beautiful daughter. Note: this is not a promotion but me trying to make a point that no matter what happens, always have faith and keep living!
@@marybradleyblack-fThis is a definition of God's unending provisions for his people. God remains faithful to his words. 🙏 I receive this for my household
Alright, I'll leave her info below this comment
+ 1
Agile done right is fantastic. Currently we have two extremes with product management on the one hand with their mutated version of agile, Vs dev teams which never want meetings or recording tasks on any level.
I think there's no better proof of that than SpaceX, which uses at least Agile inspired strategy for its iterative design process. They are the apotheosis of move fast and break things
As somebody who worked on the UML 2.0 standard, I totally understand where the original agile people came from. However, what they did lose sight of is that after a certain point, you actually need more and more structure. Yes, it is slower, but it is way more likely to get you there. The current problem is companies want the low failure rates of structured development but with the high risk timelines of agile projects.
The hard part to accept is that nobody will be happy with development methodology that works on a large scale. Developers will regret the time spent on documentation and shoring up shared knowledge for the future. Managers will regret that there still are no real metrics to measure or dials to turn to "optimize output".
Most of the people putting together frameworks these days just don't have the discipline needed to actually design something good. They don't need it, they can just release the next version after next to fix things until developers look for the next shiny thing to save them from having to just make boring, understandable and maintainable code.
And I don't blame them. Nobody wants to just grind for 50 to 60 hours and beyond. Which is why agile had the 40 hour work week rule. Which is also wrong, it needs to be 30 hours of actual work and no more than 10 hours of overhead, with the goal of making the overhead go away.
But, the pay is still good enough and capitalism being what it is, people will still grind themselves down in programming jobs. Refusing to organize to prevent the worst abuses of companies (you know, massive hiring and firing cycles, outsourcing, abuse of H1B workers and so on) because they think they are special and unique and are just one gig away from never needing to work again.
you are absolutely correct
I think we all misunderstand the original agile people. Agile is a good strategy to maximize money gain in short term and run away before the ship sink without taking any form of accountability. And this is exactly what they want.
This whole 286% article was to promote book...
You should hear also another guy who pushes agile through whole organisations not only developers Allen Holub ("No estimates" video)
Allen is a snake-oil salesman like the rest. He just panders to the developers and repackages agile/scrum into ceremonies with new names
dave farley looked at how the report was done because it did not make sense, and totally ripped it to shreds for bad methodology.
it was a report done to produce selling points for the book.
How many story points will it get me to watch that video
The biggest problem is OKR's and accountability.
We can'teasure A so we measure B and hope that also kind of works.
I used to be in management at fedex. and I can flat out tell you that the difference between a good manager and a bad one is very clear. let the people do the work, verify the work done is up to standards and provide advice and help when people are struggling. but above all, don't get into the way of your workers. if your stopping them from doing work and their work is up to standered, why the hell are you stopping them. that's wasting your team members time. that being said, as a manager you still must verify the work done meets standards and part of that is, let the crew know what the standards are, be available to re explain them many times over. and be able to have your time wasted with stupid questions, cause they are not stupid for the people asking you about them. that's basically the core of good management. right then and their.
"Startups don't have tech debt". Like chat said, they only have tech debt. What they don't have is maintenance of a long running mature product where people have forgotten why 80% of the technical decisions were made.
Scrum effectively prevents me from doing what I believe is right in the moment, in favor of waiting till I get approval the next day... And if it slips my mind the next day? Well, bye bye doing what's right.
23:51 I am very curious in what this is referring too. I have not encountered any class specific hate. I would love to hear the argument those people make
I work at a start up that's been on the market for about 9 months and I've been here since the first month and you are right on point everything we wrote, we wrote just to get the shit done, we started refactoring some things but we are still writing 5 times more dumpster code than we are refactoring.
You basically called us out there.
"Management, fundamentally, sucks and they will destroy anything that is successful." ROFL
Socrates never wrote anything down because he was convinced that if you write things down people will missunderstand your point and just stick with your practices. He preferred to just walk around and speak with people in order to keep a productive conversation going.
Aristotle did write a lot down (although much has been lost) and he did improve our thinking in major ways. Western civilization owes a ton to him as well! Unfortunately he also had some wacky ideas and because they were written down and Aristotle was so respected they became codified and possibly kept Europe in the dark ages longer than necessary because nobody dared to say that the great genius was wrong (in some areas).
TL:DR - learn from the masters, but don’t treat them as Gods and don’t keep (all) their practices if they don’t work for you. Their general approach might be useful but most likely not all the details. Stay “Agile”!
Mid to small companies with trusted and skilled engineers can do agile effectively. They have enough trust, and they have light processes that respond to their needs. It's when the company grows big that everything falls apart. Suddenly there's a need to perform in front of investors, the management hierarchy has grown enough tall and wide that the top doesn't trust the bottom anymore, consultants are hired and cumbersome "agile" solutions are sold.
A lot of times, teams come to us with with result that they want. We stop them, redirect the conversation to "what are you trying to accomplish and do you have any constraints"
This is infinitely better than what they were expecting, because we don't allow them (and by extension ourselves) to shoot themselves in the foot
We plan for the future, and make sure we aren't cornering ourselves too badly
creator likes agile, he doesnt like how we are using it.
This isn't agile means now though. The business twerps have hijacked it.
Its similar to creator of rest doesn’t like how we use it
Creator's planet is infested with product managers.
Same for creator of capitalism "dang it guys you arent supposed to use money to buy laws'
The Prime doesn't watch shitty TV, he watches Shitty Coding.
Agree so much with tribal knowledge. I built a majority of the multi year project. Colleagues came and gone.
They are able to eventually debug to an issue but I know in my guts exactly which line of code is causing that bug that appeared on the bloody demo to stakeholders. That shits my baby even tho I hate it's living guts.
I've seen agile work and work VERY well. However, it was only at small startups because we were able to actually be agile. Lots of very close collaboration with everyone.
Once you go a an existing business, the business processes are somewhat antithetical to agile process. So the business is always trying to push software creation to be more like business process. So the question comes down to who determines process. If you let the business do it then you're not going to be agile.
1:55 technically by that definition, all companies are agile because all companies are teams of people each with their own bespoke systems, rules, and processes.
I know no one will answer this but, how can someone get to that somebody Prime mentions at 19:10 ?
Not even mentioning how it turns into Waterfall Scrum.
These glasses are for alpinism. In high altitude long contact with ultra-violet sun rays can give you "altitude blindness".
I don't use Agile...I use Redux.
You have to consider the incentives outside of these 'agile' feature teams. Maybe there's not always an incentive, or even priority to truly optimise for outcomes and productivity, but safety and predictability is the priority. Devs won't have this view, but companies need to report their own version of reality, and it's easier to abstract reality via Agile process
Businesses want uniformity in process so they can build reporting around it and optimize it. Unfortunately they are optimizing a turd.
Love the last sentence 😂
I'd say the Rafale jet was developed in an agile way over the course of multiple decades. It's got its most value-added feature first, which is to fly, then they added more and more military capabilities to it, slowly, while the product was already used by the army.
The F-35 development was an enormous V-cycle since it had a enormously ambitious spec from start, and flying flawlessly was a late-completed feature.
13:10
Yeah this isn't "research". The team that did this "research" clearly doesn't know how to do research.
You need an amount of people in your dataset proportional to the entire set of people possible.
In the case of software engineers you want to ensure you have a balance between age groups & location, not just English speakers, but also include mainland Europe and maybe Asian / South America. And at least 10000 participants(more is always better). And you want multiple measurement times, preferable at least an entire years worth, so a survey once a month or twice a month. And without fixed dates, so dont' do every 20th of a month, it should be a little varied and avoid Fridays, Mondays and dates just before or after holidays to avoid those "special" days from influencing how people "feel".
Jon Kern is the love child of Dr. Disrespect and ThePrimeagen
ikr
The only thing that dissapoints me: even if I 100% agree to 95% Prime says, that doesn't mean that we are right. Totally agree to the video btw.
claiming to do agile from within a waterfall business is just waterfall without the upsides
8:10 -
26.9 million
Software engineers form a noticeable part of the workforce around the world. There are an estimated 26.9 million professional software engineers in the world as of 2022, up from 21 million in 2016.
questionable statistics
ever wondered why software is broken ?
24 October 2023
This data ranks the top 100,000 names from the more than 8 million scientists considered to be active worldwide, taking into account 22 scientific fields and 174 subfields.
Actually Agile and Scrum works there are company who do it right the problem 80 to 90% do it wrong. This what my PM trainer said who works also as a company consultant. I have found multiply RUclips video which came to the same conclusion . Web Cody also made a video who he tells how it for him and the company he is in it works. Inheritance good luck to get away from it HTML is inheritance until the root document . In general its okay when you know how it works and you know the problems and don't over do it.
It comes down to the project management. Agile must not be seen as a religion!
There are cases, where waterfall is the right way, sometimes one can do an agile light is the right fit. It is about the specific project.
I think there are some good ideas in there still: work incrementally, produce something working often, don't plan too far ahead, implement fast (automated) testing, have a trunk based version control strategy, be on good terms with the customer/stakeholders, establish friendly and collaborative team dynamics, don't rely on abstract stats about teams and people.
Then there's a bunch of ritualistic meetings, scrum masters, jira stats and other nonsense. This allows companies to call themselves agile while doing none of the good ideas in there. I work in sprints. This segments the work, but since we don't release at the end of sprints is does little to make us work iteratively.
Fun game for when people start talking about charts and agile. Try and sneak discussing the dot product and cross product into the discussion and keep a straight face. Bonus points if you can make project managers do a heap of this as part of the regular process.
If successful you can trick the project manager into writing a 3d game engine by the end of the project.
I don't know if prime is going to talk about or defend the manager's point of view since there is a reason why those companies eventually all bow down to managers. There is a reason why managers is actually stuck in the middle, the good manager and bad manager isn't that different. Being technical doesn't necessarily makes it the manager doesn't need certain metrics to protect themselves and also satisfy its own existence.
No true Scotsman
Count Dankula: ...am I a joke to you Mr. magnificent mustache man?
If I had to play devil's advocate, most companies have an IT department as a center of cost to support the main business, and because IT engineers are expensive, we need to provide metrics to justify why we are paid so high. So those corporative methodologies because a necessity for us in order to provide those metrics and to show we are doing our work.
Snowbird is a nice place. I've only been there in the summer. You can hike in the mountains. And have a hotel room waiting for ya. They had a convention there multiple years. That's why i was there.
"Multi-level inheritance is the devil" lol and amen
Agile is mostly used to micromanage
My teams have one, sometimes two, developers who know exactly what they are doing
All that is necessary is a meeting with the business owner to explain their requirements
Prime has me picturing chat in bed gently whispering sweet nothings in his ear asking for him to dunk on Agile.
I feel like project managers and middle managers like agile because its something they can do and get technical and nit pick about. it always seems to be non-technical people who spearhead it and run the agile meetings / standups. when in reality its supposed to be for developers only with NO managers or project managers. yet somehow those people always end up running the scrum and turn it in to a spring planning / assignment of tasks meetings. idk why agile is this whole special concept. it could be said as just "we have a weekly meeting to assign new tasks and track progress of the current tasks"
If we as humans were capable of planning that far into the future we wouldnt need agile in the first place.
Sometimes the best way to do something reveals itself in process and pre-ordained protocol will always get in the way of that.
This is funny. I had my mid-year 1:1 with my manager, and for my development opportunities, i mentioned i want to get my PMP and they recommended that i look into SAFe Agile certification instead
Those are tmux sunglasses with side paneling.
I honestly don’t believe that there’s anybody in my team who is incapable. Sure, there are some people who are more lazy than others, but they are capable. Maybe I’m the incapable one?
I wrote the (scrum/agile) software development process for our company, and it didn't include any of those meta-level topics. No waterfall, no burndown charts, no tracking. I don't even know what CI or STD means. It's just the hands-on stuff, so new employees can read it and instantly understand that we basically do the things they learned at university and know which level of information is needed at which point in time. This way, the company can act instead of react. We had stuff like which documents does the service technician need to check the instrument, or when exactly do you have to start taking notes if you change something. You know... because people have to take your stuff and run with it. Isn't that the most important thing?
Agile at my workplace (30 yo company) means: no planning, no discussion in the team, no talk at all about the project except that the boss comes in in the morning (who has no clue about Software engineering) saying what he thinks is good for the project and we should make it work now. No matter what. Oh yes: "today is demo day, so make it work and stop everything else". And a senior that also worked in this company for 30 years, never used a modern framework with state management and is constantly nagging about it (we use flutter. Yes actually one of the rare cases where flutter makes sense, so at least that was a good decision). No architecture, no lifecycle management, no nothing. That is in their eyes agile.
Please rate my workplace where 0 is hell and 10 is a devs dream.
edit: pushing to prod is "hey, can you push to prod? thanks dude."
“creator of the nuclear bomb doesn’t like nuclear bomb”
One of the great ironies of my life was seeing Agile morphing from a developer-friendly methodology into a set of iron chains holding developers down and endlessly wasting their time, because nobody understood what it actually was and they went with their gut instinct, which was to exert more control over creatives instead.
They learned knowing reqs lead to more successful outcomes? No shit.
This deserves 1000 likes
You cant avoid knowledge silos. And its a good thing. You should still try to mitigate them with trying to walk people through them and documenting where possible but its impossible to get everyone on the same level of understanding as the "maintainer"
Where is my parka? This take is so cold it's winter in July
Embrace "Watergile" , be Nimble and go with the flow. 🙂
Even waterfall was bastardized. The original papers talked about iterations and just use your fucking head. Of course managers come around say: "so you're telling me you know when its done?"
No ending quotation means the next paragraph is still within the quoted text
Wind blockers on the sunglasses
Agile is one of several methodologies to choose from. How is it possible that it happens to be the best fit for such a diverse range of companies? I'm asking the same question of cloud. There's a lot of adopters who only signed up because their friends did.
Non-tech people who are directly involved in development process or decision making process on lower levels are the real issue. I think that even scrum can work if ran by engineers
costco prime is wearing "glacier glasses" and yes it's to protect your eyes from reflectance off a bright snowy/ice environment.
Essential problem is this:
Considering quick and easy movement as something to do with projects and project managers
Process is just a shim to fix communication problems. Since we do this with every process, maybe we should agree that there is no process that solves for the problem of perfecting communication.
This dude looks like dr. disrespect
Thought I just wasn't white enough or had never been anywhere with enough snow and sun at the same time to need them, but even prime don't know what they are.