Hilarious!!! Guys, we love your comments. It would be great to hear more about your experiences and opinions. Please participate in our BIG AGILE SURVEY: www.striped-giraffe.com/agile-paradoxon We are happy to share the results with you in the end.
No "final comments" at the end of the survey? I struggled to answer, because it was unclear if questions asked more about current situation or in general. Also want to add that PO and SM are the roles who (from my experience) usually make or brake things. Have a business type person who favors a whip to make people go faster and not care much about quality take both hats and it'll be horrible no matter if it's theoretically still agile and adheres to all the things a good scum project does.
We had remote "standup meeting" via Google Meet where people actually required to stand up by the Scrum Master. And a supposedly 5 minute meeting dragged to 45 minutes because someone can't stop talking about their kid.
You are not an avenger because you carry a hammer or have green skin. To be a facilitator you need more than a role title. BTW: if Scrum Master facilitate the Daily Scrum, then the other teammembers don't. Is he fostering self-organization with this behavior?
The best part about an agile sprint being 2 weeks is it isn't actually 2 weeks, it's 1.25 when you subtract all the bullshit agile ceremony meetings from it (planning, playback, standups, retros). Therefore you are asked to estimate work for a shorter period you are given, and everyone acts surprised when things aren't finished. Genius.
How long do you expect this to take? Roughly 2 weeks. So if we put you on 12 hr days, 7 days a week, you will be done in about 1 week and 2 days correct? No, if I work 12 hour days, then it will take 2 to 2.5 weeks. How do you figure this? Because I am human, and with less downtime, I will quickly become more tired, and make more errors. I will be much more likely to be hungover and therefore perform sub par. So my underperformance combined with additional hours of troubleshooting means working 12 hrs per day will actually slow the project down, not speed it up. At best, it will complete around the same time as staying on 8 hr shifts. We disagree. Overtime is now approved (and mandatory) Thanks for listening.
I feel like any estimation at all is just fundamentally incompatible with how software works. You have no idea about all the bullsh.t you'll be dealing with until you're actually there. Trying to discuss it in a sprint planning meeting is pretty much just empty talk. And because estimates are so inaccurate they mean practically nothing. But business is all too eager to take it as a promise and make a deadline out of it, which will put extra stress on the team and ensure your software becomes shitty, because devs are focusing on meeting deadlines as opposed to delivering quality.
@@spawacz105 it's more like evolution going circle. In some time, Waterfall 3.0 (v-model already being Waterfall 2.0) will be invented, as a reaction to Agile's shortcomings. Then, back to Agile 3.0. And so on and so forth.
@@spawacz105 the core idea of agile is to adapt and change what doesnt work for you and keep trying new ideas. So as a concept its reinventing itself. There is no need for an agile 2.0 but hopefuly working agile will change and improve a lot in the future to fix the issues. Imho the biggest issue isnt the philosophy but bad implementations and no idea or no will to fix it.
After finishing the survey I'm redirected to a german page. Someone failed their QA test-cases. Don't worry, it can be carried over to the next sprint since it's not a blocker, but this will impact overall velocity.
Agile was invented by developers with an average work experience of 25 years. If you, your Organisation, thinks you can just do agile - like inviting 20 junior cooks to a kitchen and expecting to build a great restaurant - you’ll fail. If you don’t have that 25 year senior crowd, sit down and plan things through for more than two sprints and don’t “just agile it”. New restaurants hire a very expensive chef for a few weeks to figure out the initial recipe that the 20 juniors can springboard off. Not the other way around. In tech… chefs are called for mostly only when its too late. That’s the real paradox.
@@mazercorehe's not putting down cooks any more than he is junior developers. The analogy works. 20 cooks being directed by a chef on staff is exactly what he meant by having a senior crowd around to guide the junior developers.
As a senior dev, I've made a lot of money pissing on agile fires started by lunatics who thought they could out-code me. I love it. Keep being agile, it'll pay for my yacht.
The way that you describe it sounds like you dropped licensed (certified) practices in favor of being flexible and adaptable in your thinking and approach.
Nice Adam, you applied the first Agile value statement and, given you are practical, I assume you deliver working software, collaborate with your customer and respond to change so you might deny it, but it turns out that you are as Agile as you can be 🤣
Real question, what do you do when you do a practical design that is amazing and elongated, but then takes months to execute, and then falls short of addressing the user needs, or the user (after interacting with the product) realizes they have needs they didn’t think about before? Do you go back to the drawing board with your next practical design? If so, how long are your lead times for each of these cycles? Long lead times = a lot of $ invested in product capabilities that don’t serve user needs and therefore don’t have an ROI (aka waste)
Here from Programmers Are Also Human :DDD So true... Agile can just feel bothersome sometimes. Do we really need to do daily standups? What use even is an agile coach??
This video is equal parts brilliant and depressing. I've had so much time wasted by Agile Coach cult leaders pushing for their own dogma without any regards to how it would actually be implemented (::cough:: *SAFe* ::cough::) And then on the other hand I've worked with ADLs who truly embodied the spirit of _kaizen_ and were tireless advocates for fixing systemic problems in our working patterns... who then got ignored by the people with actual power, to the point that my company *literally fired* all the ADLs (while still expecting individual teams to follow its bastardized version of SAFe).
@@johndoe-xk1je Agile Delivery Lead. The term "scrum master" is being phased out because the role is supposed to embody a servant-leader, not a boss (the term "master" is generally being phased out due to its ambiguity between denoting expertise in a subject vs. authority)
@@GSBarlev It's sad to see how fragile people become as to complain over mundane things like the word "master." Authority and competence still exist anyway.
I was a moderately successful scrum master when I was also test lead and was supported by a project manager who put engineering first and shielded the team. Now I'm discovering the joy of the agile coach role, where I want to shorten deployment lead times and harden tests so that developers can get feedback, but my stakeholders want to see a SAFe rollout and to cargo cult automation pipelines while at the same time insisting nobody needs to draw the value streams or visit the teams
I can't help myself spelling SAFe (un)SAFe, because it really is. Big company with way too many so-called agile coaches and "Release Train Engineers"...
@@ToomuchNoiseToday its based on my 19 years in the industry, and comming from pure waterfall, through loving Scrum, through being sceptical, and then hating all that was created around Scrum. At first, the values were right, the first Scrum Masters were actual developers and engineers, so at the least - they understood that the ACTUAL value is only the thing you produce - code, how efficiently you can produce it and how close it is to what the customer and users need - thats all. Nowadays, you have "coaches" and "facilitators" that have come from far away from IT, have no background or understanding of what problem "agile" movement tried to solve in the first place, and just try to keep their jobs - which is being just a COACH or a Psychologist. Im not saying some companies dont need those roles, just like some companies probably need a Cook if they have a kitchen and serve employees dishes, but its a very very specific case, and should not be an industry norm. At the end of the day, the team that does ACTUAL work has all they need to make the right calls, and how you suppor it is by hiring smart leaders, and setting a right balance between ownership and guardrails (Im not saying this is easy, but it's the role of CEO, CTO, VP, Directors, Tech leaders and whole leadership organization roles, NOT some ephermeral extraneous Scrum / Kanban Coaches).
Part of the problem is realizing it's a tool and not a magic bullet. One of the points emphasized in Agile is that refactoring is cheap, so we will build out a model and then just change it as needed. That may work for functions and methods, but it does not work for data. It's cheap to refactor a stored proc, but try refactoring a table that already has a billion rows of data in it that take several gigs or pterabytes to store. Management loves it when you tell them that you will have to take the production database offline for a week to implement the new change.
I think for a good number of companies the video got the development over the past 20 years wrong: Agile was once (back in the days of the manifesto) a grass roots effort to make life for developers better, but in many companies it has been perverted and twisted from a framework for collaboration and self-organization to controlling and pressuring development teams in a fortnight cycle. (partially stolen from a HN comment)
Agile, XP, even Scrum: the developers should be self organizing. Project managers: well what about my job? Or more broadly: most managers are still stuck in 1940 factory management mode. Everyone is a cog, processes are decided top-down and every resource (which comprises human ones) should be used 100% for better efficiency. Flow, lean, theory of constraint? Dunno, don't care. And even if they learnt about those 80 years of progress, they'd still have to understand intellectual jobs don't have the same constraints as physical ones. And that's a huge step for most of those mofos. The only part they sure decided to not keep as it was during the old times was offices. They sure jumped on any excuse to not have people with personal offices.
@@ArkhKGB That's right. All those managers need jobs. It is easier to be a Scrum Master do agile voodoo, than to get software engineering degree and start coding.
I spent Friday sat on a zoom call looking at yet another new ways of working slideshow presentation showing me some form of Scrum, with a fortnightly “cadence” and how we’d be using Jira even more. I’ve had to listen to this same old stuff for over a decade, rehashed over and over, by different people, as my teams and managers have changed. Endless discussions. In all that time I’ve kept asking myself the same question. “What is it these people actually do?” I know I’m being dismissive when I ask that, but I do really genuinely wonder sometimes what a lot of these people are doing in relation to the end product - and even if they have any input at all, or add any kind of value to the process. I was in a zoom call once and out of the twelve people on it there was one software developer who was actually making the thing being discussed - and that was me. Maybe there was also one UXer and a Business Analyst, but the rest, I have no idea; people with manager in their job title. It seems there is a whole group of people whose job it is to just talk about stuff.
Oh wow. "Agile clown" sounds like a clown that moves in a dancing way, like this guy in the video. Was it Dave Thomas who said "calling it agile manifesto sounds like a book that jumps around"
"Guys, actually you are doing it wrong. It can ONLY work out, if we follow each. single. rule. from the SCRUM guide! First we need to estimate whateverwedontevenhaveanideawhatitsabout in units of arbitrary virtual stroy points..."
There's always gonna be grifters, and the best grift is consulting, followed by selling a startup, followed by "coaches"(followed by oil/arms industry lobbyists and middle management). By the way I am starting a consulting business, so give me a contract. I have actually no idea how you do what you do, but the difference I offer is I'll listen to the people building it, before telling your exec how to do his job.
Thank you! Recently left a project where there was that one guy who was the SM and PO but saw himself more as a product master and scrum owner. Project had so many "agile smells" it was nauseating. Any attempt to improve things were met with "Nah, I just don't see it." or dismissal of another flavor. Problem is, with each project team I work on as a freelancing developer, somehow Agile and Scrum just seems to get worse and worse over the years. (Of course, it's not so much the framework or the processes that changed, but the people implementing them, "leaders" once again not trusting the developers and trying to squeeze a maximum of "performance" out of the team)
I think initially, Agile methodologies were done only by people who really wanted to do them. Now "Agile" means something like "best practices," that is, the things you're supposed to do no matter what. So everyone says they're Agile, even if they aren't. The part about trust is underrated. I wish the Manifesto authors had put the necessity of trust right at the start, instead of taking it for granted.
This is so accurate, its funny. We have been trying to communicate this. So happy to see we are not alone. I am not even IT. IT is forcing Agile on Functional Process Re-Engineering for a brand new PLM system we have to work. Imagine the overhead on stories for a 2 week sprint to cover the Art of the Possible.
Agile doesn't enforce any rituals - the only thing Agile encourages is a retrospective. It doesn't even have to be a meeting, it can simply be an ongoing effort to improve the workflow, like building a deployment pipeline to automate the manual work, or simply reflect on the experiments in your team. All the other things like Sprint Planning, Daily Standup, and so on, are only in Scrum. Individuals and interactions over processes and tools tells you that if, for example, the Daily Standup (a process) doesn't improve the interactions in your team, you drop it. If it gets in a way of the actual work, drop it. If it makes the team miserable, drop it. You can reflect if a process or tool suits you in a retrospective. Simply getting negative feedback from your team about some ritual is enough to not continue doing it. For that, you need an autonomous (self-organizing) team - one that can self-decide about its way of working, which is another thing Agile mentions.
@@sewera.account For that you need open minded and democratic leaders. In companies lead like a dictature, you can be miserable all you like, if the company's finances are not yet highly concerning, the will still require you to follow those useless rituals.
@@sewera.account Maybe agile does not enforce it, but it doesn't matter because corporations, projects, clients and your scrum master does It's like they don't believe we work outside of meetings, so they want to see us on countless calls
The problem started when "agile" was taken hostage by managers who then made it mean "many waterfalls in fast succession". Guess what you get out of such a cascade: just gist and damp air.
@@tiefkluehlfeuer waterfall means 30% planning, 30% development, 30% test and 10% unforseen. Agile means 80% development, 10% planning and 10% validation. Huge difference in mindset too.
In my experience, the problem with Agile is the same as the problem with any other method/work form/process/technology introduced to the world of IT in the past 50 years: lots of very vocal people with too little understanding of the concepts, implications and repercussions involved latch onto it as a divine revelation, hailing it as the new black, and the silver bullet which will once and for all solve all their problems forever, as long as they embrace it wholeheartedly and in full, with no questions asked. This seems to be some sort of disease in the industry, a complete inability to step back and ask whether this is truly the best approach in all situations. An unspoken assumption that all companies are the same, all projects are the same, all teams are the same, and all developers are the same. Everyone always seem to be looking for one-size-fits-all solutions to any problem, and are surprised when the latest buzzword doesn't just magically make all problems go away and make everyone work with 100% efficiency.
Thank you very much for your comment. Very well observed and you are comming to a deeper layer of understanding what is going wrong in so many areas od the IT industry. We are collecting a lot of your feedback currently to create a new story line for another video.
Well said. It’s like fight club. The first rule about agile, is that you don’t talk about agile. As a PO I’m tasked with much of the planning, and if I don’t have stories planned for the next 2 sprints, it’s looked down upon. I’m ALL for planning but there is diminishing return. The best I will ever get is 70% right. So when something comes up: oops forgot this small detail, should be 1 developer few hours of work. Nope. Sorry. That will need to wait 7 days until the next sprit. We’ll put that in the backlog. Ceremonies then basically turn into public shaming sessions. I feel it, and I hear it in the voices of my best developers when, once again, they failed to assign the correct number of story points, assign dependencies correctly or any other amount of endless red tape in Jira.
@@ToomuchNoiseToday worth every penny and we should absolutely have this conversation about agile. Agile in principle is about being adaptive but instead we're bogged down in rituals, cult of personalities and suffocated to death by 'the process'.
@@LearnFrontendNow If you want to go into details, it would be great if you can do our agile survey www.striped-giraffe.com/agile-paradoxon. It will be hard to find those deep-dive results on the internet.
Explains the industry perfectly. We have lost our way. Plan for two damn weeks to implement a feature that takes two days to write. Oh and don't forget to burn down your f**king hours!
I think, if you have great people managing agile, it works really well. During my short life in company's time, I've seen "classic" project management as well as good and bad agile project management. Bad in many senses: not adapted for the team, not really understood, not really pushed through. I've seen good examples, and when it is well implemented, adapted for the team, and people are actually talking to each other, it works really. Problems mostly arise through company hierarchy, in my opinion, and people who try misusing agile project development for micro management or to force more productivity (and want improved productivity by an instant). It's so fun watching these videos and memes about it. Especially for me, who has generally made really good experiences with it. 😂
"If you have great managers" has nothing to do with agile... that's the cult mentality. Every thing went well? Thank agile... everything went wrong? You didn't agile hard enough.
@foxvulpes8245 I have zero knowledge of where the f you took any of what you said from my comment. Neither did I ever say or listed that failed agile teams haven't pushed agile hard enough (or didn't really push through, i.e., saying they're agile without doing anything really agile), nor did I mention "great managers." There's a big difference between team/product managers and people managing agile. Not only that, but I also never mentioned anything with regards to thanking agile if things are going great or cursing at it if things fail. In fact, I did mention problems arising with micro-management from certain managers and ill-adapted or completely misused agile practices. There are just certain use cases or groupings of people who just cannot work (well) in agile development, and there are, of course, bad managers and bad people managing agile. It's more of a cult mentality if you're only trying to bash against something, isn't it? Also, it's definitely way more of a cult mentality to not see the greater picture and just talk shit about ways of working instead of factoring in the people, conditions, and topics of said work environment. Again, agile isn't for everyone and everything. Some things just don't work in agile, and some managers misuse it for micro management, and some people just cannot work like that (or adapt it to their use case). And, of course, every new system/framework has to go through a phase of trial and error and adjustments to see whether it works great or not. That doesn't have to do with cult mentality or "forcing" people. Things do not have to stay the same, and new things take time to adapt and experiment with. That natural and has to be factored in. And if it doesn't work, you should always be able to go back (which some companies or managers don't want for micro management, etc. But then, they're not understanding what a framework is, let alone agile, tbh).
@foxvulpes8245 ah yes. Seeing things differently and not the way you want to see it is "conditioned." Very nice. Have fun doing whatever you want to do and work within the framework and way of working you like best. There's literally no real right or wrong, and if people are not able to argue correctly, I'm not wasting more time with them. If you don't want to see things nuanced and don't want to accept that agile actually works, it's your thing. Never did I say, nor will I ever say, that the agile framework works for everything and everyone. That's simply not true. Also, I won't ignore that some managers put in "agile" for micro management of people lol Everything else would be just as stupid as seeing things purely black and white (or throwing phrases like "cult mentality" and "conditioned responses" to someone who just hasn't the exact same view as you without bringing any arguments).
years ago my boss took me to an agile "event" (?) at microsoft R&D headquarters in cambridge that was basically a religious cult meeting x improv class. at the end we literally sat around in a big circle and people gave hagiographic descriptions of how amazing and life-changing the experience was. the event was like tony robbins style trust fall summer camp improv class stuff for 3 hours... but presumably it was all about agile (?)
I think most people who criticise agile have not worked in software engineering before agile. I've only experienced chaos, poorly managed by overworked, clueless techie-bosses. When Scrum coaches insist on ceremonies or the like, and ignore team members' opinions that don't agree with doing that - they're just doing it wrong: People and interactions over processes and tools. What they're doing is insisting on process, ignoring people's opinions and ideas. They're not coaching, they're leading. This is fine when there's a massive lack of structure in a team, but once things get going they should tune it down.
I was reprimanded by HR at a F10 company in 2008 for pointing out this exact issue when they "introduced" Scrum. People were so obsessed with one upmanship that they were spending 8 hours preparing the sprint review which they presented in suit & tie for a 2 week sprint 🤦♂
Spot on - I love agile when it's used in conjunction with prototyping and not micro-managed to the extreme. Formalising Agile feels like an oxymoron - too many bean counters focusing on velocity rather than outcomes.
Absolutely great!! Sometimes I did not know should I laugh or should I cry :-) I will share this video with some people who may really feel like this is from their heart.
I went from agile to waterfall and agile had its problems but it's still better. The problem is people who's whole job is agile process stuff and not the work that agil was supposed to empower.
This is why you need agile on the meta level! Edit: read a comment here that had a good take: The problem started when the word "agile" transformed from adjective to a Noun. You are not DOING Agile, you ARE agile in what you do.
The moment people started to write agile with capital A, the tool became a religion and the colleagues doing general managerial tasks became the priests. Technical experts usually have a very hard time believing in conceptual nonsense like this.
Here is the thing, the type of agile that the agile manifesto was looking for tends to emerge quite naturally, even in groups that have no knowledge of the theory of it, and it is surprisingly common, especially in groups of competent profesionals who just regularly reflect on their project together, as in just hold meetings once in a while for "how are things going, and do we need to change direction". The type of Agile that has been commercialised is built to be a structure that tries to force work to have some simularities with what the agile manifesto was advocating for, but do so by imposing a lot of structure that in principle is the opposite of what agile manifesto was advocating for. I remember one manager talking about "yeah we want to introduce this method", to which I asked them whether they have considered just what kind of needs they would have so they could select the right version, and oh we are kind of already working in the way that the method is hopeing to get us to look like.
as a developer this resonates, I f*cking hate production people with ideas, It is all BS! Cascade, Agile, Kanban, done em all got the action man and t-shirt. I wish production would learn something about the disciplines they are planning for, for once.
Agility is a continuum. You've just witnessed two extremities. Somewhere in the middle is your organisation's sweetspot - find it, but don't get complacent. It moves, and it's different for each project (assuming you still have projects).
There is a big misunderstanding related to agile. The agile manifesto does not propose scrum ceremonies. Whoever wrote this in the video description did not read or did not understand the agile manifesto correctly. In my opinion, as a Scrum Master, the big problem with agile is the industry of methods and frameworks. For example, you learn that you are not doing Scrum if you do not have a daily meeting, instead the daily meeting being used as a tool for the team to decide whether to use it or not. Let the team decide which tool, process and framework to use to deliver the right product to the customer with great quality.
There's an error on the description. The Agile Manifesto does not propose any Scrum ceremonies. In fact, the Manifesto does not contain the word "Scrum" or "ceremony." This demonstrates some of the big problems with both Really Existing Agile and its criticism. Everyone ignores the Manifesto and treats Scrum and its many ceremonies as the sine qua non of Agile. And even then, the "Agile" people refer to might not have much to do with what's in the Scrum Guide. Why read that when Agile is "simple"? Just have daily status report meetings (sorry, "standups") and planning meetings every two weeks where you use some convoluted estimation method that's supposedly not about time, but actually is.
You are hitting the spot. That is why we wanted to create this Video. We do not want to be the ones knowing everythng better and for sure not to propagate a new agile manifesto. We want to bring it down again to ask ourselves on how to get the work done in a pragmatic, agile and developer friendly way without too many meetings. This is an invite for a discussion. Thanks for your comment.
I unironically think that an actor who can make you want to punch them in the face is a great actor, bravo for channeling the pathos that is over-used Cargo Cult Agile good sir.
Conceptually, "agile" is doing the smallest demonstrable part of the finished project, getting feedback from the customer, making course corrections and repeating until the customer is satisfied in the end result. In practice, it can end up being a bunch of extra work that frustrates the team.
Agile by design was to deperson developers into cogs that upper management (who often have no coding experience) can replaced or micromanaged. It is a corporate buzz word slung around by the Duning-Kruger CEO class who think that if they can get 9 women they will have a baby in 1 month. It is why I left the software industry to get paid more doing way less and watched the company I worked go under in 1 year w/o me. I had worked there 7 years but I was getting flak and write ups for not being a team player about agile. Infact one middle manager actually tried to fire me. Told me I was fired and I just sent his letter and response to the program manager. They didn't want to take a side because they had to support agile.. but I was un fired. Keep in mind this was after receiving corporate awards that only 3 our of 2000+ employees received per a year per multiple years, and some awards that literally had "savior" etched in the big glass block.
Yeah. And I’ve never been less productive. Today agile is just another form of top down development with more paperwork and meetings, and less opportunity to change course. Everyone is another automaton. Basically the opposite of agile.
Been in 'the biz' for 30 years.... waterfall, agile/scrum, etc.... Here's the deal: Figure out the (REAL... ahem) problem that the customer wants to solve, and? Solve it. Crazy, huh? Always try to figure out how to break it, and then always try to make it so it doesn't break. And for God's sake; once someone figures out how to do that stuff, let them do it for as long as they want to, without forcing them to 'level up' to a point where it becomes impossible for them to know either the problem or the solution anymore.
You are making a strong point here imho. GTD is a discipline which many people have forgotten. Or even a bit rougher... get the fucking job done. But there are aspects to agile which have the potential to improve our life@work and some do become a religion. And as Agile was meant to be executed by programmers (also the Scrum Masters) and becomes evident that something goes wrong nowadays. We do not need Gurus who tell us how life looks like. I have seen agile Coaches which have the intention to solve even every aspect of people's life.
"We can stop doing and talk about doing" embodies my issue with Agile/Scrum so much Not that the process on paper is bad, but the fact that in implementation it turns what should be a simple feedback and implementation process into a series of really unnecessary meetings. I also think it gets applied on a level too small scale to really be of any additional use (like, does a project with less than 6 people really need it?) or a level so large that you start having people involved in the conversation who have no applicable knowledge or who just don't actually care (so why are they here?).
Things like this video scare me. I haven't worked yet but I'm glad I listened to a lot of talks from the originators of the agile movement, before getting a job. A few fun facts in case you're interested: - they called it "manifesto for agile software development", "agile manifesto is like you give it to people and they start dancing", "they even capitalise Agile like it's a God" - they don't like calling it agile anymore, generally speaking, because they're uncomfortable with what happened - they didn't intend to give advice with the manifesto. Some of their other work gives advice to advanced programmers, or general advice, and rarely beginner-friendly processes you can follow From what I understand there's a disconnect in the underlying context. It seems that the most advanced, most experienced software developers are extremely social. They try things out, they comfort their higher-ups when they look uncomfortable, they don't tell the higher ups what processes they follow, sometimes they even sit in pairs two people per computer like airplane pilots. Even outside their skills, they're fundamentally different to stereotypical programmers. These seem to be the sort of people who write the agile movement related books. I find this fascinating because it explains the situation, as well as what we should do about it on an individual level. And the energetic agile coach in the video reminds me of the phrase "blazingly fast". Does "blazingly fast" come from anime?
Coming from a 48 year old programmer: you can essentially ignore agile. Don’t let it distract you from what is hopefully your passion : programming. The average company will just pay “agile” (whatever that is) lip service. It’s not really important. They will talk about it. Just nod your head. And if you find a company where agile has become a cult (I’m sure they exist) simply up and leave. That company is not worthy of your talent and will likely fail. Don’t misunderstand: agile is done well sometimes and has shows value. It is well suited to mainstream, incremental, bespoke, product development. The classic example would be a web based inventory system which must evolve based on user feedback. It is not well suited to a large amount of product areas including from scratch “green field” stuff, or anything which requires any kind of formal engineering practises, such as anything safety or security critical.
Reading the comments made me feel sorry for all the people that had bad agile experiences, specially the daily meeting ones. I thought it is really hard to ruin agile, but it is really easy if done by old school project managers.
Excellent video! This is how complete idiots who can't even write a line of code have found a job in software development ... you don't need years of programming experience to work in the industry - just do a two-day Scrum Master (certified!) training and you are good to go telling seasoned experts how they have to do their job. Es wäre lustig, wenn es nicht so traurig wäre.
Sorry Aleksandar; I can understand you... but this is not a high level superficial survey. We wanted to have a deeper market insight. Only then we can do something with yor experiences and have a detailed outcome.
Bang on, nothing like salesfolk hawking 'frameworks' and enterprises completely missing the point to kill a good idea. Grug the caveman say agile values good, scrum framework bad .
If coaching is indeed a bad thing, there was apparently enough money earned with it to pay for this over-produced video. Which is btw done very well,, compliments for the production!
Ahh, 2001 - the days when Total Quality management folk (with no development knowledge at all) were bogging down teams in bureaucratic systems. Hell, even as late as 2007, One large multinational was rolling out a defect management process "with only 23 states" and were bragging about it. Of course there was going to be kickback - it was necessary, however, the kickback was largely ideologically driven and rigid - right from the start. To question or innovate the agile manifesto was heresy right from the start. Enter the education industry churning out people certified as scrum masters after a weekend course, prancing around as if they know everything about development. We went from one extreme to the other - and each time we end up with people who have very little to no lived experience with development calling the shots. Don't worry, something else will come along and so the cycle repeats. Bright shiny thing coming - get ready moths to fly towards the flame again.
Agile is like communism, everyone got it wrong and now a lot of people suffer because of it. As I heard someone once say, "the moment agile died, is the moment it stopped being an adjective and became a noun", as to say Agile != agile.
They were obviously doing Agile wrong, that's why 50 million died. We must try it again in this country, but do it correctly this time. /sark
Рік тому+1
This is one of the most stupid arguments that i hear here and there - you can use it for everything that you want to paint in negative light. Just because dictators rise to power on "communism" baners and then abuse their position to exploit and even kill others is not different from "businessman" or politicians that rise to power on "capitalism" baners, and then abuse their positions. Being in relm of politics analogies, I wonder how many lives were cut short because of insufficient wages paid to workers, while one of fathers of capitalism, Adam Smith, was vocal advocate of importance of fair pay - how that happen that in "capitalism" we forget about that and workers need to fight for that right? Could we say therefore, that because ideas are abused and people suffer, capitalism is like communism? Agile is as much like a comunism as capitalism, waterfall, OOP, or any other idea is. Just because people are imperfect, avoid understanding, abuse ideas for their own advantage is not a proof that something "is like communism"...
This is what we stand for. Focus on delivery. Nevertheless, we find some agile principles useful some not that much. One focus we do have is to bring down the amount of meetings massively in order to give back freedom to developers which imho are creative people. Whenever you disturb a creative being you are loosing a lot of output. But... we want to have your individual opinions... in order to summarize and come up with conclusions which then agian.. we want to share with you guys.
@@ToomuchNoiseToday agree! When scrum works like in the beginning, SM shields the team from random BS and PO attends all the alignment and strategic meetings so that the team can crack on and build stuff. Review and refinement sessions and a really good use of *so that...* should give all the alignment needed for Devs to make good decisions in the small
Hilarious!!! Guys, we love your comments. It would be great to hear more about your experiences and opinions. Please participate in our BIG AGILE SURVEY: www.striped-giraffe.com/agile-paradoxon We are happy to share the results with you in the end.
No "final comments" at the end of the survey?
I struggled to answer, because it was unclear if questions asked more about current situation or in general. Also want to add that PO and SM are the roles who (from my experience) usually make or brake things. Have a business type person who favors a whip to make people go faster and not care much about quality take both hats and it'll be horrible no matter if it's theoretically still agile and adheres to all the things a good scum project does.
@@morothar_loki Thanks a lot for your input!
Will you email the results of the survey? Or are they going to be published somewhere?
@@shandrio We will email it to all participants of the survey. Later it will be published on our website.
We had remote "standup meeting" via Google Meet where people actually required to stand up by the Scrum Master. And a supposedly 5 minute meeting dragged to 45 minutes because someone can't stop talking about their kid.
Then your scrum master sucks at their job. Dailies are supposed to be timeboxed at 15 minutes.
Yeah, in such a case, that someone should cut it short on daily and if needed, continue the discussion one on one afterwards.
You are not an avenger because you carry a hammer or have green skin. To be a facilitator you need more than a role title. BTW: if Scrum Master facilitate the Daily Scrum, then the other teammembers don't. Is he fostering self-organization with this behavior?
45 minutes is rough, but as someone that works at home alone, stand up is my 15 mins of socialising in the day 😅
profile pic checks out 🤣🤣
The best part about an agile sprint being 2 weeks is it isn't actually 2 weeks, it's 1.25 when you subtract all the bullshit agile ceremony meetings from it (planning, playback, standups, retros). Therefore you are asked to estimate work for a shorter period you are given, and everyone acts surprised when things aren't finished. Genius.
How long do you expect this to take?
Roughly 2 weeks.
So if we put you on 12 hr days, 7 days a week, you will be done in about 1 week and 2 days correct?
No, if I work 12 hour days, then it will take 2 to 2.5 weeks.
How do you figure this?
Because I am human, and with less downtime, I will quickly become more tired, and make more errors. I will be much more likely to be hungover and therefore perform sub par. So my underperformance combined with additional hours of troubleshooting means working 12 hrs per day will actually slow the project down, not speed it up. At best, it will complete around the same time as staying on 8 hr shifts.
We disagree. Overtime is now approved (and mandatory)
Thanks for listening.
I feel like any estimation at all is just fundamentally incompatible with how software works. You have no idea about all the bullsh.t you'll be dealing with until you're actually there. Trying to discuss it in a sprint planning meeting is pretty much just empty talk. And because estimates are so inaccurate they mean practically nothing. But business is all too eager to take it as a promise and make a deadline out of it, which will put extra stress on the team and ensure your software becomes shitty, because devs are focusing on meeting deadlines as opposed to delivering quality.
I estimate the work takes 2 days, but with agile it takes 5.
@@paaao default. you tell "manager" (or a PO who acts as if) why a thing won't work, and end up beeing persuated to commit doing exactly this.
@@PhilippBlum 8 if you count the review and retro and intermediate refinements
Each IT trend promises to be "better than the previous", until it becomes worse.
Great video.
Sounds like every new Javascript framework/library
It is evolution going forward :). In some time, agile 2.0 would be invented to improve these shortcomings.
@@spawacz105 it's more like evolution going circle. In some time, Waterfall 3.0 (v-model already being Waterfall 2.0) will be invented, as a reaction to Agile's shortcomings. Then, back to Agile 3.0. And so on and so forth.
@@spawacz105 the core idea of agile is to adapt and change what doesnt work for you and keep trying new ideas. So as a concept its reinventing itself. There is no need for an agile 2.0 but hopefuly working agile will change and improve a lot in the future to fix the issues.
Imho the biggest issue isnt the philosophy but bad implementations and no idea or no will to fix it.
After finishing the survey I'm redirected to a german page. Someone failed their QA test-cases. Don't worry, it can be carried over to the next sprint since it's not a blocker, but this will impact overall velocity.
Thank you very much. We fixed it.
Bruh
Agile was invented by developers with an average work experience of 25 years. If you, your Organisation, thinks you can just do agile - like inviting 20 junior cooks to a kitchen and expecting to build a great restaurant - you’ll fail. If you don’t have that 25 year senior crowd, sit down and plan things through for more than two sprints and don’t “just agile it”. New restaurants hire a very expensive chef for a few weeks to figure out the initial recipe that the 20 juniors can springboard off. Not the other way around. In tech… chefs are called for mostly only when its too late. That’s the real paradox.
You're putting down cooks for no reason. If you have a restaurant with 20 cooks you have a chef on staff to direct them. The analogy doesn't work
@@mazercorehe's not putting down cooks any more than he is junior developers. The analogy works. 20 cooks being directed by a chef on staff is exactly what he meant by having a senior crowd around to guide the junior developers.
Yup, witnessed multiple times. Also, long time no see! :-)
As a senior dev, I've made a lot of money pissing on agile fires started by lunatics who thought they could out-code me. I love it. Keep being agile, it'll pay for my yacht.
25yrs teaches you a lot about how to run up the clock.
We dropped agile years ago and decided to fix the root cause of the problem: actually do practical design.
The way that you describe it sounds like you dropped licensed (certified) practices in favor of being flexible and adaptable in your thinking and approach.
Hear, hear. Design!
I never heard about practical design before, any suggestion for beginners?
Nice Adam, you applied the first Agile value statement and, given you are practical, I assume you deliver working software, collaborate with your customer and respond to change so you might deny it, but it turns out that you are as Agile as you can be 🤣
Real question, what do you do when you do a practical design that is amazing and elongated, but then takes months to execute, and then falls short of addressing the user needs, or the user (after interacting with the product) realizes they have needs they didn’t think about before? Do you go back to the drawing board with your next practical design? If so, how long are your lead times for each of these cycles? Long lead times = a lot of $ invested in product capabilities that don’t serve user needs and therefore don’t have an ROI (aka waste)
I have been a professional developer for the last 10 years and this video shaked my soul
"People before processes!"
Agile manager: We have to use JIRA, and this CI system, and this language, and standups every morning, and...
and sprint planning, and story poker, and backlog refinement, and team retro and sprint demos,.....
How many people are from Programmers are also human?
Here from Programmers Are Also Human :DDD
So true... Agile can just feel bothersome sometimes. Do we really need to do daily standups? What use even is an agile coach??
This video is equal parts brilliant and depressing.
I've had so much time wasted by Agile Coach cult leaders pushing for their own dogma without any regards to how it would actually be implemented (::cough:: *SAFe* ::cough::)
And then on the other hand I've worked with ADLs who truly embodied the spirit of _kaizen_ and were tireless advocates for fixing systemic problems in our working patterns... who then got ignored by the people with actual power, to the point that my company *literally fired* all the ADLs (while still expecting individual teams to follow its bastardized version of SAFe).
What is ADL?
@@johndoe-xk1je Agile Delivery Lead. The term "scrum master" is being phased out because the role is supposed to embody a servant-leader, not a boss (the term "master" is generally being phased out due to its ambiguity between denoting expertise in a subject vs. authority)
@@GSBarlev It's sad to see how fragile people become as to complain over mundane things like the word "master." Authority and competence still exist anyway.
I was a moderately successful scrum master when I was also test lead and was supported by a project manager who put engineering first and shielded the team.
Now I'm discovering the joy of the agile coach role, where I want to shorten deployment lead times and harden tests so that developers can get feedback, but my stakeholders want to see a SAFe rollout and to cargo cult automation pipelines while at the same time insisting nobody needs to draw the value streams or visit the teams
I can't help myself spelling SAFe (un)SAFe, because it really is. Big company with way too many so-called agile coaches and "Release Train Engineers"...
The problem started when the word "agile" transformed from adjective to a Noun. You are not DOING Agile, you ARE agile in what you do.
A very strong observation.
@@ToomuchNoiseToday its based on my 19 years in the industry, and comming from pure waterfall, through loving Scrum, through being sceptical, and then hating all that was created around Scrum. At first, the values were right, the first Scrum Masters were actual developers and engineers, so at the least - they understood that the ACTUAL value is only the thing you produce - code, how efficiently you can produce it and how close it is to what the customer and users need - thats all. Nowadays, you have "coaches" and "facilitators" that have come from far away from IT, have no background or understanding of what problem "agile" movement tried to solve in the first place, and just try to keep their jobs - which is being just a COACH or a Psychologist. Im not saying some companies dont need those roles, just like some companies probably need a Cook if they have a kitchen and serve employees dishes, but its a very very specific case, and should not be an industry norm. At the end of the day, the team that does ACTUAL work has all they need to make the right calls, and how you suppor it is by hiring smart leaders, and setting a right balance between ownership and guardrails (Im not saying this is easy, but it's the role of CEO, CTO, VP, Directors, Tech leaders and whole leadership organization roles, NOT some ephermeral extraneous Scrum / Kanban Coaches).
it's all just a misunderstanding. Actually it is "Edge Isle"
Part of the problem is realizing it's a tool and not a magic bullet. One of the points emphasized in Agile is that refactoring is cheap, so we will build out a model and then just change it as needed. That may work for functions and methods, but it does not work for data. It's cheap to refactor a stored proc, but try refactoring a table that already has a billion rows of data in it that take several gigs or pterabytes to store. Management loves it when you tell them that you will have to take the production database offline for a week to implement the new change.
I think for a good number of companies the video got the development over the past 20 years wrong: Agile was once (back in the days of the manifesto) a grass roots effort to make life for developers better, but in many companies it has been perverted and twisted from a framework for collaboration and self-organization to controlling and pressuring development teams in a fortnight cycle. (partially stolen from a HN comment)
Agile, XP, even Scrum: the developers should be self organizing.
Project managers: well what about my job?
Or more broadly: most managers are still stuck in 1940 factory management mode. Everyone is a cog, processes are decided top-down and every resource (which comprises human ones) should be used 100% for better efficiency. Flow, lean, theory of constraint? Dunno, don't care.
And even if they learnt about those 80 years of progress, they'd still have to understand intellectual jobs don't have the same constraints as physical ones. And that's a huge step for most of those mofos.
The only part they sure decided to not keep as it was during the old times was offices. They sure jumped on any excuse to not have people with personal offices.
@@ArkhKGB That's right. All those managers need jobs. It is easier to be a Scrum Master do agile voodoo, than to get software engineering degree and start coding.
I spent Friday sat on a zoom call looking at yet another new ways of working slideshow presentation showing me some form of Scrum, with a fortnightly “cadence” and how we’d be using Jira even more.
I’ve had to listen to this same old stuff for over a decade, rehashed over and over, by different people, as my teams and managers have changed. Endless discussions.
In all that time I’ve kept asking myself the same question.
“What is it these people actually do?”
I know I’m being dismissive when I ask that, but I do really genuinely wonder sometimes what a lot of these people are doing in relation to the end product - and even if they have any input at all, or add any kind of value to the process.
I was in a zoom call once and out of the twelve people on it there was one software developer who was actually making the thing being discussed - and that was me. Maybe there was also one UXer and a Business Analyst, but the rest, I have no idea; people with manager in their job title. It seems there is a whole group of people whose job it is to just talk about stuff.
Welcome, my friend. Welcome to the tertiary economy of America and its hoards of unqualified middle management positions.
Agile is brilliant when done by developers, it becomes an impediment when some agile clown gets involved.
Oh wow. "Agile clown" sounds like a clown that moves in a dancing way, like this guy in the video.
Was it Dave Thomas who said "calling it agile manifesto sounds like a book that jumps around"
@@theodorealenas3171Agile clowns sound fun, like they can do some acrobatic tricks while they are clowning.
Agile clown sounds very entertaining
"Guys, actually you are doing it wrong.
It can ONLY work out, if we follow each. single. rule. from the SCRUM guide!
First we need to estimate whateverwedontevenhaveanideawhatitsabout in units of arbitrary virtual stroy points..."
There's always gonna be grifters, and the best grift is consulting, followed by selling a startup, followed by "coaches"(followed by oil/arms industry lobbyists and middle management).
By the way I am starting a consulting business, so give me a contract. I have actually no idea how you do what you do, but the difference I offer is I'll listen to the people building it, before telling your exec how to do his job.
Man, this is the best video I've seen in a while!
Hilarious and so true 😂
Thank you! Recently left a project where there was that one guy who was the SM and PO but saw himself more as a product master and scrum owner. Project had so many "agile smells" it was nauseating. Any attempt to improve things were met with "Nah, I just don't see it." or dismissal of another flavor. Problem is, with each project team I work on as a freelancing developer, somehow Agile and Scrum just seems to get worse and worse over the years. (Of course, it's not so much the framework or the processes that changed, but the people implementing them, "leaders" once again not trusting the developers and trying to squeeze a maximum of "performance" out of the team)
I think initially, Agile methodologies were done only by people who really wanted to do them. Now "Agile" means something like "best practices," that is, the things you're supposed to do no matter what. So everyone says they're Agile, even if they aren't.
The part about trust is underrated. I wish the Manifesto authors had put the necessity of trust right at the start, instead of taking it for granted.
Well, that's the posterchild example for why exactly SM and PO should never be the same person. :/
This is so accurate, its funny. We have been trying to communicate this. So happy to see we are not alone. I am not even IT. IT is forcing Agile on Functional Process Re-Engineering for a brand new PLM system we have to work. Imagine the overhead on stories for a 2 week sprint to cover the Art of the Possible.
ha ha ha ha I loved it! thanks for making it, I just sent the link to my manager.
Felt like I was watching last 23 years of my contracting career in 6 minutes 😂
This actor deserves an Emmy
Agile has become magic internet points for corporations
Can you describe this a bit better, please?
@@ToomuchNoiseToday needs clarification, can we schedule a meeting for it?
Wow, what a great video!
The topic is really relevant. Behind all the rituals of Agile, you can forget that you also need to do the work actually :)
Agile doesn't enforce any rituals - the only thing Agile encourages is a retrospective. It doesn't even have to be a meeting, it can simply be an ongoing effort to improve the workflow, like building a deployment pipeline to automate the manual work, or simply reflect on the experiments in your team.
All the other things like Sprint Planning, Daily Standup, and so on, are only in Scrum. Individuals and interactions over processes and tools tells you that if, for example, the Daily Standup (a process) doesn't improve the interactions in your team, you drop it. If it gets in a way of the actual work, drop it. If it makes the team miserable, drop it. You can reflect if a process or tool suits you in a retrospective. Simply getting negative feedback from your team about some ritual is enough to not continue doing it.
For that, you need an autonomous (self-organizing) team - one that can self-decide about its way of working, which is another thing Agile mentions.
this looks to me like a very good approach. Agile is a mind set, not a manifest. Actually the two words "agile manifesto" are an oxymeron.
@@sewera.account For that you need open minded and democratic leaders. In companies lead like a dictature, you can be miserable all you like, if the company's finances are not yet highly concerning, the will still require you to follow those useless rituals.
@@sewera.account Maybe agile does not enforce it, but it doesn't matter because corporations, projects, clients and your scrum master does
It's like they don't believe we work outside of meetings, so they want to see us on countless calls
coming from programmers are also humans😂😂😂
Same
Same
Same
Smae
Same
The problem started when "agile" was taken hostage by managers who then made it mean "many waterfalls in fast succession". Guess what you get out of such a cascade: just gist and damp air.
What is the difference between agile and many waterfalls in fast succession?
@@tiefkluehlfeuer waterfall means 30% planning, 30% development, 30% test and 10% unforseen. Agile means 80% development, 10% planning and 10% validation. Huge difference in mindset too.
In my experience, the problem with Agile is the same as the problem with any other method/work form/process/technology introduced to the world of IT in the past 50 years: lots of very vocal people with too little understanding of the concepts, implications and repercussions involved latch onto it as a divine revelation, hailing it as the new black, and the silver bullet which will once and for all solve all their problems forever, as long as they embrace it wholeheartedly and in full, with no questions asked.
This seems to be some sort of disease in the industry, a complete inability to step back and ask whether this is truly the best approach in all situations. An unspoken assumption that all companies are the same, all projects are the same, all teams are the same, and all developers are the same. Everyone always seem to be looking for one-size-fits-all solutions to any problem, and are surprised when the latest buzzword doesn't just magically make all problems go away and make everyone work with 100% efficiency.
Thank you very much for your comment. Very well observed and you are comming to a deeper layer of understanding what is going wrong in so many areas od the IT industry. We are collecting a lot of your feedback currently to create a new story line for another video.
Well said. It’s like fight club. The first rule about agile, is that you don’t talk about agile.
As a PO I’m tasked with much of the planning, and if I don’t have stories planned for the next 2 sprints, it’s looked down upon. I’m ALL for planning but there is diminishing return. The best I will ever get is 70% right. So when something comes up: oops forgot this small detail, should be 1 developer few hours of work. Nope. Sorry. That will need to wait 7 days until the next sprit. We’ll put that in the backlog.
Ceremonies then basically turn into public shaming sessions. I feel it, and I hear it in the voices of my best developers when, once again, they failed to assign the correct number of story points, assign dependencies correctly or any other amount of endless red tape in Jira.
Send a thank you to programmers are also human
The best summery and "state of the Art" what happens to a great idea !!! Thx guys you touched my heard
This was an absolute masterpiece.
Thanks for your comment. It took us a long time to get the story line together and it was executed by a professional film company with real actors.
@@ToomuchNoiseToday worth every penny and we should absolutely have this conversation about agile. Agile in principle is about being adaptive but instead we're bogged down in rituals, cult of personalities and suffocated to death by 'the process'.
@@LearnFrontendNow If you want to go into details, it would be great if you can do our agile survey www.striped-giraffe.com/agile-paradoxon. It will be hard to find those deep-dive results on the internet.
pre-agile transformation - "... and every individual's voice will be heard"
post-agile transformation - *only the scrum master has a voice*
for communism to work you either need God or a dictator.
No, the po usually
What a great video production.
Nice shot from Warsaw there, Emilii Plater 😊
Explains the industry perfectly. We have lost our way.
Plan for two damn weeks to implement a feature that takes two days to write.
Oh and don't forget to burn down your f**king hours!
I think, if you have great people managing agile, it works really well. During my short life in company's time, I've seen "classic" project management as well as good and bad agile project management. Bad in many senses: not adapted for the team, not really understood, not really pushed through.
I've seen good examples, and when it is well implemented, adapted for the team, and people are actually talking to each other, it works really. Problems mostly arise through company hierarchy, in my opinion, and people who try misusing agile project development for micro management or to force more productivity (and want improved productivity by an instant).
It's so fun watching these videos and memes about it. Especially for me, who has generally made really good experiences with it. 😂
"If you have great managers" has nothing to do with agile... that's the cult mentality. Every thing went well? Thank agile... everything went wrong? You didn't agile hard enough.
@foxvulpes8245 I have zero knowledge of where the f you took any of what you said from my comment.
Neither did I ever say or listed that failed agile teams haven't pushed agile hard enough (or didn't really push through, i.e., saying they're agile without doing anything really agile), nor did I mention "great managers." There's a big difference between team/product managers and people managing agile.
Not only that, but I also never mentioned anything with regards to thanking agile if things are going great or cursing at it if things fail. In fact, I did mention problems arising with micro-management from certain managers and ill-adapted or completely misused agile practices. There are just certain use cases or groupings of people who just cannot work (well) in agile development, and there are, of course, bad managers and bad people managing agile.
It's more of a cult mentality if you're only trying to bash against something, isn't it?
Also, it's definitely way more of a cult mentality to not see the greater picture and just talk shit about ways of working instead of factoring in the people, conditions, and topics of said work environment. Again, agile isn't for everyone and everything. Some things just don't work in agile, and some managers misuse it for micro management, and some people just cannot work like that (or adapt it to their use case).
And, of course, every new system/framework has to go through a phase of trial and error and adjustments to see whether it works great or not. That doesn't have to do with cult mentality or "forcing" people. Things do not have to stay the same, and new things take time to adapt and experiment with. That natural and has to be factored in.
And if it doesn't work, you should always be able to go back (which some companies or managers don't want for micro management, etc. But then, they're not understanding what a framework is, let alone agile, tbh).
@@playeronthebeat Found the conditioned Response.
@foxvulpes8245 ah yes. Seeing things differently and not the way you want to see it is "conditioned." Very nice.
Have fun doing whatever you want to do and work within the framework and way of working you like best.
There's literally no real right or wrong, and if people are not able to argue correctly, I'm not wasting more time with them.
If you don't want to see things nuanced and don't want to accept that agile actually works, it's your thing. Never did I say, nor will I ever say, that the agile framework works for everything and everyone. That's simply not true. Also, I won't ignore that some managers put in "agile" for micro management of people lol
Everything else would be just as stupid as seeing things purely black and white (or throwing phrases like "cult mentality" and "conditioned responses" to someone who just hasn't the exact same view as you without bringing any arguments).
years ago my boss took me to an agile "event" (?) at microsoft R&D headquarters in cambridge that was basically a religious cult meeting x improv class. at the end we literally sat around in a big circle and people gave hagiographic descriptions of how amazing and life-changing the experience was. the event was like tony robbins style trust fall summer camp improv class stuff for 3 hours... but presumably it was all about agile (?)
Incredible
I think most people who criticise agile have not worked in software engineering before agile. I've only experienced chaos, poorly managed by overworked, clueless techie-bosses.
When Scrum coaches insist on ceremonies or the like, and ignore team members' opinions that don't agree with doing that - they're just doing it wrong: People and interactions over processes and tools. What they're doing is insisting on process, ignoring people's opinions and ideas. They're not coaching, they're leading. This is fine when there's a massive lack of structure in a team, but once things get going they should tune it down.
I was reprimanded by HR at a F10 company in 2008 for pointing out this exact issue when they "introduced" Scrum. People were so obsessed with one upmanship that they were spending 8 hours preparing the sprint review which they presented in suit & tie for a 2 week sprint 🤦♂
I freakin' love it! I seriously needed the laugh... especially lately! Thanks a ton.
Spot on - I love agile when it's used in conjunction with prototyping and not micro-managed to the extreme. Formalising Agile feels like an oxymoron - too many bean counters focusing on velocity rather than outcomes.
Absolutely great!! Sometimes I did not know should I laugh or should I cry :-) I will share this video with some people who may really feel like this is from their heart.
This is Krazam level of quality! Subscribed.
I went from agile to waterfall and agile had its problems but it's still better. The problem is people who's whole job is agile process stuff and not the work that agil was supposed to empower.
This is why you need agile on the meta level!
Edit: read a comment here that had a good take: The problem started when the word "agile" transformed from adjective to a Noun. You are not DOING Agile, you ARE agile in what you do.
Oh gosh! It's gold!
The moment people started to write agile with capital A, the tool became a religion and the colleagues doing general managerial tasks became the priests. Technical experts usually have a very hard time believing in conceptual nonsense like this.
Please let me know there will be a chapter 2!
We wil for sure; we are just digging deeper into other findings, all related to our industry and beyond.
sprint 2*
Here is the thing, the type of agile that the agile manifesto was looking for tends to emerge quite naturally, even in groups that have no knowledge of the theory of it, and it is surprisingly common, especially in groups of competent profesionals who just regularly reflect on their project together, as in just hold meetings once in a while for "how are things going, and do we need to change direction". The type of Agile that has been commercialised is built to be a structure that tries to force work to have some simularities with what the agile manifesto was advocating for, but do so by imposing a lot of structure that in principle is the opposite of what agile manifesto was advocating for. I remember one manager talking about "yeah we want to introduce this method", to which I asked them whether they have considered just what kind of needs they would have so they could select the right version, and oh we are kind of already working in the way that the method is hopeing to get us to look like.
as a developer this resonates, I f*cking hate production people with ideas, It is all BS! Cascade, Agile, Kanban, done em all got the action man and t-shirt. I wish production would learn something about the disciplines they are planning for, for once.
90% of meetings, 10% of coffee breaks ... I mean work.
The first problem is that Scrum is the complete opposite of Agile.
Agility is a continuum. You've just witnessed two extremities. Somewhere in the middle is your organisation's sweetspot - find it, but don't get complacent. It moves, and it's different for each project (assuming you still have projects).
Muito bom, excelente
Eu já falo exatamente isso há anos !
Mas ninguém tem coragem de falar que isso virou uma religião . Ninguém aguenta mais
There is a big misunderstanding related to agile. The agile manifesto does not propose scrum ceremonies. Whoever wrote this in the video description did not read or did not understand the agile manifesto correctly. In my opinion, as a Scrum Master, the big problem with agile is the industry of methods and frameworks. For example, you learn that you are not doing Scrum if you do not have a daily meeting, instead the daily meeting being used as a tool for the team to decide whether to use it or not. Let the team decide which tool, process and framework to use to deliver the right product to the customer with great quality.
Did you use Agile while writing, filming, and editing this?
There's an error on the description. The Agile Manifesto does not propose any Scrum ceremonies. In fact, the Manifesto does not contain the word "Scrum" or "ceremony."
This demonstrates some of the big problems with both Really Existing Agile and its criticism. Everyone ignores the Manifesto and treats Scrum and its many ceremonies as the sine qua non of Agile. And even then, the "Agile" people refer to might not have much to do with what's in the Scrum Guide. Why read that when Agile is "simple"? Just have daily status report meetings (sorry, "standups") and planning meetings every two weeks where you use some convoluted estimation method that's supposedly not about time, but actually is.
You are hitting the spot. That is why we wanted to create this Video. We do not want to be the ones knowing everythng better and for sure not to propagate a new agile manifesto. We want to bring it down again to ask ourselves on how to get the work done in a pragmatic, agile and developer friendly way without too many meetings. This is an invite for a discussion. Thanks for your comment.
I unironically think that an actor who can make you want to punch them in the face is a great actor, bravo for channeling the pathos that is over-used Cargo Cult Agile good sir.
thanks! I had no idea what I was talking about, so I'm glad it moved you to feel something ;-)
This is a masterpiece
I've just started working as a backend developer and have no idea what agile actually is . what's watitng for me ahead
Conceptually, "agile" is doing the smallest demonstrable part of the finished project, getting feedback from the customer, making course corrections and repeating until the customer is satisfied in the end result. In practice, it can end up being a bunch of extra work that frustrates the team.
Agile by design was to deperson developers into cogs that upper management (who often have no coding experience) can replaced or micromanaged. It is a corporate buzz word slung around by the Duning-Kruger CEO class who think that if they can get 9 women they will have a baby in 1 month. It is why I left the software industry to get paid more doing way less and watched the company I worked go under in 1 year w/o me. I had worked there 7 years but I was getting flak and write ups for not being a team player about agile. Infact one middle manager actually tried to fire me. Told me I was fired and I just sent his letter and response to the program manager. They didn't want to take a side because they had to support agile.. but I was un fired. Keep in mind this was after receiving corporate awards that only 3 our of 2000+ employees received per a year per multiple years, and some awards that literally had "savior" etched in the big glass block.
Yeah. And I’ve never been less productive. Today agile is just another form of top down development with more paperwork and meetings, and less opportunity to change course. Everyone is another automaton. Basically the opposite of agile.
That was so well done!
This is brilliant!
So well made and shockingly accurate 😉
Now this is some good criticism.
Great video! So true!
Been in 'the biz' for 30 years.... waterfall, agile/scrum, etc.... Here's the deal: Figure out the (REAL... ahem) problem that the customer wants to solve, and? Solve it. Crazy, huh? Always try to figure out how to break it, and then always try to make it so it doesn't break. And for God's sake; once someone figures out how to do that stuff, let them do it for as long as they want to, without forcing them to 'level up' to a point where it becomes impossible for them to know either the problem or the solution anymore.
You are making a strong point here imho. GTD is a discipline which many people have forgotten. Or even a bit rougher... get the fucking job done. But there are aspects to agile which have the potential to improve our life@work and some do become a religion. And as Agile was meant to be executed by programmers (also the Scrum Masters) and becomes evident that something goes wrong nowadays. We do not need Gurus who tell us how life looks like. I have seen agile Coaches which have the intention to solve even every aspect of people's life.
"We can stop doing and talk about doing" embodies my issue with Agile/Scrum so much
Not that the process on paper is bad, but the fact that in implementation it turns what should be a simple feedback and implementation process into a series of really unnecessary meetings.
I also think it gets applied on a level too small scale to really be of any additional use (like, does a project with less than 6 people really need it?) or a level so large that you start having people involved in the conversation who have no applicable knowledge or who just don't actually care (so why are they here?).
😂 What a rant
This rips double hard... My company does agile, but nearly every riff from the waterfall segment still applies... :(
Things like this video scare me. I haven't worked yet but I'm glad I listened to a lot of talks from the originators of the agile movement, before getting a job.
A few fun facts in case you're interested:
- they called it "manifesto for agile software development", "agile manifesto is like you give it to people and they start dancing", "they even capitalise Agile like it's a God"
- they don't like calling it agile anymore, generally speaking, because they're uncomfortable with what happened
- they didn't intend to give advice with the manifesto. Some of their other work gives advice to advanced programmers, or general advice, and rarely beginner-friendly processes you can follow
From what I understand there's a disconnect in the underlying context. It seems that the most advanced, most experienced software developers are extremely social. They try things out, they comfort their higher-ups when they look uncomfortable, they don't tell the higher ups what processes they follow, sometimes they even sit in pairs two people per computer like airplane pilots. Even outside their skills, they're fundamentally different to stereotypical programmers. These seem to be the sort of people who write the agile movement related books. I find this fascinating because it explains the situation, as well as what we should do about it on an individual level.
And the energetic agile coach in the video reminds me of the phrase "blazingly fast". Does "blazingly fast" come from anime?
Coming from a 48 year old programmer: you can essentially ignore agile. Don’t let it distract you from what is hopefully your passion : programming. The average company will just pay “agile” (whatever that is) lip service. It’s not really important. They will talk about it. Just nod your head. And if you find a company where agile has become a cult (I’m sure they exist) simply up and leave. That company is not worthy of your talent and will likely fail.
Don’t misunderstand: agile is done well sometimes and has shows value. It is well suited to mainstream, incremental, bespoke, product development. The classic example would be a web based inventory system which must evolve based on user feedback. It is not well suited to a large amount of product areas including from scratch “green field” stuff, or anything which requires any kind of formal engineering practises, such as anything safety or security critical.
How did you find so much friends?
No worries, guys! There's always a war-room next weekend, to solve any problem, that no one could tell, because every one was telling stuff 😂😂
Actually amazing 👏
Reading the comments made me feel sorry for all the people that had bad agile experiences, specially the daily meeting ones. I thought it is really hard to ruin agile, but it is really easy if done by old school project managers.
OMG THIS HIT ME RIGHT IN THE FEELS
its like you read my mind bruh
What we need is more gamification.
Next time, don't give it a name.
When you give it a name, you give it power over you.
Is this from some movie or so?
No, but maybe they will make a movie out of it. ;-)
The pain of moving from agile to scrum safe2 bullshit framework is making me open LinkedIn on planning days
Gold
Excellent video! This is how complete idiots who can't even write a line of code have found a job in software development ... you don't need years of programming experience to work in the industry - just do a two-day Scrum Master (certified!) training and you are good to go telling seasoned experts how they have to do their job. Es wäre lustig, wenn es nicht so traurig wäre.
I reached page 6 of the survey and gave up. People should really stop making 10 page surveys and hope for someone to answer them ...
Sorry Aleksandar; I can understand you... but this is not a high level superficial survey. We wanted to have a deeper market insight. Only then we can do something with yor experiences and have a detailed outcome.
*Brent stands up and begins a slow clap*
Bang on, nothing like salesfolk hawking 'frameworks' and enterprises completely missing the point to kill a good idea. Grug the caveman say agile values good, scrum framework bad
.
Love this
What Is the first sentence. "This Is ??? "
futile
If coaching is indeed a bad thing, there was apparently enough money earned with it to pay for this over-produced video. Which is btw done very well,, compliments for the production!
Ahh, 2001 - the days when Total Quality management folk (with no development knowledge at all) were bogging down teams in bureaucratic systems. Hell, even as late as 2007, One large multinational was rolling out a defect management process "with only 23 states" and were bragging about it. Of course there was going to be kickback - it was necessary, however, the kickback was largely ideologically driven and rigid - right from the start. To question or innovate the agile manifesto was heresy right from the start. Enter the education industry churning out people certified as scrum masters after a weekend course, prancing around as if they know everything about development. We went from one extreme to the other - and each time we end up with people who have very little to no lived experience with development calling the shots. Don't worry, something else will come along and so the cycle repeats. Bright shiny thing coming - get ready moths to fly towards the flame again.
I'd be very happy if you could tackle Design Thinking next ^^
Actually, we want to continue with videos about our observations. "Design Thinking" is for sure a strong candidate.
Spot on!
Prowareness ppl suck!
Programmers are also human brought me here.
Imagine breaking your back doing hard labor every day and reading the comments here…
how to tell someone you work with SAFe without mentioning it once 😂
Agile is like communism, everyone got it wrong and now a lot of people suffer because of it. As I heard someone once say, "the moment agile died, is the moment it stopped being an adjective and became a noun", as to say Agile != agile.
They were obviously doing Agile wrong, that's why 50 million died. We must try it again in this country, but do it correctly this time.
/sark
This is one of the most stupid arguments that i hear here and there - you can use it for everything that you want to paint in negative light. Just because dictators rise to power on "communism" baners and then abuse their position to exploit and even kill others is not different from "businessman" or politicians that rise to power on "capitalism" baners, and then abuse their positions.
Being in relm of politics analogies, I wonder how many lives were cut short because of insufficient wages paid to workers, while one of fathers of capitalism, Adam Smith, was vocal advocate of importance of fair pay - how that happen that in "capitalism" we forget about that and workers need to fight for that right? Could we say therefore, that because ideas are abused and people suffer, capitalism is like communism?
Agile is as much like a comunism as capitalism, waterfall, OOP, or any other idea is. Just because people are imperfect, avoid understanding, abuse ideas for their own advantage is not a proof that something "is like communism"...
Really true
Yeah! Yeah! 🤲👐 when software developers end up having their daily pentecost.
History will not look kindly on the cultists of Agile
Why are we talking about agile? We should be talking about delivering outcomes. That was kinda the whole point.
This is what we stand for. Focus on delivery. Nevertheless, we find some agile principles useful some not that much. One focus we do have is to bring down the amount of meetings massively in order to give back freedom to developers which imho are creative people. Whenever you disturb a creative being you are loosing a lot of output. But... we want to have your individual opinions... in order to summarize and come up with conclusions which then agian.. we want to share with you guys.
@@ToomuchNoiseToday agree! When scrum works like in the beginning, SM shields the team from random BS and PO attends all the alignment and strategic meetings so that the team can crack on and build stuff. Review and refinement sessions and a really good use of *so that...* should give all the alignment needed for Devs to make good decisions in the small