@@matswessling6600 If a team can use agile/scrum without management access to tracking tools, that is certainly right. However, any methodology endorsed and enforced by management will have tracking tools. Personally, I wish managers would go back to GANT charts and PERT charts and let programmers use agile/scrum per the manifesto.
@@paradoxicalcat7173 we have exactly similar situation. It's even worse, THE PM makes everyone 29+ stuck in an hour long daily scrum asking everyone status, completely useless
We're at the time when Agile isn't anymore a tool for the team to self-organize but a tool for management to impose micromanagement. On the grand scheme, the gain of productivity was lost. It's just the illusion of measurability that stuck.
@@user-vr2rq5hl6lyeah and that kind of visibility was unheard of when extreme programming and the first scrum guide were written. They used paper tickets, and only the team sees the sprint backlog. Real self organisation. Hell I was doing fine with magnetic whiteboards and post its before management broke my co located team. We could write anything we needed on a ticket and rewire our board on a whim using a marker or a piece of tape. This ticket has 50 tests and we discovered a problem when reviewing the 20th? Make a new kanban board for re-review of the tests, Job is good. Now I have to write to an admin to add a custom field.
The problem is, that just because the management calls what they do "Agile" doesn't mean it has anything to do with "Agile". Blaming Agile in such a case is just stupid. It's like making a vacation in Greenland and then complaining that it's cold at the equator. It doesn't make any sense.
@@gzoechi "Agile" lost its meaning. That's why there is a difference between Agile and agile. "Agile" is just marketing ploy now and agile, the attained quality, where at least some of the verdicts from the Agile Manifest are upheld, is rare.
@@rccc5806 Only to you, because you accept the nonsense. This is why we have to find new words for old things all the time. Just because a lot of idiots misuse a word, doesn't make it mean anything different. When we start using a new word the game begins again and again ... We just need to teach what Agile means instead of letting the bad people redefine our words.
I was "fired" once, because the "PO" said I was slower as a Senior than an Entry level dev. I laugh, cause nothing I ever coded came back bugged, opposed to what the Entry level guy used to make. I only said: Suit your self, if quality is not the priority here, then I agree, I should go. And then I left, smiling. :)
Did they provide a cost analysis of total time spent with entry level guy vs. doing the job right the first time with senior man? I'll assume you'll say, NO.
I was in that very same situation back there in the mid-1990s in Germany. The customers of the company I worked for were afraid to get updates. Except for updates I had been coding - and testing, I might add. Yes, that took way longer than the usual development processes at that company but it was definitely worth it. The differences are that I was not fired for developing properly and, well, the development back then was not really agile.
@@seraphinberktold7087 Sure yes, but yeah it's not like we are dragging the development, we just want to deliver once and with quality, thats all. 😞Make sure all the exception paths are handled, etc, etc.
I said basically this exact thing. The junior devs “produced” code, but it was always garbage. And the overall architecture was so horrendous that touching one file caused ripple effects in multiple classes, and in some cases forced major changes in the unit tests. Absolute madness.
Head of Engineering running a product team with 35 engineers here. ✋ My advice is: Just skip the damn meetings and focus on building great software. Show up to demos with great stuff. No one will question you if you consistently deliver high quality work, I promise. As a smart engineer, you can demonstrate that you’re capable of doing the job better without managers telling you what to work on and keeping you under a microscope. Here’s how: Avoid being boxed in as the technical savant who doesn’t know anything other than how to write code. Ask the right questions. Make sure you understand the user and the business. Do your homework and make sure to talk about customers and why your work is valuable to them. Take professional pride in your work. Don’t agree to impossible estimates, or sacrifice quality for the sake of deadlines. Just deliver high quality working software consistently, and demo it frequently. The managers and excessive meetings are there because leadership doesn’t trust you. They want someone to keep an eye on you because they believe software engineers can’t make design / product / business decisions themselves. Prove them wrong and focus on just building something you can be proud of.
When she said "agile 2.0 that puts the devs first...". As a manager I shaked. Agile it's the opposite. No one comes first. Devs must accept that tey have a vision of the world that must align with the business. That's where their salary come from. Comunication it's about try to understand each other needs. (And this does not means to of meetings.). My advise despite the methodolgy used : there are other people out there that are not devs but that struggle to do a good job as a whole. Some of them are good, some of them aren't. Just like among programmers. Communicate with them . Even if you have to use words and not... a protocol. Anyway.. I love the video and I agree with the fact that Agile is too often not working.
That IS the definition of Agile. That’s what I always try to fight for and against the Big Savvy Bosses who want to believe they know what they’re doing. 1. Devs are not dumb waiters. They create wonderful things by solving puzzles. Do you really know how to organize their workflow better? Let them decide! 2. Agile != Speed Up Development. High Value High Quality first. Otherwise you will be buried in Tech Debt and every feature will cost you 10x more. 3. 100% Utilization is shit. Do they give you the result? F*ck off then! 4. The only options to give the Devs any feedback are Sprint Review and the rare cases when they ask. Go and talk to the customers and do tons of researches. Let them cook.
Project manager/ product owner here. I am usually getting kicked from above for not religiously dragging the team through a ton of useless meetings and Agile ceremonies. My teams typically love me for that, my bosses don't. And can someone please explain how a sprint is not simply a two-week waterfall? I still don't get the fuss about what's so great about sprints. Much prefer Kanban and CI/CD...
I'm not agile certified so I have the same question. How are sprints not waterfall? My group is automation and robotic engineering... People with mechanical, electrical degrees and we code a ton. When asked if we're waterfall or agile I just refuse to answer, instead describing our workflow which to my knowledge is a hybrid of these two ideas.
@@DAG_42 First of all waterfall is rather a theoretical model for processes, where software is built until a big release (which can take months or years) and after that the feedback is gathered. Sprint could be a waterfall (because it has the same phases), if it lasted too long. Also, when the team doing sprints sees results long after the project was started, not getting any feedback from stakeholders and blindly executing what PO puts on the roadmap, it's a kind of waterfall. Just its classic phases are mixed into sprints. And if you get feedback but your managers doesn't include it to next sprints - sprints are artificial. Also, sprints are not required to develop software in "an Agile way" - it's one of the method. For example in my project (I'm a dev) we have very slow adaptation of updates - it takes months since majority of our clients will update our library. So even when we have a great telemetry, we cannot inspect the results and adapt our plans at the end of the sprint. It would be much better to get rid of sprints but... our managers are too used to them to change anything. So for me this is the real problem with Agile: it's a standard nobody understands anymore. Like Project Organizations 20 years ago. Agile is a philosphy and a set of tools you should pick carefully for your individual project to embrace this philosophy. Scrum is not the only Agile method, but companies are behaving like Scrum can work everywhere.
A scrum team is suppose to swarm around the work and go story by story, limiting their work in progress, and collaborating constantly to achieve the sprint goal. But many (most?) teams tend to just waterfall their scrum, pre-assigning all stories individually, with everyone doing analysis the first 3 days, development the next 5 days, then a testing/bugfix crunch on the last day (and into the weekend if necessary) often with corners being cut to force work across the finish line. Why? Many reasons, but mostly because it's just good enough for most projects.
Sounds like you bosses doesn't understand agile. Sadly they are not alone. And the "sprint"? Well, since you mention a sprint I would suspect you are using Scrum. Scrum is built on empiricism where we form a hypothesis, test it and evaluate to build products in complex environments. The sprint is an arbitrary container of such an iteration. Many use two week, I have done one week sprints and even seen shorter than that. It should be long enough to get actual data out of it to inform future decisions. If we simplify and say we are to scale multiple high-rises and put posters on every floor we might initially have an estimate of when we believe we will be done. Updating that estimate after scaling the first floor of the first building might not be the most optimal thing to do since we have not acquired enough data to make a more informed guess. But say we have a timeframe (a sprint) where we manage to scale 3 out of 8 houses, we have learnt that older houses tend to take more time due to certain factors etc. At that time we could extrapolate a guess founded in more relevant data than we initially had for the remanding work (or pivot if needed... perhaps we decide its not worth the investment, or that we need to finish faster so we need to deploy more resources). This cycle of inspect and adapt is the fundamental aspect of Scrum. We inspect and adapt our sprint plan on our daily scrum every day, we inspect and adapt based on the result of our hypothesis in the sprint review and we inspect and adapt our process during the retrospective. Scrum is incomplete by design. Only bare essentials needed to foster the foundational notion on which Scrum rests are prescribed and each team is to find complementary practices that best suit them and their context. What do I often see in companies claiming to "be agile" and "doing Scrum"? The teams are asked to book a bunch of "meetings" that no one knows the purpose of and no one explains to them. They then go to these meetings and try to make sense of them. What humans often do is to use previous experiences to interpret new ones when no other context is provided. So the daily scrum doesn't turn into a short affair where the team inspects their progress since last time and adapts their plan but instead turns into a status meeting. Either people try to convince the other members of the team that they actually did work yesterday, or they try to report to the Scrum Master. If it's really bad a manager is there who they "report to". The Sprint Planning turns into a contract negotiation session with management, the Sprint Review is where you have to apologise for not getting every single things you guessed in the Sprint Planning "Done" or if you are lucky actually got it done (or made it seem like it was done) and at least didn't get scolded. During the sprints each "role" work on their small parts of a story in isolation. A designer creates something in Figma and hands it over to developers who then develop and hand it over to testers... all while requirements specialists make sure all the arbitrary requirements dotted down a long time ago are fulfilled and documentation updated. Instead of working together, swarming around the highest value task and seeing it to completion we see Water-Scrum-Fall (waterfall in sprints disguised to be agile). and on and on and on. This is a perversion to put it mildly. This is not the use case for Scrum, that is not Agile product development and yet so many companies claiming to be doing agile do this. Most companies have heard of agile success stories, they want their slice of the cake of magic benefits. But they don't actually embrace the mindset shift that agile rests on. Instead they incorporate words, names of roles into their existing processes and tools. When that doesn't work, they proclaim that they tried agile and it "didn't work for them". It might shine through (hehe), but I'm growing sick of the agile theatre organisations play and that they manage to escape blame and instead shift the blame onto agile.
I've worked in the role of manager and I have a personal policy -- have the least amount of meetings possible. I swear many middle-management people schedule meetings (in all industries, not just software development) to give the "illusion" that they have a lot of work they need to do, it's corporate theater. How often have you been in a meeting where the relevant portion for you or your team is a 5-minute block somewhere within that 1 hour timesuck? I imagine it's a lot.
There are so many jobs that didn’t exist, and never needed to exist, that are the result of automation during the last several decades. People worry about AI taking their jobs but they shouldn’t. New jobs will be created and if history is an indicator a lot of them will be nonsense roles. I know there are good middle managers but a lot of them spend most their time trying to justify their own existence to management. So all they really want from the people they manage is PPT slides and meetings to fill their calendars for the illusion of being busy.
@@MikeKalil, when did you start in IT? I've been at this game since 1979, and believe me, there are far less people required in IT now than in the olden days when I started. My dev team does the same work of 6 times more people required to develop in the old days...less QA too now because much of testing is automated, scripts, etc...perhaps we have too many middle managers now...
@kylek29 That's not true. I don't believe you. Let's set up a meeting to discuss that, okay? 😅😉 You'll get a chance to give your side somewhere in the hour meeting, .....OH...and bring us donuts and coffee, okay. 🤣
@@SpaceCadet4Jesus Scrum is just a money maker for some hack that came up with the idea. A Scrum Master has to pay $300 or more to take an on-line course. It looks good on paper but it is just padding for a manager's resume. Agile, Kanban, Jira too. In engineering, many middle managers have the position go to their head because they think they are a "super engineer" and that is why they are a manager. No, true engineers want to create not manage. I chose to remain technical and create. I knew one manager that read all sorts of books on management. He tried to implement several philosophies at once.... Ineffective.
You're one of the rare managers who recognizes that management and meetings are overhead, and are to be minimized. Agile goes in the opposite direction, treating everyone like children, and adding overhead.
I started coding in the '80s - used to kick out (good) code like crazy, I can't imagine writing a lot of code today - these processes strip all the joy out of the process.
Hilariously, the relentless emphasis on the MVP has created a world of developers who "respond to change over following a plan" by cutting corners. They never actually learn how to write code that is architected to anticipate change. They've been trained to focus only on the moment. 😞
Started in the late seventies, but I have to agree. Still writing code though - but I am self-employed, so most of the meetings are with myself. But my colleagues from the 80s do agree with you, we had a very different work culture at that time. The boss told us his wishes about the time schedule, we did some bickering and found common ground.
It depends upon the development group, the team members, the management...if they are decent, then coding today is freakin awesome...if not, you experience various levels of hell...think Dante's inferno...
@@joelholdbrooks6729 This is a great comment. I studied computer science in the '80's and then wrote code for many many years. I'll admit that expediency, schedule pressure and short-sightedness often prevent writing robust, well commented, extensible code (management along the lines of "why design and code for something we're not getting paid for"). Over the years I've seen so many fashionable coding idioms and paradigms come and go that when I see some current Best Practices guru spout mantra I just roll my eyes. Next time you hear someone talk REST ask them what it stands for and have them explain the underlying principles and theory. Bet you they don't know.
There were two things I did to survive “bureaucratic” agile. First, since our overbearing project manager came to the retrospective, we couldn’t voice our real concerns. To combat this, we had a secret retrospective afterwards without the manager so we could talk openly. Second, when it came to estimating, I always estimated as high as possible without breaking out laughing. The manager hated it but had to admit that our customers were happy because we always ended up delivering on time.
"Second, when it came to estimating, I always estimated as high as possible without breaking out laughing" This is actually sound advice. I prefer not to estimate but if I have to, I will do this.
i am a product manager and i actually do and expect the exact same, you shouldn't have to do a secret retro. I always want my team to estimate as high as possible. I prefer always delivering less on time than promising more and not being able to deliver. It works, team is happy, stakeholders are happy, end of story.
Amatuers estimate high...true pros estimate within 10% of how long a story will actually take. People that estimate high on purpose should get fired off the team!
@@jacobmeetsworld6812, it is against Agile to estimate high on purpose, and its also anti-Agile for the product owner to attend the retro. It sounds like you are not using Agile, nor do you know how it works. Its always a good policy to under-promise, over-deliver, but to do it with corrupt means is simply unprofessional. This is what 45 years of development has proven to me...when done correctly, Agile is the best way to produce and maintain products.
@@TheSilverGlow Ah, but you probably didn’t have a project manager who would argue for the smallest possible estimate when we never had a chance to look at the code to determine how much effort was actually needed.
This is such a fantastic video. You've really nailed down one huge problem with modern Agile--people with zero development experience think that the process they manage is itself productivity.
I have worked for a company that makes air data inertial reference units that produce the navigational data for commercial passenger jets on multiple occasions as a contractor. The last time I worked there the manager who had hired me retired and the new manager who replaced him wanted to inflict agile methodologies on the team. All the lead engineers were against it because it is a complex, math intensive product, with a very high consequence of failure. The new manager laid off all the contractors and replaced us with inexperienced recent graduates. After enjoying a little time off, I got a contract job at a medical device company. A guy who sits in a nearby cubicle is a former coworker at the aerospace company. He said the reason he left was because he saw the trend management was taking said he wanted no part in causing a plane crash.
I remember a time when I was with IBM. After the manager laid down new policies for meetings and reporting, a programmer asked: If we do all of this, when do we actually work?
@@HussainAkbar Something I’ve noticed is that most Agile/Scrum meetings are spent talking about story numbers and iteration numbers without ever talking about the technical issues.
@@user-vr2rq5hl6l because technical issues are not relevant. Just spill over. Write a short summary that nobody is interested in, but can be used to fill up the next SoS meeting.
Businesses seems to associate speed and agile with each other. Instead agile works great in a condition where we need to learn a lot. Waterfall works great when we know what works. My personal opinion is that we should stop taking the frameworks so serious and start to work out how to best deliver business value instead.
Yes when the bosses say they want agile they mean they want short lead times and the ability to change their minds whenever. But agile is hard. Scrum doesn't work unless the team is more or less doing xp level engineering. Scrum is also supposed to make the team sovereign and shield them so they can protect the improvements they need to make quality flow. But this doesn't work if product management wants to come to the stand ups and ask why developer x doesn't seem to have any real work to do.
I disagree, 45 years of development has taught me that Agile is always the best way to go. Even if you know what needs to be done, do not need to "learn a lot", Agile provides transparency to all team members, provides expectations of when this and that get done, and it provides a fantastic communication platform to share, to learn from other team mates, and to mentor. If done wrong, Agile can be far worse than water fall. If Agile is not working for you, you're doing it wrong.
@HonkletonDonkleto, is sounds like you do not understand Agile. You mock it because you don't have the experience to appreciate it. You still in college?
@@TheSilverGlow I used to have a team member who railed against all the agile. Back at my old employer, he'd say, we just got the requirements and wore the code, we didn't have to stop every two weeks and integrate, or update the tests with every ticket. And did the code work? I asked Nope!
Excellent summation, but I'd like to add a few more issues. The original problem Agile was designed to solve was for consulting...having a design team meet with the customer, get all the specs, lay out a plan usually waterfall), build the product in camera then hand it to the customer only to discover that it's not what the customer wanted. This happens because real world end uses often don't really know what they want until they see it. So Agile baked that in by having a design team draw up a "big design" plan, then iterating the design on a two week schedule and showing the customer chunks of the final product to get dynamic feedback. THAT works. Where things went off the rails was the assumption that this works for all development when in fact, it really doesn't. Example: if your Agile team has no customers, or almost as bad, a in-team customer representative who represents the customer but works for the dev company, you're not doing Agile. (Pigs and chickens as we used to say). Worse, somehow Agile changed from a productivity tool to a productivity MEASURING tool and external managers became "chickens" along with the customers (if you even have any of those), creating a conflict in goal. The managers' goal is to get the product done as fast as possible and make money off the work invested. The customers' goal is to get exactly what they're paying for. See the problem? Things like "velocity" weren't part of the original idea either. It was added as a way to check progress and see if there were bottlenecks. Now it becomes a "success" metric on its own merit. I can't tell you how many scrum plans have been rearranged in mid-process just to get velocity numbers up higher. Or how often after a sprint plan is locked, someone in management changes direction and blows the entire plan out the door. (And then complains about OUR velocity...) Oddly to me, this relates to git or "blame-based source code management" where finding the goats when something goes wrong is more important than just getting the mistake corrected and educating the team. Fear-based development also rarely works. Agile has a place, but somehow it's turned into a religion and a surprisingly rigid one at that given its actual name.
You’ve described some of the exact thoughts I was having about Scrum at work recently. We transitioned back to Kanban because there is less arbitrary bureaucratic stuff to worry about, like points or whether we can squeeze another task in.
I would add that agile has become a way for justifying constant specification and priority changes. Working with requirements that change every day is awful
There are so many things that can go wrong with a project but its usually not Agiles fault in my experience. We run a large number of projects and I can't say the agile side has ever been something to complain about with excellent standards and quality output. The only issue has been contractor turnover but we resolved that by viewing things from the contractor point of view, there are solutions besides money.
Interesting. I am writing a book that shows how we are addicted to specific ways of doing business, which has a much higher inertia and much higher foundational scientific Newtonian base, than anything that agile has ever written or developed. Design Thinking has been also dramatically standardized everywhere, for the same reason.
My employer forced nearly all IT teams to use agile. My team is not developers, we support servers and software on them, along with tuning the configuration of the applications. When we just did business as usual, we were told we were not doing enough Jira stories. So now we have stories for all the little daily things so we can complete more stories. We do less actual work than we did before, but now we have a bunch of meetings and Jira stories to to prove we do work. The meetings are especially a pain. In 2022 we kept complainng because we were averaing 25 hours per week of meetings. This year we are keeping meetigns more under control, averaging about 15, but it's hard because managment keeps pushing for more meetings and we are constantly pushing back.
You cannot use agile. It's not a verb. Agile just means flexible. It's the manifesto for agile software development. The title, one page. It's not a hammer or a procedure, it's a description.
You speak from my heart. The problem is: even if we come up with an Agile 2.0, if you put the same people in place as before nothing will change (which is exactly why agile is often failing)
We don't need Agile 2.0. I would say that agile didn't fail... if anything, we need to look ourselves in the mirror and open our eyes to the fact that maybe we failed agile. We allowed organizations to pervert it and stood silently by. Perhaps because we felt "we must be willing to be agile and constantly evolving". And while that is a true tenant of agile it doesn't mean that we can reshape agile back into waterfall and command and control and still call it agile. There are core principles on which agile stands that we must uphold and respect. It's ok for an organization to choose not to be agile. But not to claim to be while working against the very foundation on which it rests. I'm trying my best not to be silent and raise my voice where I work now (which is a classic tale of a company wanting/claiming to be agile and spending an enormous amount of time and energy working against it).
I remember, when I first heard about agile and asked what it means (about 10 years ago), my conclusion was: I was doing it (developing software in small iterations) my whole developer life anyway. Now my last project (a European airline) I rage-quitted, and I'm still recovering after almost a year. I already had a burnout (before agile), so I know what it feels like. The description Dee gave fits like a glove. So my advice: If you have a SM who attended a 2-week-seminar, run as fast as you can. Otoh I experienced Safe as working almost perfectly when we had an experienced agile coach. She did not buckle and took everyone to task, also, and especially the stake holders. Once they understood that we (the devs) setup the pace, things started to work. Most important lesson I learned (and anyway suspected right from the start): Do it like evolution does it: Mutate, evaluate, select, repeat. Try things, keep those that work, abandon things that don't work. Forget about "frameworks", they can only provide suggestions, not paths to follow.
Yes, the "agile manifesto" thing was basically good old common sense packaged into flashy marketing. Then it got subverted through unscrupulous "scrum" consultants to mean "slave driving".
This 👆 is exactly how i interpret agile. Do a thing for 2 weeks. See what went well and what didn't. Adapt to avoid the bad things if possible. If you religiously cling to the methodology as prescribed you will not be listening to the team, you won't be adapting and the team will be frustrated and bogged down. We are now down to 2 dailies, are probably going to do a retro once a month, revised the po and scrummaster roles to fit our work and personalities better and we are doing great. Better then before SAFe. We have no need for the archetypical scrummaster zealotry.
@@clray123 The funny thing is that, at the time the Agile Manifesto was written (and Extreme Programming and other efforts were being developed) these sensible ideas had not really become *common* sense yet. It was those efforts which put them together, refined them, and popularized them.
@@errrzarrr It is. But that means you have to let the devs do it. Like I wrote elsewhere: For instance, management has no business in attending the Daily. And that includes the Scrum Master.
My problem with agile is that you're given a certain amount of time to finish something. Then your boss comes and tells you to do so many other stuff on top of your actual task and still expects you to finish your actual task in the original time frame.
Any popular term at some point becomes vacuous buzzword. They realized at some point that developers liked agile, then hired project managers to be Scrum masters. Fake agile became a business in itself and now the term is more nonsense than not. Would love to talk more on this topic!
Here are my two cents on the topic: Neither Agile nor Waterwall will replace good management. Those are tools, and the problem is with the people who are using them. Burning out mostly has to do with the workload and setting realistic deadlines for your team. Wasting time in meetings also has nothing to do with Agile and 100% to do with the people leading the meetings and inviting 200 people to a meeting that needs two experts to talk to each other. Now, in defense of the managers. Being a PM, Scrum Master or Manager is a very difficult skill to master. That said, there is a solution: 1. provide leadership training to every new manager 2. promote a positive work environment 3. embrace feedback from your team 4. be a servant or transformational leader 5. lead by example
I just checked the amount of agile meetings for our Team (using Scrum): It's ~3h a week, including Standups. So I'd say, when teams that have 13h of agile meetings a week, I wouldn't call it a problem of "Agile Software Development", but of ridiculously bad management. "Ridiculously", because the problem is known for years and the responsible people failed to recognize and fix this for such a long period of time now. Love it, change it or leave it.
Yes i agree. Rather than complain, I have solution that I guess I need to make a video about, because Dee does not have her email in her profile, and I was hoping she could create a Zoom community call where I could share my solution and discuss it with other like-minded professionals like you and Dee. I really do not want to make a video, so any ideas on how we can all meet on a real-time group call would be appreciated?
I run very lean Scrumban and it works great. Daily standups are usually 5 minutes. We combine retrospectives and planning into a single meeting every 2 weeks and it is usually done within 30-45 minutes. It works fine as long as the person running it is trying to keep these meetings short and efficient, and the developers themselves are the ones breaking down big tasks into smaller ones, providing their own time estimates, etc.
We have very few standups go less then 20 minutes, and that's only when multiple team members are out. I get really frustrated when a 15 minute standup goes past 45 minutes because people think they need to give a full account of everything they are doing that day.
@@javaman2883 Comes down to culture. Over supervision and not trusting people to do a good job makes people feel they have to justify their time to managers and over explain themselves
@@redf7209 You don't even need a good manager. A fairly incompetent manager is fine if they just _get out of the way_ and let the devs deal with work. Agile "project management" isn't terribly difficult, and the reason it works is because it's the developers and customers themselves, not project managers, doing it.
I feel like this is finally being recognized in the industry but the real problem is that Agile software has evolved to the point that it can be used to micromanage developers and obtain metrics for evaluating performance, and leadership loves this. I recently had a conversation with my project manager in which he said that he thought tickets could be written to account for activities as little as 15 minutes so that developers’ entire days can be accounted for. I didn’t use the word “micromanage” but I did use a bunch of corporate double-speak to tell him that exactly what he was doing and in no way that would possibly be productive or encouraging. Not only is that demoralizing, but it’s a very wasteful use of a developer’s time because of the overhead cost. Sometimes we need to stare out of the window and think through a solution for some time. We are not robots.
Macrosnooping 😂 Also, it takes time to create all these observable tasks which probably do not factor into the overall ‘productivity’ time calculation. Leading to an expectation that people work as many hours needed to get the job ‘done’. 6 hours vs 10 makes no difference to the company... Except, it does, loss of focus, context switching, hyper-communication of intention but reduced time to deliver, all negatively impact the company, and so more initiatives are used to manage and control. It’s a way to deskill (by devaluing) the worker so that the company can think of and treat them like replaceable resources, rather than integral, because would the board think if your workforce were integral? 😮 I think ultimately, business don’t have a way of thinking about their knowledge workers, they aren’t competitors (but they could run off with all your inside secrets) they aren’t customers (although you constantly try to sell them the idea that this company is the best xyz, or we’re family) so companies kind of have their workforce as hostile but necessary partners to deliver a goal and there’s just no good model out there which bucks this trend and delivers (whatever ’delivers’ means to a company + the knowledge workers). BTW knowledge worker, doesn’t just mean tech, it’s anyone who has specific knowledge to carry out tasks to achieve a goal. And those goals drive revenue for a business.
@@youtubeplaylist6374 Heart felt and well understood. I am pretty shit hot at what I do but management forcing it to tiny pots for no good reason never made any sense to me. The last little tin pot hitler couldn't even to be bothered to come to my retirement sighn off. I think Industry / Business is pretty nasty everywhere, stuff like agile just gives the incompetents something to hit you with. Owners buy into Agile not Workers who do the actual graft. Would you et the brady bunch choose team leaders? But they do because of belief in bull , weak will and just pure incompetence, which is for why their companies fail. Show me a company appointed team leader and I will show you a failed project.
Yup, all these "frameworks" are to get metrics on developers so they can be controlled by performance reviews that are heavily documented, make the managers look effective, and help human resources that loves documented performance to justify a layoff. Under these frameworks, the developer is sweating to keep up with the clock and not really focusing on their work. It is a self fulfilling prophecy to damnation at that point.
I have been a dev for over 20y and a year ago started to work for a company which does the scrum stuff. Your video exactly shows how I feel about it. Biggest problems are the constant meetings. When I started and I saw my calendar, I thought it was a mistake. It looks like I am a some kind of busy business man with million of meetings. I feel burned out. Already searching for a new job, but most of the companies nowadays use "scrum", which is depressing.
I retired four years ago early at 57. Mainly becuse Covid was starting, but also because of the Scrum/Agile/Kanban/Jira nonsense. I was a contract engineer at the time. I started turning down offers when the following happened: I went to a company where 8 developers sat in a room with 2 rows of 4 desks that faced each other. No cubicles, not even low wall ones. I called it the Lord's Table. Our work area was also the Scrum meeting room. Every morning we had a Scrum where we were told to stand at our desk for the entire 15 minute or so meeting. The "gods" as they clearly thought they were (office dwellers) came in too, along with the project manager (PM) who was also the Scrum Master. I had to endure standing listening to what other people were doing but I could not collaborate with them during the scurm so it was total waste of time. I asked the PM if I could sit during the Scrum and stand only when I gave my "status" because of my arthritic knee. He said, "No! Everyone must stand at the Scrum". We didn't have phones on our desks, we had to use our personal cell phones. The office dwellers would come into the room throughout the day and have meetings STANDING OVER US AS WE WORKED AS IF WE WERE NOT THERE. They made us feel inferior and it seemed on purpose. They had big offices where 3 guys could have a meeting, but no, they had to "invade our workspace". I told the other developers, I can see them doing this to a contract guy like me that is just there to get them through a tough time, but you regular employees put up with this? Just then an office dweller came in puffing out his chest telling us to be quiet. One of the developers told him just go back to your office and close your door - we don't have offices. That started a huge argument between everyone the room and a couple more office dwellers. The tension had been building for some time but nobody said anything. At least one developer was burnt out and a zombie. I had to call a colleague in a differnt facility. I was told the guy I was calling was a real jerk and to use the "phone booth" room and close the door. They other 7 guys had a pool as to how long it would take for me to get upset with guy on the phone.. it was 5 minutes and one guy won 50 bucks. This kind of stuff kept their sanity. This was my SECOND day there. I walked out. Management was annoyed. I was told 2 other guys quit right after that. I told my contract agency (that was angry with me for walking out) all of this - focused on the known jerk in the other facility. A month later my contract house called me that the guy they sent to replace me reported the exact same situation - right down to the jerk on the phone. They said I was exonerated and they had another assignment for me... I passed.
Scrum is incomplete by design. Only bare essentials needed to foster the foundational notion on which Scrum rests are prescribed and each team is to find complementary practices that best suit them and their context. Let's pretend we do a three week sprint cadence. Then you would have a 15 min meeting every day and on top of that you have a planning session, review and retrospective that would take up a couple of hours each. That's it. Those are all the meetings in Scrum. Have I been in organisations claiming to be "agile" and "doing scrum" where my entire calendar has been filled with meetings? Ohhh yes. But that hasn't been the fault of Scrum, if anything it has been the fault of the organisations unwillingness to let go of the old processes. Scrum has simply been added on top. Instead of enabling the teams and putting trust in them to make decisions control is sought by management resulting in a bunch of reporting meetings etc. Most of which fly in the face of agile and Scrum.
@@DanielLiljeberg I was so annoyed with the meetings in my previous job that I decided to start writing them up in secret. When did they start, when did they end, how much time was spent, now many participants, which participants etc. I came to the horrible conclusion that I spent more than 30% of my weeks in meetings on average... usually evenly spaced out during the day so that the only time I actually got any work done was when I arrived early in the morning. Whenever I got back into the groove there was another meeting... but of course I was expected to complete my tasks regardless of the meetings. Was that the fault of agile or scrum? Maybe not, but today if a company even mentions that they are working with scrum or agile I am running in the opposite direction.
I'm a junior programmer. My company's daily meetings last at least 90 minutes, even more, other meetings are the longest. Each spring developers are scolded because the objectives are not finished. Each time we are asked to estimate the difficulty and the time to complete a task, the estimates are divided by two or three, and we are given these revised objectives. Before each PI We have the right to a speech about technical debt. But when we say that there are too many meetings and the objectives are unrealistic we are told that this is the method and we must follow it for more productivity. Sometimes I am fed up with it, even if I love to code.
This has nothing to do with agile. This is a sign you work is a dysfunctional environment with managers who don’t understand what’s going on. You either have to become an authority there and fix it or move on. Your work place is broken, thus the work you are doing is broken.
Agile scrum doesn't work because what it INSISTS you do in the development lifecycle is diametrically opposed to what engineers need to write good software. I'm a Senior Software Engineer with over 25 years of experience writing software. What I need to deliver good software is: 1) Thorough requirements and technical documentation. 2) All dependencies I have on others to be completed BEFORE I begin my actual coding. 3) Uninterrupted time to write the code. What I get is incomplete requirements (because : iteration), unfinished dependencies sometimes with no estimate on when the dependency will be completed (because: agile!), and constantly being pulled off sprint tasks to deal with troubleshooting prod problems or do hot-fixes for high priority bugs (because: management). And for the Agile Kool-Aid drinkers....don't start with the "OH NO! YOU CAN'T GET ALL REQUIREMENTS UP FRONT!!! THAT'S WATERFALL!" just know this: Not being able to get ALL requirements up front is not an excuse to not try to get as many of them as you can upfront, and just screaming "WATERFALL! WATERFALL!" doesn't mean it's a bad way to proceed. Seriously, get over yourselves.
I can’t even agree with this enough. The amount of meetings we attended were just ridiculous. I probably only had about 1 or 2 hours per day to do any development work.
My worst agile experience include pointing sessions (with official pointing cards), estimating meetings, daily standup meetings (where we were required to stand up), “ceremonies” where everyone did a presentation of progress, and the retrospective. Also, there were project meetings with team members to discuss what actually needed to be done. All we really needed were the project meetings and updates to Jira.
Same. Constant meetin. Standup, prepare planning, discuss with team to help them to finish their ticket. Validate each step with QT, UX, PM. Changing the color of a button takes more than a day!!!!!
@@joanvallve7647 dumb people love things that simplify into a set of rigid rules that, when followed, they think will produce the best results. Religions, economic theories, etc., are all designed to make a complicated world simple. Trying to apply one thing to everything is a sure way to do the wrong thing.
Thank GOD someone is finally saying out loud what I have felt for years. Businesses are like misguided children these days and hop on whatever trend comes along without question. The best project managers I have ever seen are ones who have done the job (or similar projects) for years, have experience and knowledge and can guide the process because they have been thoroughly involved and understand what needs to be done. These people know how to get from A to Z... not like some dork with a spreadsheet who thinks if you ask the right questions, you can manage anything whether you know anything about the project or not. Just an example... I interviewed with an IT project manager once who looked at my resume and said "Oh, you know how to do this? That's good because honestly, I don't know what it means rack a server" What? How does someone like that become an IT PROJECT MANAGER? 😠
It's not "these days" - it's been this way forever - I can't even count the number of fads I've been through. In my view it's some combination that is tuned to the team/task that actually works best. From the "Rational Process" - centered around RationalRose, to something the Clear Case folks defined, honestly I've lost track. I remember back in '94 Peer Programming became a fad and Fidelity tried to get us to use it... we all unanimously said NO WAY - but NASA uses it! 😄
Because IT Project Managers are often not technical. This is often a problem because while they can organise tasks they don't have any appreciation for what is involved in that task. This means if the person allocated says 10 days to do it, they just accept it, even if, in reality, it's 2 days work...or 200
I'm working for a very small team inside of a huge enterprise that *claims* to be "agile". In that team we practice *actual* agile, bottom-up, continuous reflections, no standups, one scheduled meeting per week. And we're moving *fast*. Faster than anyone thought would be possible. And I understand why a lot of managers hate agile without one of those frameworks: their position becomes questionable. Who should a manager manage if the developers manage themselves? The other reason is: true agile works best when you have devs who are mostly senior and/or passionate. So what do managers do? Hire juniors, who are cheaper and need guidance. Thus managers add scrum/safe to have pretend-guidance, and keep their jobs. A huge W for managers.
100% agree. Good Sr devs make managers worse than redundant. It puts managers in the position of getting in the way, slowing everything down and being one more mouth to feed (useless pay check that could go to more or better Sr Devs)
My dream company would be the inverse of this top heavy clown world where there are like 2 highly productive developers for every 8 useless people... it should be mostly a company of Architects at the top, then senior Software engineers... and a small sprinkle of HR people for recruiting top talent and paying them very well so they want to stay and are self-managing and passionate. Architects can do the job of project manager but the Sr Devs should make it light work because they're self organizing. Tech leads are also good to have a clear chain of command to resolve disputes quickly. I'd run a lean company so that the budget can be spread amongst a smaller number of highly productive team mates rather. Quality over quantity... large dev teams don't scale anyway!
By the way... I am now living in Brazil where living costs are cheap. If you want a good worker for cheap - I'd gladly leave the shitshow I currently work at... I have 5 years experience as a SWE.
In my 6 years of working as ux designer, I was baffled by the resistance to do even a 'simple' ux research such as interviews or observations with a target group at the beginning. And Agile was one of the main reasons for such a mindset. No wonder the products we worked on later failed miserably. And I ended wirh burnout.
Because the worst people to get detailed requirements from are the users. Believe you me, beyond the basic functionality, they don't know or care about what they want until you actually give them something. Then all of a sudden they know - and always did apparently - exactly what they wanted. If you're doing this on a routine basis you'll never get anything finished.
In my 25 years as a developer, and most recently as CTO, I can tell you that it's a huge waste of time. The users are terrible designers and will make a lot of bad suggestions. It's much better to simply ask them what they need on a non-technical level, and then design it yourself. Once they get to actually use the UI, they'll be able to tell you what they find inconvenient, and you can iteratively improve it.
Agile should be called rigid. Anyways how hard is UI anyways we literally have 30 years of examples to take inspiration from from games to apps to websites. Find some you like and use them. Nobody is going to give good feedback unless theyre more intelligent and capable than you.
i (a software dev) now work in a company where the upper management wants the software division to use Agile, but no one in the software division wants it. this is a nightmare. since the upper management knows nothing about Agile, and the ones tasked with implementing it, hates it. we are forced to do everything wrong, and are afraid to tell anyone.
I worked at an internet news magazine one time, one of the founders came back from a sabbatical and said something like, “Maybe we should switch to Ruby on Rails, that seems really popular.” It was ten years old at that time, and it was clear from the many disparate components and lack of any real design much less documentation that this actually had a chance of getting attention! What was it Jobs said, allegedly… “It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.”
Hmmm...the best software developers I've work with (45 years experience) prefer Agile...perhaps your company is not doing it right...the least experienced tend to not like it because it holds them accountable, forces them to more transparency, and dates matter.
@@errrzarrr, the Manifesto is actually anti what you suggest...but the point is well taken...management is wrong to demand Agile without the team buying in...if most of the team hates it, then one of two things: (a) they have little experience doing Agile correctly, or (b) too many juniors on the team, or (c) they are afraid to expose their lack of competence, lack of skill, or lack of drive...such people hate accountability, transparency, and being held responsible...or (d) management sucks.
When I was first introduced to Agile many years ago, sprints were 1 month long. I miss those days. Also scrums were 2 or 3 days a week. This was doable. But now sprints are 2 weeks and standups are every day. I don’t think management realizes that a 15-minute standup wastes at least an hour. If you start work at 9am and standup is 9:30, you’re now sitting and doing nothing because you can’t get deep in to coding for 30 minutes. Then standup rarely lasts only 15 minutes. And then after standup, it’s bio break and a drink. Now most of the morning has gone by. Then we have backlog grooming, planning, retros, etc. The point system has never made sense to me and means something different to every SM I’ve had. But then you also do hours for tasks. Let’s stick with one metric please. If 13 points is roughly 1 sprint, then just say 2 weeks instead of 13 points. And honestly I have never seen an accurate estimate…ever. You can say it will take 1 week but it takes 3 weeks…or maybe only a day. I should stop ranting now lol.
You're absolutely correct. Business has always been challenged with traditional software development methodology because management has too little ability to track progress in near real-time. Agile flips this on its head by introducing "micro-inspection" (and hence micro-management) at the cost of inflicting "death by 1000 cuts" on developers.
As a scrum master, it's to make yourself obsolete. Train the dev team to work together and on their own, train the product owner to effectively figure out what the client wants and teach everyone how to refine into atomic and well defined user stories. Once the machine starts rolling, get out. Go to another team. If there is a scrum master for a long time, it means that either the team is not willing / able to pick up scrum, or, more likely, a bad scrum master.
The SM is the interface between the Dev Team and the outer world. The SM is also the lubricant in the team. He/she is there to avoid or help overcome impediments. The SM is the guardian of the agile methodology, the guardian of the team schedule, the guardian of the procedures, the guardian of the team rituals. The SM is the guardian of the memory of the team and the project. That's some of the tasks of an SM. Yes, I've been a SM in a scrum/agile team before 😉
A study indicated that people trip and fall mostly at the first or last step of stairs. And it further suggested that we should remove both these steps to prevent people falling. 😅
I'm a CSM. And a SE and Architect, 30 years in the biz. Agile is a way for consulting companies to make $$$. Most companies do not even do full Scrum, they use daily standups as a way to micro-manage. Full scrum has roles that (barely) make it work as a methodology. Remove those roles (program manager for instance) and failure is inevitable. I did just fine for twenty years prior to scrum, using waterfall and then rational unified process based on use cases. Use cases worked, and identified wtf you were building. The fallacy is that scrum produces working software. It may produce some software, but it rarely produces what the end user actually needs. It also makes engineers have to basically apologize (in toxic environments) for research spikes, requirements gathering, architecture or any other fundamentals of software engineering for which there used to be formal process. Software engineering practices are on the decline. See 737 MAX, and be very afraid.
As a former Dev, now CIO/CTO, we do Agile Lite. We let the customer (internal employees) stack rank, we build what they want in "functional phases"...maybe you call that Waterfall, Sprints don't have a deadline decided by me, it's not 2 weeks hard and fast, and we work our backlog. We have happy customers getting what they need and have measurable progress. You don't have to buy into the cult. Maybe the sprint is 5 days, and maybe it's 3 weeks, I don't care, and why should you? In either case, we have to stack rank so the customer feels they are getting the value, but outside of that, I'm not giving you a full delivery schedule because your requirements are not fully qualified. People can't articulate requirements until they use it, so we eat the elephant one bite at a time.
This is exaclty the format I use with my team and barring any blocked work, we are always releasing new stuff that our internal and external customers asked for.
Great video. In my experience, agile/scrum is misused far more often than it's done right. I was on a project where they had daily scrum meetings consisting of 20+ people, over half of whom were participating from a remote location by phone! Somehow we managed to get products out the door, but it was in spite of project management, not because of it.
I don't really think we should move from agile as the title suggests, but as you say in the video, we should move away from over-zealous implementations of SCRUM. In my team Agile works and is not overwhelming with meetings. We do have them, but they don't get in the way of day to day work and we have a reasonable approach to it. But SCRUM in other teams is a messy burden that makes use of three different project management tools and has their members sitting in meetings all day. In other cases, some teams just have waterfall disguised as Agile. At the end of the day, agile methodologies are a lot like programming patterns - tools that can help you do your job if applied correctly. But as with programming patterns, if you follow them dogmatically and don't properly assess your actual situation at hand to see what fits best, you end up making things harder for you.
Yes. We need a better management culture and for managers to actually understand what they manage, not moving on from agile. Agile is an instrument, not a silver bullet. A lot of "agile" I've seen was a combination of worst attributes of agile and waterfall. You have a two week long spring, 1 hour daily meeting with 15-people team and everyone talks about everything but nobody offers any help to others (it's too long already), documentation is not done at all, there is not sprints or tasks for tech debt, budget and features are per-planned for half a year, nothing ever gets removed from any sprint, and any extension of time goes with increase in scope.
@@MikkelzuI think I remember watching his video on the topic but don't remember the details. His videos are hit or miss for me in terms of how agreeable I find them. But your summary doesn't sound good either tbh. "Getting shit done" without catching up with colleagues regularly is also a recipe for disaster in my opinion. A good team is aware of the work as a whole and its status and can react appropriately. A lot of the times it happens that I hear something on a SCRUM that I know something about which then allows me to provide input. To me that's healthy. Our stand-ups are rarely longer than 15 minutes of the work day, so I hardly consider it to be a barrier in the way of GSD. As with most things, it's all about balance
@@MikkelzuWorth noting is that my impression is that Primegean is a very code oriented person, but being an engineer extends way beyond how many words per minute you can type and how efficient you are with VIM. Most of the work in my experience is discussing and understanding requirements and making sure you got them correctly, so meetings are a necessary evil
@@vlad-rs8pb Same for me on his videos. My take on GSD being better is a bit nuanced but overall I agree with some aspect. I think a standup is fine (as long as it doesnt devolve into chatter), and periodic review periods as a team to check if the direction is still right etc is also good. However I dont believe that sprints, retros, refinements and the whole shebang is necessary at all. I think if a developer has a blocker or needs help that the first case should be low barrier communication to ask for help. Now, at my work at least, most people just wait 3 days for the 2 hour long refinement thats planned in when they have a blocker of some kind instead of asking me or another senior for help. GSD with periodic communication and letting the bureaucrats do the bureacracy is to me much more productive than forcing a group of developer to spend almost 35% (if we look at the example in the video by Dee, the reddit dude with 13 hours of meetings) of their work week on meaningless meetings. I will concede and say i am a certified agile/scrum hater and I will probably never see the appeal of it after having worked with it in such a misappropriated way
You hit the nail on it's head. I have almost two decades of experience in Software development. I have not yet met a developer who cherishes or looks forward to going to in to these meetings. That says a lot how developers feel about these blood sucking, life expectancy diminishing meetings.
I think its a huge issue that developers, look down on meetings and communication as much as a HUGE portion does to day , also lack of documentation and want to work all the time like at home making a small hobby project for themselves. Tje resistance to whow their work and sometimes even sabotage is part of why the meeting size and numbers grow because there is a huge culture of unprofessionalism and even antagonism. It makes an impenetrable wall that makes it hard to work as a unit and even harder to make a good org that is more than its parts.
@@michaelk.jensen1611 there are developers that have to high of a sense of value for themselves.. and also a developer that refuses to communicate is one that will soon have no job. But on the other hand the excess of meetings can cut into valuable development time. Can't get that feature done if you keep talking to me.
@@acasualviewer5861 what I'm thinking is that part of what creates a lot of meetings is this culture and dislike for meetings and communication. Then as a consequence of that, meetings increases because people feel they are walled out and not in the loop , or other ways. So I believe that mindset actually might be part of why there are more meetings. So in effect the dislike (that I think often are kneejerk like reactions) of meetings and communication is a significant factor in creating even more meetings.
@@michaelk.jensen1611 interesting perspective. I do agree that sometimes rather than looking through a PR for hours in Github, it might be easier to just have a call with the developer and have him explain the code to you. Saves everyone a lot of time. Being too afraid to have face to face contact is not healthy.
Thank you, I appreciate your thoughts! Agile is not the holy cow. A process must support the business - it's not about using blindly a methodology. If your process doesn't work, change it, reflect, adopt, repeat. I don't think there is a one-size-fits-all methodology. As PM I'm always trying to force the business side to come up with concepts which are well-thought through because one of the issues I see is that we loose planty of time in requirements discussions once we started coding. The business side is often misinterpreting agile with I-can-change-my-requirements anytime in opposite to waterfall where proper specs are required upfront. We have a lot of people in the middle and upper management who actually have no idea what software development and engineering is about. But these people are often the decision makers or "owners", they naturally need more communication and therefore meetings. I really blame mainly the business side for the explosion of meetings in software development. But again, if your process doesn't work, escalate it and try to change it. Otherwise I only recommend to consider looking for a new job. Don't waste your life in stupid meetings and boring companies 🙃
I dont blame business for the explosion of meetings. I blame middle management 😂 Tell the person who controls the budget that your team spends 32% of their time on meetings - and you’ll get their full support to cut those numbers down 🥲
@@ChiTheAesthete it’s their job to be in meetings. But if ICs are spending more than 15% of their time in meeting, there’s an argument to be made. If it’s 30% or more - even a way stronger argument 😁 it’s like hiring 10 devs but only 7 are working 😂
Great video, really like your approach. So recognizable. My 2 cents: it is fundamentally wrong to see ( by the managers ) , agile is something for the team to execute. It is however in the first place for the managers to come into action, removing the impediments and making themselve not needed any more, creating a real agile environment. If there is real self-management made happen, there is no pressure. If a team can operate independently, there are no further alignments/meetings required. Agile is not about practices to do, but about creating an environment that makes it possible!
My two cents. Agile exists because no manager can justify spending lots of time to write proper requirements, without producing any code in the meanwhile. Unfortunately Agile started to pop up in the aerospace field. Very scary.
Waterfall is soooo much easier. The basic idea is that you write the documentation before you write the code. You might have to revise the documentation several times before you are happy with the design. But revising documentation is vastly easier than revising code. And when you get to the point of writing code, your job is easy and fun because all the technicalities of have been well thought-out.
Can't say I have ever worked on something so simple waterfall really worked. Documentation was hundred pages+ and it always became a hell of changes after a few months due to changes of requirements as well as additional knowledge gained doing development.
Waterfall had many issues. But I agree it was not evil like Agile is. It is evil from it's conception. Agile manifesto is on some extent BS because it focuses on developer's empowerment while ignoring the fact that software is just a tool wich serves purposes developers mostly donesn't understand and doesn't have to know either.
@@joanvallve7647 what is evil in agile? What makes you think it is focused on the developers? And why do you think developers do not need to know what they are building? Personally I think the biggest problem with agile is that it is not there to give the business the information they really would like to have: what they get, when they get it, and what it will cost. It is a methodology to give business a way to steer development accepting that this can't be estimated with any precision. Unfortunately many think it is a methodology meant to answer these questions - and then it goes terribly wrong.
@@lmoellebI can tell you that I work on medical devices and iterative waterfall is the way to go. You cannot deliver safety and quality in 2 week sprints. You can call it stretched - out agile, call it FRED, call it whatever you want. You've got to do up front design, documentation, prototyping, BEFORE showing to customer. Especially if customer is an MD or surgeon. They tend to be high ego people and surprisingly ignorant of the effort involved in making a safe and effective product, unless they've done it before. "It's got to be easy to use" they say over and over again, as if we don't know that. But it's got to be safe as well, and that costs time and money. Testing, unit tests, CI/CD, static analysis. You can sort of stuff this into a scrum framework, but get rid of the word sprint. Because if you sprint! You're likely to fall and twist you ankle....
@@lmoelleb The problem is right there, hundreds of pages. Those do not get written by experienced developers analyzing the project goals and matching those with the actual data, but by non-developers and other corporate bureaucrats. Based on unverified data and promises of data to be delivered in a certain way, nothing is tested in advance. But with Waterfall done right, it is smooth sailing and you start with a working model that has proven the data fits and can efficiently supply the project requirements. But when it is done badly at the start, it's just as much a mess as with any other development method.
I totally agree except for one thing. Scrum/SAFe is not the only way of Agile; they are frameworks that are almost anti-Agile. However, they call themselves "Agile" because they are like a Trojan horse within Agile principles. A good methodology that fits Agile principles is Kanban.
I would argue Scrum can facilitate agile product development very well (unless it is on theatre ofc). If I have a flow of work, Kanban is often a perfect fit. But if the mission is to develop a product in a complex environment Scrum tends to work better. The empirical inspect and adapt cycle fits well with iterative workflow in close collaboration with the customers/users. We form a hypothesis, we test it and make decisions based upon the outcome.
BTW - I just don't go to meetings I have nothing to contribute to. But... I'm old (see another post on another of your videos) so no one cares if I am there or not. I keep the stakeholders apprised via written reports. If anyone has a question, they have my email address. Also, I have that exact copy of the Agile Manifesto that you display on my wall (I have acted as a Project Manager in many different development paradigms). The comment 'too many meetings is too many meetings' is an extremely cogent point. Years ago a manager of mine had a poster in our meeting room that suggested "Don't let a meeting become an event where minutes are kept and hours are wasted". I have always remembered that.
I coordinated the V DevOps life cycle (Waterfall framework), and I agree. The department integrated continuous integration (a precursor of DevOps) to respond to customer needs outside standard development. Nowadays, with a misunderstanding of the Agile framework (used as a micromanagement tool against people, not for products), you have too many meetings for a few valuables at the end. The tests are not done correctly to satisfy the desire to go on the market quickly. Then, you have the customer feedback several times. The product is not implementable: there are too many significant errors or bugs.
They force agile now in cybersec too unfortunately... Which obviously works as terrible as one may think. Source: I work in cybersec and some projects are run in scrum/agile.
@@dmitryurbanovich4748 We have a project, for example, to improve/review existing SIEM and to implement SOAR for the client. And along with it goes the design and the documentation, there are calls and discussions - and that's where agile comes in - all that preparation and actual implementation is in sprints and daily calls. Believe it or not, but did some projects where there was even retro xD At least we don't measure effort in story points.
@@dmitryurbanovich4748 Sorry, didn't notice the comment earlier. Basically, if you provide cybersecurity services to the client - e.g. the migration from one cybersecurity platform to another (EDR, SIEM, firewalls), then that whole work is being tracked using scrum. There's spring splanning, kanban board with tasks, daily stand ups etc.
My main issue with agile is in how many startups and small companies use the small iterations to replace the need for a plan or documentation of one. Many simply don't have a specification of requirements for version 1.0, or 2.0 for that matter. Without that specification it becomes virtually impossible to also set up a test plan for QA to go through before signing the release papers. Developers don't necessarily like to document too much, but if you're supposed to work in parallel it helps to "waste some time" at the beginning by specifying the overall goal, also to prevent scope drift. I was educated in the old IBM-style waterfall method, which is also tedious and feels slow, it's not perfect, but it allows for a complex component taking longer than many of the smaller ones, you don't aim for having a fully compilable version every week. You just make unit tests according to specs, and then all the pieces are supposed to work when they're ready to be put together.
In the last 12-15 years, I've seen many agile teams, and had agile forced on my team a couple times. I've never seen agile work. I don't think I've ever seen it done following the manifesto properly either. We've kept a few of the ideas but changed them. We don't do daily scrum. Weekly. Sprints are a quarter. Sprint planning and grooming are done annually. What do we do when work comes in and needs done sooner? Manager decides priority. We also do a weekly status report. That report takes a few hours because its not really just a report, it is a weekly presentation to the exec management. They want to see 50-100 of these each week, and go through them quickly finding blockers, issues, and who is doing actual work vs. pretending. Every "Agile" project I've seen goes about 268% longer than planned.
Be careful not to confuse agile and scrum. They are not one in the same. You can be agile and not use the scrum framework. And doing scrum does not make you agile.
Like politics, the biggest problem is when companies allow and promote people who actually want to manage others...to manage others. That one attribute should spell immediate disqualification. If dev teams are to ultimately 'manage themselves' then managers need to be promoted, by force if neccessary : ), from within the dev teams themselves.
Was a PM in video games for 8 years. Used only what we founf usefull in agile : Scrum planning/review (merged), scrum meetings. We created highlevel stories and the teams broke it down in tasks. Agile was not used to micro managed at all (PMs in video games don't have time for that). No idea what all the other meetings you mentionned are. Maybe a Director or team lead had an extra meeting here and there but it's part of their job. I don't remember one team member complainning about having too many Agile related meeting. We used waterfall for art and Agile for tech and it worked pretty well.
So true, Agile is what businesses use to hide the fact that the really have no committment to following a methodology and just want to hide the fact that they operate from the top of the organization by the seat of their pants. The Agile problem is compounded by ignoring the reality of development personalities. Extroverts migrate towards management and they feel like they are doing something by warming seats in meetings. Meanwhile the real developers - those who actually do work - are forced to waste time in unproductive meetings where - as typical introverts - they get so bored that they zone out. In my long career the only methodology that I saw produce real high quality products is the data-first Structured Engineering that we used to survive Y2K. But it requires true commitment by the corporation and proper training of all participants, including some from the business areas.
I dont agree with the title but I do agree with what you say in the video, Agile is the way to go imo but if the management misuse it and doesn't implement it right it will hurt the productivity,
I am a Scrum master. It was going good in my company and developers were happy with the sprints. But one day the company implemented Agile 2.0. Since then we are just following scrum ceremonies for the sake of it and micromanagement is at peak. Burnout seems a very small word to me.
We have project managers, senior project managers, product managers, group product managers, product specialists, sr. product specialists, SCRUM masters and agile coaches on the IT side, NONE of whom can write a line of code or even a SQL query. And we are proud of it. :))
I am so thankful that I am old enough to have missed the Agile and Scum methodologies. I am old enough that we used the Waterfall methodology combined with common sense and small iterations It worked well and was responsive to customer feedback. I know little about Scrum and Agile but every time I learn something new about them, I just shake my head.
"Small iterations" and "responsive to customer feedback" are the core of Agile. It seems like your team - just as countless other teams - has invented agile software development 🙂
Same experience, I hate agile, I hate SCRUM, I hate SAFe Agile, I hate PM's, I hate Scrum masters, I hate grooming meetings, I hate retrospective meetings, I hate it all. Will never go back to those type of companies.
I agree... But 95% of companies want you to do Scrum and SAFE. That sucks. I miss the good old days working with waterfall approach (no meetings at all).
You have some validity in most of those opinions. You also have to keep in mind that if you hate reflecting on how you can do better or mistakes you have made, ie retospective, are truly an engineer?
Dee, good segment. The mythology transition was all about speed of delivery replacing quality. The complaint, in my day, was how long it took to get a "FIX" for a newly discovered bug. The reality was different of course. The level 3 (SW engineer owning the product) would VERIFY and identify the failing code, and then generate a fix that was released as a BETA software install. The grand issue was that the (Agile Software) fix required regression testing to insure no unexpected behavior changes to the code and a BETA site sign-off. It was the NEW kids pushing the Academic Agile Software development as a way to get rid of the PESKY Documentation, Installation process development, Installation Testing installs, Regression Code Testing, Release documentation, Release to BETA approval, BETA site buy in for testing and sign-off. They just wanted to develop and throw it over the wall, respond to it's broke, develop and throw it over the wall etc. Essentially making the user the software testing manager with the production site being the software testing environment.
Such a great video, thanks for sharing your thoughts! I’ve worked in product and project management (15yrs!) and now a re-skilled as a developer, so I can see both sides of the argument! Agile is not the problem, but the interpretation of it, is what causes so many issues. Biggups!
I'm not a software dev, I've just recently started working in a dev-ish role and because of technology migration I'm working in two projects. We all here do "agile". My main team works closely with our PMs, we have 2 status meetings every week, and one sprint planning every two. They usually last less than 15 minutes. In the other project, I have a daily status meeting, usually more than half an hour. It's still way less than people describe, but even that is a bit much for me. Status meetings aren't the devil - some people do need to have frequent checks or they'll start to procrastinate - that includes me. But I find that talking about what I did every day is useless as the tasks take more time and I have other work to do. I very much prefer the rare meetings and being encouraged to actually talk to people if I have any questions. I know that if I have a meeting next day, my questions will just wait for that and it slows my work down.
People love to hear their own voice. I was a brutal dictator as the scrum leader and kept the discussion as short as humanly possible. What did you do yesterday? What will you do today? You have at most 90 seconds. Snap snap around the group and out of there. Any other issues are dealt with after people are set free. Meetings suck the life out of the team. People only needed to know what others were working on so they could collaborate that day. Pure agile, where programmers were assigned to random tasks each day never works. Developers have specific skills. The write the test first and then write the code worked perfectly. If done well, agile works. The problem is that people will slowly revert to long meetings and too many meetings and old habits and it can collapse.
I've done that too, and the other folks loved it. But that breaks down the moment some manager above me muscules his way into the meetings. If I can't (politely) shut him up, it goes to hell. Even if I can shut him up the first few times, before long he feels a need to Exert His Authority. It surely goes to hell after that. Then I encouraged team members to set up their own ad hoc meetings as needed, including ONLY the relevant folks, when something needed to be worked out. That works until the manager gets wind of it; then he'll insist in being invited to every such meeting - which derails them. Then the only route left it to have ad hoc conversations with the relevant folks OUTSIDE of any 'meeting'.
Wow, I just came across your video. I retired from a large company several years ago. Before retiring, I was part of several Agile projects for a few years. Your video and many of the comments here bring back so many anxious feelings and not so good memories. It’s like I time-travelled back to that time. I never felt that our SCRUM meetings were worth all the time that was devoted to them. So many times I said to some colleagues, just let me get the fricken work done! Stop wasting so much time talking about doing the work and just get it done. Endless meetings, even about the smallest of things. I frequency felt stressed and lots of anxiety. Finally, I would get to the end of the workday and then think I have to do the same non-productive crap the next day. I hope I didn't offend anyone here. Thank you for your video. It's nice to know I wasn't the only person who felt this way!
I agree 100% with this, agile is not the problem, is how 95% of bussiness implement it, and it comes to this: Bro reads agile manifesto and it says "Individuals and interactions over processes and tools", bro flips it and it goes like "processes and tools over Individuals and interactions ". Scrum master is indeed the herper of agile, because is the perfect plan to enter the tech industry without knowing a crap of it, Just give to an SM a team of devs so he can micromanage them and get paid for it, profit without writing a single line of code.
Please can someone tell me what "Individuals and interactions over processes and tools" really means in any material sense. It's like saying "you must go down before going up". That's the problem with agile it really has no meaning. Development of any product of any meaningful size has always been done in cycles. The Waterfall method is just something dreamed up to justify agile and subsequent consulting.
@@charlesd4572 The agile manifesto is really a compendium of best practices to any given project of any nature, is not strictly reserved to software engineering, that why is so ambiguous, but if you want to narrow to what devs do on agile teams it's not complicated to understand: for example, "individuals and interactions over processes and tools" in SWE is really putting devs needs over the ceremonies of, let's say scrum, that in practice means "we don't need your freaking meetings, let me do my freaking job". Like the video said, one of the main issues of scrum is that there is too many (ofter useless) meetings, and maybe you can skip some meetings that aren't that necessary, more if you're short of time to meet your sprint goals. Some SM and managment evangelize so much scrum that they don't care if meetings took 40% of your time and still you're asked to meet your sprint goals, that's why almost every dev hates scrum. The framework should adapts to the teams needs, maybe we should make that daily meeting twice a week (change the name if you want tho), maybe that 1 on 1 is not neccesary, Jira can do the backlog grooming automatically and maybe we don't need that meeting either. Frameworks adapts to devs and not backward, "but we need to have those meetings if not we're not doing scrum", well, we're not then, and screw scrum and screw the SM and screw managment, I need to do my freaking job so bother someone else with your little meetings.
Some people just want to have meetings all the time because it makes everyone feel important. If you bring up the fact that there too many meetings, they'll schedule a meeting to discuss it.
I remember when I was new on a Team, my first Dev Job. I said after a few months that we could make things better and gave two examples. Instead of just doing that non bureaucratically (or reject it) we scheduled a monthly 'retrospective'. I did not knew what it was and said: Why we do not JUST decide to do it or not, like the Agile Manifesto says? But I thought maybe they know more. On the Retrospective it was awful. When any of us brought on a topic to change, one of the other blocked it. Learning: I wanted to change something, it resulted in a 2+h time waste every month.
I never had to suffer under Agile, so I can't comment to that. I did go to a lot of meetings in my career. Your discussion reminded me of a colleague at my first workplace, Texas Instruments. His name was Art. He was an affable and extremely knowledgeable guy. He became my go-to co-worker when I had a question no one else could answer. I eventually noticed that every time we had a department meeting, Art was never there. He wasn't absent or sick. He just didn't go. Ever. Except once when he was getting an award for his excellent work and was asked (begged) by his manager to attend. I eventually asked him about it. Art replied that he didn't find it useful to go to the department meetings as he never learned anything and he was better off spending the time getting his work done. I concurred, but I was way too lacking in cred to pull off the same stunt. Art was so invaluable to the department that he just didn't give a flip about what management thought of him. Art was my God.
I cannot complain: We are a small team of 4 devs, 1PO and 1SM and doing Kanban. Our iteration turns last one week. Review + Planing is done in roughly 45min. The trick: we do not estimate anything, and issues are done, when they are done. Our PO trusts our jugdement: When we think a refactoring might be necessary we are allowed to do it. No questions asked. The result is a healthy codebase with almost no Sonar issues and +83% code coverage.
Right on. Agile is a philosophy, not a methodology. The problem is not about being agile, but doing Agile™ (i.e. Scrum). Scrum sells to large late-adapter organizations; they have managers who want to keep their jobs, and budget to burn on scrum consultants to adopt it.
Agile people (PMs, Scrum masters, POs, whoever) are non-technical people trying to get a job and a position in a technical teams without learning technicalities, nor honoring its complexity. They are there for themselves only, posing a middleman's between engineers and the clients, but only having a whip as their position justification. Not technical knowledge, not domain knowledge, nothing. Once I get bored, I will switch to job in which I'll be making money by asking every day 'how is your task progressing?', 'what is your estimation?', and dragging boxes in Jira. brainless, but priceless
They're Aristocrats, Bureaucrats, and Charlatans attempting to micromanage, commodity, 'trendify', and cash in on a Cargo Cult. The Agile Industrial Complex.
Actually, if someone forced me to maintain Jira instead of doing actual work, I would refuse even if they doubled my pay. (Already rich, from non-bullshit jobs.)
I enjoyed your video essay, probably because it reflects my thoughts on Agile as well. There are a few comments I have. Some background on me, I have retired early from a technology career, but over the course of my career I spent 15 years as a software developer, 2 years in UX and as a business analyst, and another 12 years as a scrum master. The Scrum Master Role: I think for some the role is--as you say--no more than tracking progress and checking boxes. I dug in my heels and only reluctantly performed those tasks. In my view the scum master has one objective: to maximize developer performance and well-being. That objective places the scrum master as a servant leader who monitors the well being of the team and ensures they are able to focus on work AND that they are working on the right problems to deliver sprint objectives. Statistics on individual performance, projecting work plans weeks or months ahead, reporting to the engineering manager on day-to-day minutiae, all of this is rubbish. If you have a role like a scrum master that protects the team and removes organizational roadblocks that can be the difference between a successful project and an unsuccessful one. Agile was understood by my former organization as a way they could proceed to make unlimited requests week to week changing the focus of teams on the whims of stakeholders who had no obligation to commit to any of their ideas. In waterfall, you had better get your ideas organized and your feature requests fully formed and ready for analysis and development, because a change to them is costly and highly visible to your senior leadership. Under Agile (done poorly) stakeholders can make changes to core features days away from launch. At my former organization I worked for them for 7 years, and in that time I worked on 5 interrelated projects that totaled a budget of approximately $450 Million USD. All of them had negative ROI, and not one of them satisfied the business or the customer or the development teams involved. It was one enormous half billion dollar clust--mess. While there was no single cause, my interpretation of the issue is that a majority of the failure of the project could have been addressed by falling back to core Agile principles. I ultimately retired because our company stopped even giving lip service to following The Agile Manifesto and my role became one that focuses solely on data entry into Jira, reporting and maximizing velocity without regard to the overall performance or well-being of the team. Your video really struck a chord with me. I don't usually write paragraph long comments to YT videos. Thanks again.
Tech PM here. Am Agile. What attracted me to Agile: as a PM, I get to contend for my teammates. My teammates are Devs and Engineers. The moment the higher ups try to use me to micro-manage my teammates, I push back against the higher ups and I buffer for my teammates. I love love love being a good PM. It is a real joy.
I (30 years engineering) was agreeing with you until the end… ultimately, we build things for the customer(s), that is the whole point of the whole thing, including the Agile process and what it hopes to deliver (in small chunks, frequently). Agile 2.0, then, might be starting with the OG Agile Manifesto, NOT treating it like a library that can be wrapped with the latest misguided bureaucracy and worse, and adapting it to the team, situation, and deliverables at hand. Agile 2.0 is maybe a formally-defined Composable Agile…
@@charlesd4572 Read the Feynman Appendix to the Challenger Report… be honest with team and management and develop a system that works so that delivery to the customer doesn´t kill them.
Agile is the complete opposite to micromanagement. It works really well. But people who call Scrum agile are deluded: Scrum is the completely opposite to agile.
Ever since Agile was adopted in all my companies it has been a tool for micro management. At the end of the sprint and if you don’t delivery a “feature” it is always why don’t you deliver the feature on time. Two to three times a week would had hour long or longer scrum to discuss the current deliverables for the sprint. This is from industries like aerospace, industrial controls, to storage. All the same
I concur with virtually all of what you said in this video, I think a new way forward is needed to allow workers to find a better balance and optimise their efforts. Happy workers are more productive workers in the long run. Micro management and meetings achieve the opposite, lowering productivity. The ball is in your court now, managers! I wish your channel success, I'm definitely subscribing!
Software projects are failing because companies decide to place in software management positions HR people who are comletely irrelevant with the subject of software without any former experience with code just because they believe they can be managers. These people because they are completely lacking the ability to understand a situation end up trying to push their teams when it's not really possible. To companies always select former software developers for software management positions, don't fall for the HR crap arguments that a person is more social than another, or that he will deliver faster etc.
I was trained with ITIL, which was built for IT service management, but can be applied to almost anything. One of the key factors that my instructor kept reminding us was that it's meant to be guidelines, not requirements, and specifically pointed to Agile as an example of what happens if you take all guidelines as requirements. It could be that the ITIL I worked with was built well, but it usually makes sense, and if I didn't like something, was encouraged to bring it up to see if it could be done better for our team.
100% agree. My problem is not with Agile, but that Agile, when misunderstood, always ends up turning against developers when there are problems. For example, principle 7 of the Agile manifesto ends up being interpreted as the delivery of functionality since what is not seen is not perceived as an increase in value. In this way, real ticking time bombs are created in many companies. As software engineers, we must also contribute to transforming the culture of organizations; we all want to work comfortably. Videos like this are very helpful in spreading and creating this kind of awareness, so thank you very much.
Very interesting video. I’m in IT (but not developer) and day 1 when agile came out I said, this will greatly stress and put under pressure developers, this is not a good method as it is…This need to be changed because at the end this is human beings..
Agile when used to micro-manage things leads to too many meetings. Leadership loves it coz they get to see what's happening on a daily basis. Developers hate coz of the daily interference. In my opinion, the best solution to not get burnt out is to increase the sprint cycle from 2 to 3 or 4 weeks.
#1 Great video #2 You and your research are 100% correct #3 As a senior technical BA, too many non-technical people do not understand or implement agile well. #4 One of the issues is putting the same resources on multiple projects, this means one person might have multiples of all the meetings mentioned. This means hours of meeting, no work.
Same issues on my job. Never been a fan of meetings, and that's what scrum is all about. Vague requirements pretty much necessitate the meetings. Waterfall can be slow up front, to get the requirements done, but once you have them it goes pretty fast. I'd personally prefer some kind of hybrid development system, an expedited waterfall that gets the requirements at around 70%, then allow the devs to talk with the PO during implementation to get the nitty gritty details
I'm an old man with 20plus years of waterfall experience. New to agile as well. Other than the hype, listening to your video, I'm thinking the problem not in the process (maybe) but rather in dividing the scrum target which are prob too ambitious and too all over the place (not focused)? Because, knowing your team capacity and productivity rates are core skills of project managers. If the team is in perpetual condition of burning out, what does that say about the pm skill in managing the workload and team productivity?
Waterfall? Really. You did the entire project without any review of the product during development - no feedback at all (not even alpha, beta and release). Waterfall is a strawman made up by the same folks that came up with Agile.
@@charlesd4572 waterfall is a linear development process. It is clear because it is divided into stages. You move to the next stage when you’re done with the current stage. You don’t start implementing until you’ve clarified what the client wants. You don’t start writing user manuals until you’re done implementing. This is much better project management because it’s to the point. Agile I feel should only be used in issue tracking/feature requests. Things that are not the core infrastructure but rather amendments. When you’ve ready acknowledged there’s a large codebase to work off of and a lot of competing directions to steer it in. As others have stated, can’t be dogmatic about it. Sprints and meetings are too disruptive and the end-target is too I’ll-defined in Agile. The various manager roles such as product manager, program manager, and project manager decouple software devs from the planning process and relegate us to code monkeys. I understand “Agile” in startups where you do Extreme Programming for prototyping but Agile in big co is something very different and a reflection on the company being unfocused, top-heavy, chasing too many projects, bring a simp for customers who don’t know what they want and isolating devs from the planning portion of software development. I’m not impressed with Agile at all.
@@mecanuktutorials6476 in that sense then yes. I think the problem with agile is that it assumes users know exactly what they want. They don't, they have a broad idea of functionality and until they get the product (and by that I mean at least an alpha stage one) they won't care enough to think hard about any specific part of it. Of course once they get something they'll pretend to have known exactly what the wanted all along.
@@charlesd4572 "I think the problem with agile is that it assumes users know exactly what they want" Agile is about the opposite of that.. the idea is to work in small increments, so the customers/stakeholders/users understanding and requirements has many opportunities to grow and change while the product is being developed.
@@charlesd4572 Absolutely not true. The waterfall monicker was coined by Winston Royce in the early 70s to describe the flawed process of trying to apply industrial economics, as descibed by Thomas to software development. It was never meant to actually be used. Agile is a set of values and principles described by a team of leading developers in 2001. Royce was not one of them. The stuff being discussed here as nothing or very little to do with the values and principles that were put forward then. The stuff discussed here is not an agile culture but an appropriated terminology.
The role of the SCRUM master should best be carried out by the dev team. The SCRUM master HAS to be part of the team, if not, its bullshit. The role is very simple and small, certainly not more than 20% of full time.
I'm not a developer but I really enjoyed watching your detailed, fair and courteous analysis of your part of the industry. I hope there are more ppl like you.
I've been around and seen many many SW development ideologies. Two in a box. Extreme programming. Pragmatic programming. The Grady Booch method. Agile. Scrum(-but). What I found works best (especially if you're building/integrating new hardware) is to plan (only plan) using waterfall and slice the release into ~one month chunks where you hit some major milestone in each chunk (e.g. bootloader running on new board). Then to execute each milestone use some kind of iterative method. Scrum works, and there are others, but the best I found is the Spiral Model. Once you're in execution the manager's role is to get the team what they need and protect them from outside crap, (like meetings). Once a milestone is met, you have a party an update the overall plan. In summary: plan using waterfall (big gantt charts, the whole works), divide into milestones, execute each milestone with some kind of iterative model, celebrate each milestone, update the plan and keep iterating. And protect the team.
It's failing, because agile is being used to micro-manage people
but that is not a fault with agile or scrum.
@@matswessling6600 yes you are right, agile methodologies for self management has been hijacked by managers to micro manage hours
@@matswessling6600 If a team can use agile/scrum without management access to tracking tools, that is certainly right. However, any methodology endorsed and enforced by management will have tracking tools. Personally, I wish managers would go back to GANT charts and PERT charts and let programmers use agile/scrum per the manifesto.
BINGO! Totally the situation where I currently work.
PM doesn't know sh*t about writing software, and insists on meetings every 3 days. F*ing useless.
@@paradoxicalcat7173 we have exactly similar situation. It's even worse, THE PM makes everyone 29+ stuck in an hour long daily scrum asking everyone status, completely useless
We're at the time when Agile isn't anymore a tool for the team to self-organize but a tool for management to impose micromanagement. On the grand scheme, the gain of productivity was lost. It's just the illusion of measurability that stuck.
I found agile to be a way for management to micro-manage since anyone could follow us in Jira & Rally.
@@user-vr2rq5hl6lyeah and that kind of visibility was unheard of when extreme programming and the first scrum guide were written. They used paper tickets, and only the team sees the sprint backlog. Real self organisation. Hell I was doing fine with magnetic whiteboards and post its before management broke my co located team. We could write anything we needed on a ticket and rewire our board on a whim using a marker or a piece of tape. This ticket has 50 tests and we discovered a problem when reviewing the 20th? Make a new kanban board for re-review of the tests, Job is good. Now I have to write to an admin to add a custom field.
The problem is, that just because the management calls what they do "Agile" doesn't mean it has anything to do with "Agile". Blaming Agile in such a case is just stupid. It's like making a vacation in Greenland and then complaining that it's cold at the equator. It doesn't make any sense.
@@gzoechi "Agile" lost its meaning. That's why there is a difference between Agile and agile. "Agile" is just marketing ploy now and agile, the attained quality, where at least some of the verdicts from the Agile Manifest are upheld, is rare.
@@rccc5806 Only to you, because you accept the nonsense. This is why we have to find new words for old things all the time. Just because a lot of idiots misuse a word, doesn't make it mean anything different. When we start using a new word the game begins again and again ...
We just need to teach what Agile means instead of letting the bad people redefine our words.
I was "fired" once, because the "PO" said I was slower as a Senior than an Entry level dev. I laugh, cause nothing I ever coded came back bugged, opposed to what the Entry level guy used to make. I only said: Suit your self, if quality is not the priority here, then I agree, I should go. And then I left, smiling. :)
Did they provide a cost analysis of total time spent with entry level guy vs. doing the job right the first time with senior man? I'll assume you'll say, NO.
@@SpaceCadet4Jesus Yeap. NO. 😞
I was in that very same situation back there in the mid-1990s in Germany.
The customers of the company I worked for were afraid to get updates. Except for updates I had been coding - and testing, I might add.
Yes, that took way longer than the usual development processes at that company but it was definitely worth it.
The differences are that I was not fired for developing properly and, well, the development back then was not really agile.
@@seraphinberktold7087 Sure yes, but yeah it's not like we are dragging the development, we just want to deliver once and with quality, thats all. 😞Make sure all the exception paths are handled, etc, etc.
I said basically this exact thing. The junior devs “produced” code, but it was always garbage. And the overall architecture was so horrendous that touching one file caused ripple effects in multiple classes, and in some cases forced major changes in the unit tests. Absolute madness.
Head of Engineering running a product team with 35 engineers here. ✋
My advice is: Just skip the damn meetings and focus on building great software.
Show up to demos with great stuff. No one will question you if you consistently deliver high quality work, I promise.
As a smart engineer, you can demonstrate that you’re capable of doing the job better without managers telling you what to work on and keeping you under a microscope.
Here’s how:
Avoid being boxed in as the technical savant who doesn’t know anything other than how to write code.
Ask the right questions. Make sure you understand the user and the business. Do your homework and make sure to talk about customers and why your work is valuable to them.
Take professional pride in your work.
Don’t agree to impossible estimates, or sacrifice quality for the sake of deadlines.
Just deliver high quality working software consistently, and demo it frequently.
The managers and excessive meetings are there because leadership doesn’t trust you. They want someone to keep an eye on you because they believe software engineers can’t make design / product / business decisions themselves.
Prove them wrong and focus on just building something you can be proud of.
When she said "agile 2.0 that puts the devs first...". As a manager I shaked. Agile it's the opposite. No one comes first. Devs must accept that tey have a vision of the world that must align with the business. That's where their salary come from. Comunication it's about try to understand each other needs. (And this does not means to of meetings.). My advise despite the methodolgy used : there are other people out there that are not devs but that struggle to do a good job as a whole. Some of them are good, some of them aren't. Just like among programmers. Communicate with them . Even if you have to use words and not... a protocol. Anyway.. I love the video and I agree with the fact that Agile is too often not working.
Wise words my brother.
golden reply
And update your resume because they'll find a way to fire you.
That IS the definition of Agile. That’s what I always try to fight for and against the Big Savvy Bosses who want to believe they know what they’re doing.
1. Devs are not dumb waiters. They create wonderful things by solving puzzles. Do you really know how to organize their workflow better? Let them decide!
2. Agile != Speed Up Development. High Value High Quality first. Otherwise you will be buried in Tech Debt and every feature will cost you 10x more.
3. 100% Utilization is shit. Do they give you the result? F*ck off then!
4. The only options to give the Devs any feedback are Sprint Review and the rare cases when they ask. Go and talk to the customers and do tons of researches. Let them cook.
Project manager/ product owner here. I am usually getting kicked from above for not religiously dragging the team through a ton of useless meetings and Agile ceremonies. My teams typically love me for that, my bosses don't.
And can someone please explain how a sprint is not simply a two-week waterfall? I still don't get the fuss about what's so great about sprints. Much prefer Kanban and CI/CD...
I'm not agile certified so I have the same question. How are sprints not waterfall? My group is automation and robotic engineering... People with mechanical, electrical degrees and we code a ton. When asked if we're waterfall or agile I just refuse to answer, instead describing our workflow which to my knowledge is a hybrid of these two ideas.
@@DAG_42 First of all waterfall is rather a theoretical model for processes, where software is built until a big release (which can take months or years) and after that the feedback is gathered. Sprint could be a waterfall (because it has the same phases), if it lasted too long. Also, when the team doing sprints sees results long after the project was started, not getting any feedback from stakeholders and blindly executing what PO puts on the roadmap, it's a kind of waterfall. Just its classic phases are mixed into sprints.
And if you get feedback but your managers doesn't include it to next sprints - sprints are artificial.
Also, sprints are not required to develop software in "an Agile way" - it's one of the method. For example in my project (I'm a dev) we have very slow adaptation of updates - it takes months since majority of our clients will update our library. So even when we have a great telemetry, we cannot inspect the results and adapt our plans at the end of the sprint. It would be much better to get rid of sprints but... our managers are too used to them to change anything.
So for me this is the real problem with Agile: it's a standard nobody understands anymore. Like Project Organizations 20 years ago. Agile is a philosphy and a set of tools you should pick carefully for your individual project to embrace this philosophy. Scrum is not the only Agile method, but companies are behaving like Scrum can work everywhere.
A scrum team is suppose to swarm around the work and go story by story, limiting their work in progress, and collaborating constantly to achieve the sprint goal. But many (most?) teams tend to just waterfall their scrum, pre-assigning all stories individually, with everyone doing analysis the first 3 days, development the next 5 days, then a testing/bugfix crunch on the last day (and into the weekend if necessary) often with corners being cut to force work across the finish line.
Why? Many reasons, but mostly because it's just good enough for most projects.
Managers like to harass you to feel important that’s it
Sounds like you bosses doesn't understand agile. Sadly they are not alone.
And the "sprint"? Well, since you mention a sprint I would suspect you are using Scrum. Scrum is built on empiricism where we form a hypothesis, test it and evaluate to build products in complex environments. The sprint is an arbitrary container of such an iteration. Many use two week, I have done one week sprints and even seen shorter than that. It should be long enough to get actual data out of it to inform future decisions. If we simplify and say we are to scale multiple high-rises and put posters on every floor we might initially have an estimate of when we believe we will be done. Updating that estimate after scaling the first floor of the first building might not be the most optimal thing to do since we have not acquired enough data to make a more informed guess. But say we have a timeframe (a sprint) where we manage to scale 3 out of 8 houses, we have learnt that older houses tend to take more time due to certain factors etc. At that time we could extrapolate a guess founded in more relevant data than we initially had for the remanding work (or pivot if needed... perhaps we decide its not worth the investment, or that we need to finish faster so we need to deploy more resources).
This cycle of inspect and adapt is the fundamental aspect of Scrum. We inspect and adapt our sprint plan on our daily scrum every day, we inspect and adapt based on the result of our hypothesis in the sprint review and we inspect and adapt our process during the retrospective.
Scrum is incomplete by design. Only bare essentials needed to foster the foundational notion on which Scrum rests are prescribed and each team is to find complementary practices that best suit them and their context.
What do I often see in companies claiming to "be agile" and "doing Scrum"?
The teams are asked to book a bunch of "meetings" that no one knows the purpose of and no one explains to them. They then go to these meetings and try to make sense of them. What humans often do is to use previous experiences to interpret new ones when no other context is provided. So the daily scrum doesn't turn into a short affair where the team inspects their progress since last time and adapts their plan but instead turns into a status meeting. Either people try to convince the other members of the team that they actually did work yesterday, or they try to report to the Scrum Master. If it's really bad a manager is there who they "report to".
The Sprint Planning turns into a contract negotiation session with management, the Sprint Review is where you have to apologise for not getting every single things you guessed in the Sprint Planning "Done" or if you are lucky actually got it done (or made it seem like it was done) and at least didn't get scolded.
During the sprints each "role" work on their small parts of a story in isolation. A designer creates something in Figma and hands it over to developers who then develop and hand it over to testers... all while requirements specialists make sure all the arbitrary requirements dotted down a long time ago are fulfilled and documentation updated.
Instead of working together, swarming around the highest value task and seeing it to completion we see Water-Scrum-Fall (waterfall in sprints disguised to be agile).
and on and on and on.
This is a perversion to put it mildly. This is not the use case for Scrum, that is not Agile product development and yet so many companies claiming to be doing agile do this. Most companies have heard of agile success stories, they want their slice of the cake of magic benefits. But they don't actually embrace the mindset shift that agile rests on. Instead they incorporate words, names of roles into their existing processes and tools. When that doesn't work, they proclaim that they tried agile and it "didn't work for them".
It might shine through (hehe), but I'm growing sick of the agile theatre organisations play and that they manage to escape blame and instead shift the blame onto agile.
I've worked in the role of manager and I have a personal policy -- have the least amount of meetings possible. I swear many middle-management people schedule meetings (in all industries, not just software development) to give the "illusion" that they have a lot of work they need to do, it's corporate theater. How often have you been in a meeting where the relevant portion for you or your team is a 5-minute block somewhere within that 1 hour timesuck? I imagine it's a lot.
There are so many jobs that didn’t exist, and never needed to exist, that are the result of automation during the last several decades.
People worry about AI taking their jobs but they shouldn’t. New jobs will be created and if history is an indicator a lot of them will be nonsense roles.
I know there are good middle managers but a lot of them spend most their time trying to justify their own existence to management. So all they really want from the people they manage is PPT slides and meetings to fill their calendars for the illusion of being busy.
@@MikeKalil, when did you start in IT? I've been at this game since 1979, and believe me, there are far less people required in IT now than in the olden days when I started. My dev team does the same work of 6 times more people required to develop in the old days...less QA too now because much of testing is automated, scripts, etc...perhaps we have too many middle managers now...
@kylek29 That's not true. I don't believe you. Let's set up a meeting to discuss that, okay? 😅😉 You'll get a chance to give your side somewhere in the hour meeting, .....OH...and bring us donuts and coffee, okay. 🤣
@@SpaceCadet4Jesus Scrum is just a money maker for some hack that came up with the idea. A Scrum Master has to pay $300 or more to take an on-line course. It looks good on paper but it is just padding for a manager's resume. Agile, Kanban, Jira too. In engineering, many middle managers have the position go to their head because they think they are a "super engineer" and that is why they are a manager. No, true engineers want to create not manage. I chose to remain technical and create. I knew one manager that read all sorts of books on management. He tried to implement several philosophies at once.... Ineffective.
You're one of the rare managers who recognizes that management and meetings are overhead, and are to be minimized. Agile goes in the opposite direction, treating everyone like children, and adding overhead.
I started coding in the '80s - used to kick out (good) code like crazy, I can't imagine writing a lot of code today - these processes strip all the joy out of the process.
Hilariously, the relentless emphasis on the MVP has created a world of developers who "respond to change over following a plan" by cutting corners. They never actually learn how to write code that is architected to anticipate change. They've been trained to focus only on the moment. 😞
Started in the late seventies, but I have to agree. Still writing code though - but I am self-employed, so most of the meetings are with myself. But my colleagues from the 80s do agree with you, we had a very different work culture at that time. The boss told us his wishes about the time schedule, we did some bickering and found common ground.
It depends upon the development group, the team members, the management...if they are decent, then coding today is freakin awesome...if not, you experience various levels of hell...think Dante's inferno...
Oh my. guys been coding here since the 70s and 80s.. hats off
@@joelholdbrooks6729 This is a great comment. I studied computer science in the '80's and then wrote code for many many years. I'll admit that expediency, schedule pressure and short-sightedness often prevent writing robust, well commented, extensible code (management along the lines of "why design and code for something we're not getting paid for"). Over the years I've seen so many fashionable coding idioms and paradigms come and go that when I see some current Best Practices guru spout mantra I just roll my eyes. Next time you hear someone talk REST ask them what it stands for and have them explain the underlying principles and theory. Bet you they don't know.
There were two things I did to survive “bureaucratic” agile. First, since our overbearing project manager came to the retrospective, we couldn’t voice our real concerns. To combat this, we had a secret retrospective afterwards without the manager so we could talk openly. Second, when it came to estimating, I always estimated as high as possible without breaking out laughing. The manager hated it but had to admit that our customers were happy because we always ended up delivering on time.
"Second, when it came to estimating, I always estimated as high as possible without breaking out laughing"
This is actually sound advice. I prefer not to estimate but if I have to, I will do this.
i am a product manager and i actually do and expect the exact same, you shouldn't have to do a secret retro. I always want my team to estimate as high as possible. I prefer always delivering less on time than promising more and not being able to deliver. It works, team is happy, stakeholders are happy, end of story.
Amatuers estimate high...true pros estimate within 10% of how long a story will actually take. People that estimate high on purpose should get fired off the team!
@@jacobmeetsworld6812, it is against Agile to estimate high on purpose, and its also anti-Agile for the product owner to attend the retro. It sounds like you are not using Agile, nor do you know how it works. Its always a good policy to under-promise, over-deliver, but to do it with corrupt means is simply unprofessional. This is what 45 years of development has proven to me...when done correctly, Agile is the best way to produce and maintain products.
@@TheSilverGlow Ah, but you probably didn’t have a project manager who would argue for the smallest possible estimate when we never had a chance to look at the code to determine how much effort was actually needed.
This is such a fantastic video. You've really nailed down one huge problem with modern Agile--people with zero development experience think that the process they manage is itself productivity.
I have worked for a company that makes air data inertial reference units that produce the navigational data for commercial passenger jets on multiple occasions as a contractor. The last time I worked there the manager who had hired me retired and the new manager who replaced him wanted to inflict agile methodologies on the team. All the lead engineers were against it because it is a complex, math intensive product, with a very high consequence of failure. The new manager laid off all the contractors and replaced us with inexperienced recent graduates. After enjoying a little time off, I got a contract job at a medical device company. A guy who sits in a nearby cubicle is a former coworker at the aerospace company. He said the reason he left was because he saw the trend management was taking said he wanted no part in causing a plane crash.
I remember a time when I was with IBM. After the manager laid down new policies for meetings and reporting, a programmer asked: If we do all of this, when do we actually work?
@@HussainAkbar Something I’ve noticed is that most Agile/Scrum meetings are spent talking about story numbers and iteration numbers without ever talking about the technical issues.
Work overtime 😂
@@user-vr2rq5hl6l because technical issues are not relevant. Just spill over.
Write a short summary that nobody is interested in, but can be used to fill up the next SoS meeting.
I'd rather work alone on my own product. Corporations are wage slave factories full of morons who waste time on meetings.
Businesses seems to associate speed and agile with each other. Instead agile works great in a condition where we need to learn a lot. Waterfall works great when we know what works.
My personal opinion is that we should stop taking the frameworks so serious and start to work out how to best deliver business value instead.
Correct! These frameworks are for people who shouldn't be working on projects
Yes when the bosses say they want agile they mean they want short lead times and the ability to change their minds whenever.
But agile is hard. Scrum doesn't work unless the team is more or less doing xp level engineering. Scrum is also supposed to make the team sovereign and shield them so they can protect the improvements they need to make quality flow. But this doesn't work if product management wants to come to the stand ups and ask why developer x doesn't seem to have any real work to do.
I disagree, 45 years of development has taught me that Agile is always the best way to go. Even if you know what needs to be done, do not need to "learn a lot", Agile provides transparency to all team members, provides expectations of when this and that get done, and it provides a fantastic communication platform to share, to learn from other team mates, and to mentor. If done wrong, Agile can be far worse than water fall. If Agile is not working for you, you're doing it wrong.
@HonkletonDonkleto, is sounds like you do not understand Agile. You mock it because you don't have the experience to appreciate it. You still in college?
@@TheSilverGlow I used to have a team member who railed against all the agile. Back at my old employer, he'd say, we just got the requirements and wore the code, we didn't have to stop every two weeks and integrate, or update the tests with every ticket.
And did the code work? I asked
Nope!
Excellent summation, but I'd like to add a few more issues.
The original problem Agile was designed to solve was for consulting...having a design team meet with the customer, get all the specs, lay out a plan usually waterfall), build the product in camera then hand it to the customer only to discover that it's not what the customer wanted. This happens because real world end uses often don't really know what they want until they see it. So Agile baked that in by having a design team draw up a "big design" plan, then iterating the design on a two week schedule and showing the customer chunks of the final product to get dynamic feedback. THAT works.
Where things went off the rails was the assumption that this works for all development when in fact, it really doesn't. Example: if your Agile team has no customers, or almost as bad, a in-team customer representative who represents the customer but works for the dev company, you're not doing Agile. (Pigs and chickens as we used to say).
Worse, somehow Agile changed from a productivity tool to a productivity MEASURING tool and external managers became "chickens" along with the customers (if you even have any of those), creating a conflict in goal. The managers' goal is to get the product done as fast as possible and make money off the work invested. The customers' goal is to get exactly what they're paying for.
See the problem?
Things like "velocity" weren't part of the original idea either. It was added as a way to check progress and see if there were bottlenecks. Now it becomes a "success" metric on its own merit. I can't tell you how many scrum plans have been rearranged in mid-process just to get velocity numbers up higher. Or how often after a sprint plan is locked, someone in management changes direction and blows the entire plan out the door. (And then complains about OUR velocity...)
Oddly to me, this relates to git or "blame-based source code management" where finding the goats when something goes wrong is more important than just getting the mistake corrected and educating the team. Fear-based development also rarely works.
Agile has a place, but somehow it's turned into a religion and a surprisingly rigid one at that given its actual name.
You’ve described some of the exact thoughts I was having about Scrum at work recently. We transitioned back to Kanban because there is less arbitrary bureaucratic stuff to worry about, like points or whether we can squeeze another task in.
I would add that agile has become a way for justifying constant specification and priority changes. Working with requirements that change every day is awful
There are so many things that can go wrong with a project but its usually not Agiles fault in my experience. We run a large number of projects and I can't say the agile side has ever been something to complain about with excellent standards and quality output. The only issue has been contractor turnover but we resolved that by viewing things from the contractor point of view, there are solutions besides money.
Excellent summarization of Agile-SCRUM issues! Thank you!
Interesting. I am writing a book that shows how we are addicted to specific ways of doing business, which has a much higher inertia and much higher foundational scientific Newtonian base, than anything that agile has ever written or developed. Design Thinking has been also dramatically standardized everywhere, for the same reason.
My employer forced nearly all IT teams to use agile. My team is not developers, we support servers and software on them, along with tuning the configuration of the applications. When we just did business as usual, we were told we were not doing enough Jira stories. So now we have stories for all the little daily things so we can complete more stories. We do less actual work than we did before, but now we have a bunch of meetings and Jira stories to to prove we do work.
The meetings are especially a pain. In 2022 we kept complainng because we were averaing 25 hours per week of meetings. This year we are keeping meetigns more under control, averaging about 15, but it's hard because managment keeps pushing for more meetings and we are constantly pushing back.
You cannot use agile. It's not a verb. Agile just means flexible. It's the manifesto for agile software development. The title, one page.
It's not a hammer or a procedure, it's a description.
@@bzuidgeest you can call it whatever you want; if it gets in the way its still a turd.
Just create a lot of rec curing supporting tickets. Like 5 story points every Sprint - support server x, report incidents and etc
Were you forced to use Scrum, or you had the liberty to choose methodology?
You speak from my heart. The problem is: even if we come up with an Agile 2.0, if you put the same people in place as before nothing will change (which is exactly why agile is often failing)
We don't need Agile 2.0. I would say that agile didn't fail... if anything, we need to look ourselves in the mirror and open our eyes to the fact that maybe we failed agile. We allowed organizations to pervert it and stood silently by. Perhaps because we felt "we must be willing to be agile and constantly evolving". And while that is a true tenant of agile it doesn't mean that we can reshape agile back into waterfall and command and control and still call it agile. There are core principles on which agile stands that we must uphold and respect. It's ok for an organization to choose not to be agile. But not to claim to be while working against the very foundation on which it rests.
I'm trying my best not to be silent and raise my voice where I work now (which is a classic tale of a company wanting/claiming to be agile and spending an enormous amount of time and energy working against it).
Amen. That.
I remember, when I first heard about agile and asked what it means (about 10 years ago), my conclusion was: I was doing it (developing software in small iterations) my whole developer life anyway.
Now my last project (a European airline) I rage-quitted, and I'm still recovering after almost a year. I already had a burnout (before agile), so I know what it feels like. The description Dee gave fits like a glove.
So my advice: If you have a SM who attended a 2-week-seminar, run as fast as you can.
Otoh I experienced Safe as working almost perfectly when we had an experienced agile coach. She did not buckle and took everyone to task, also, and especially the stake holders. Once they understood that we (the devs) setup the pace, things started to work.
Most important lesson I learned (and anyway suspected right from the start): Do it like evolution does it: Mutate, evaluate, select, repeat. Try things, keep those that work, abandon things that don't work. Forget about "frameworks", they can only provide suggestions, not paths to follow.
Yes, the "agile manifesto" thing was basically good old common sense packaged into flashy marketing. Then it got subverted through unscrupulous "scrum" consultants to mean "slave driving".
This 👆 is exactly how i interpret agile. Do a thing for 2 weeks. See what went well and what didn't. Adapt to avoid the bad things if possible. If you religiously cling to the methodology as prescribed you will not be listening to the team, you won't be adapting and the team will be frustrated and bogged down. We are now down to 2 dailies, are probably going to do a retro once a month, revised the po and scrummaster roles to fit our work and personalities better and we are doing great. Better then before SAFe. We have no need for the archetypical scrummaster zealotry.
this
Do you believe the evolution shit?
@@clray123 The funny thing is that, at the time the Agile Manifesto was written (and Extreme Programming and other efforts were being developed) these sensible ideas had not really become *common* sense yet. It was those efforts which put them together, refined them, and popularized them.
Daily Scrum meetings sucks my will to live, and the only way to complain about it is to a person who's entire job is dependent on "making it work".
Yes. So tell him. Find a way to make it work for you.
Maybe thet are conducted incorrectly
@@phillipsparks9690 They certainly are....
Ironically, advertised as the framework meant to empower devs. _"By devs, for devs."_ Yeah, right, it never was.
@@errrzarrr It is. But that means you have to let the devs do it. Like I wrote elsewhere: For instance, management has no business in attending the Daily. And that includes the Scrum Master.
My problem with agile is that you're given a certain amount of time to finish something. Then your boss comes and tells you to do so many other stuff on top of your actual task and still expects you to finish your actual task in the original time frame.
Oh my dude this is THE problem of the industry. Managers and bosses that don't understand that "do more" takes more time are sooo annoying...
They already are breaking their own rules with that one
Any popular term at some point becomes vacuous buzzword. They realized at some point that developers liked agile, then hired project managers to be Scrum masters. Fake agile became a business in itself and now the term is more nonsense than not.
Would love to talk more on this topic!
true and real brother.
I'm sorry, but that's not agile.
Here are my two cents on the topic: Neither Agile nor Waterwall will replace good management. Those are tools, and the problem is with the people who are using them. Burning out mostly has to do with the workload and setting realistic deadlines for your team. Wasting time in meetings also has nothing to do with Agile and 100% to do with the people leading the meetings and inviting 200 people to a meeting that needs two experts to talk to each other.
Now, in defense of the managers. Being a PM, Scrum Master or Manager is a very difficult skill to master. That said, there is a solution:
1. provide leadership training to every new manager
2. promote a positive work environment
3. embrace feedback from your team
4. be a servant or transformational leader
5. lead by example
I just checked the amount of agile meetings for our Team (using Scrum): It's ~3h a week, including Standups.
So I'd say, when teams that have 13h of agile meetings a week, I wouldn't call it a problem of "Agile Software Development", but of ridiculously bad management. "Ridiculously", because the problem is known for years and the responsible people failed to recognize and fix this for such a long period of time now.
Love it, change it or leave it.
Yes i agree. Rather than complain, I have solution that I guess I need to make a video about, because Dee does not have her email in her profile, and I was hoping she could create a Zoom community call where I could share my solution and discuss it with other like-minded professionals like you and Dee. I really do not want to make a video, so any ideas on how we can all meet on a real-time group call would be appreciated?
I run very lean Scrumban and it works great. Daily standups are usually 5 minutes. We combine retrospectives and planning into a single meeting every 2 weeks and it is usually done within 30-45 minutes. It works fine as long as the person running it is trying to keep these meetings short and efficient, and the developers themselves are the ones breaking down big tasks into smaller ones, providing their own time estimates, etc.
Its all down to good managers not supervisors
We have very few standups go less then 20 minutes, and that's only when multiple team members are out. I get really frustrated when a 15 minute standup goes past 45 minutes because people think they need to give a full account of everything they are doing that day.
@@javaman2883 Comes down to culture. Over supervision and not trusting people to do a good job makes people feel they have to justify their time to managers and over explain themselves
@@redf7209 You don't even need a good manager. A fairly incompetent manager is fine if they just _get out of the way_ and let the devs deal with work. Agile "project management" isn't terribly difficult, and the reason it works is because it's the developers and customers themselves, not project managers, doing it.
I feel like this is finally being recognized in the industry but the real problem is that Agile software has evolved to the point that it can be used to micromanage developers and obtain metrics for evaluating performance, and leadership loves this. I recently had a conversation with my project manager in which he said that he thought tickets could be written to account for activities as little as 15 minutes so that developers’ entire days can be accounted for. I didn’t use the word “micromanage” but I did use a bunch of corporate double-speak to tell him that exactly what he was doing and in no way that would possibly be productive or encouraging. Not only is that demoralizing, but it’s a very wasteful use of a developer’s time because of the overhead cost. Sometimes we need to stare out of the window and think through a solution for some time. We are not robots.
I would get ansy with anyone asking me how many days.
Macrosnooping 😂 Also, it takes time to create all these observable tasks which probably do not factor into the overall ‘productivity’ time calculation. Leading to an expectation that people work as many hours needed to get the job ‘done’. 6 hours vs 10 makes no difference to the company... Except, it does, loss of focus, context switching, hyper-communication of intention but reduced time to deliver, all negatively impact the company, and so more initiatives are used to manage and control.
It’s a way to deskill (by devaluing) the worker so that the company can think of and treat them like replaceable resources, rather than integral, because would the board think if your workforce were integral? 😮
I think ultimately, business don’t have a way of thinking about their knowledge workers, they aren’t competitors (but they could run off with all your inside secrets) they aren’t customers (although you constantly try to sell them the idea that this company is the best xyz, or we’re family) so companies kind of have their workforce as hostile but necessary partners to deliver a goal and there’s just no good model out there which bucks this trend and delivers (whatever ’delivers’ means to a company + the knowledge workers).
BTW knowledge worker, doesn’t just mean tech, it’s anyone who has specific knowledge to carry out tasks to achieve a goal. And those goals drive revenue for a business.
@@youtubeplaylist6374 Heart felt and well understood. I am pretty shit hot at what I do but management forcing it to tiny pots for no good reason never made any sense to me. The last little tin pot hitler couldn't even to be bothered to come to my retirement sighn off. I think Industry / Business is pretty nasty everywhere, stuff like agile just gives the incompetents something to hit you with. Owners buy into Agile not Workers who do the actual graft. Would you et the brady bunch choose team leaders? But they do because of belief in bull , weak will and just pure incompetence, which is for why their companies fail. Show me a company appointed team leader and I will show you a failed project.
Yup, all these "frameworks" are to get metrics on developers so they can be controlled by performance reviews that are heavily documented, make the managers look effective, and help human resources that loves documented performance to justify a layoff. Under these frameworks, the developer is sweating to keep up with the clock and not really focusing on their work. It is a self fulfilling prophecy to damnation at that point.
@@paulromsky9527 Spot On!
I have been a dev for over 20y and a year ago started to work for a company which does the scrum stuff.
Your video exactly shows how I feel about it. Biggest problems are the constant meetings.
When I started and I saw my calendar, I thought it was a mistake. It looks like I am a some kind of busy business man with million of meetings.
I feel burned out. Already searching for a new job, but most of the companies nowadays use "scrum", which is depressing.
I retired four years ago early at 57. Mainly becuse Covid was starting, but also because of the Scrum/Agile/Kanban/Jira nonsense. I was a contract engineer at the time. I started turning down offers when the following happened:
I went to a company where 8 developers sat in a room with 2 rows of 4 desks that faced each other. No cubicles, not even low wall ones. I called it the Lord's Table. Our work area was also the Scrum meeting room. Every morning we had a Scrum where we were told to stand at our desk for the entire 15 minute or so meeting. The "gods" as they clearly thought they were (office dwellers) came in too, along with the project manager (PM) who was also the Scrum Master. I had to endure standing listening to what other people were doing but I could not collaborate with them during the scurm so it was total waste of time. I asked the PM if I could sit during the Scrum and stand only when I gave my "status" because of my arthritic knee. He said, "No! Everyone must stand at the Scrum". We didn't have phones on our desks, we had to use our personal cell phones. The office dwellers would come into the room throughout the day and have meetings STANDING OVER US AS WE WORKED AS IF WE WERE NOT THERE. They made us feel inferior and it seemed on purpose. They had big offices where 3 guys could have a meeting, but no, they had to "invade our workspace".
I told the other developers, I can see them doing this to a contract guy like me that is just there to get them through a tough time, but you regular employees put up with this? Just then an office dweller came in puffing out his chest telling us to be quiet. One of the developers told him just go back to your office and close your door - we don't have offices. That started a huge argument between everyone the room and a couple more office dwellers. The tension had been building for some time but nobody said anything. At least one developer was burnt out and a zombie. I had to call a colleague in a differnt facility. I was told the guy I was calling was a real jerk and to use the "phone booth" room and close the door. They other 7 guys had a pool as to how long it would take for me to get upset with guy on the phone.. it was 5 minutes and one guy won 50 bucks. This kind of stuff kept their sanity. This was my SECOND day there. I walked out. Management was annoyed. I was told 2 other guys quit right after that. I told my contract agency (that was angry with me for walking out) all of this - focused on the known jerk in the other facility. A month later my contract house called me that the guy they sent to replace me reported the exact same situation - right down to the jerk on the phone. They said I was exonerated and they had another assignment for me... I passed.
@@paulromsky9527 wow - sounds like a nightmare! I could not work like this.
Scrum is incomplete by design. Only bare essentials needed to foster the foundational notion on which Scrum rests are prescribed and each team is to find complementary practices that best suit them and their context.
Let's pretend we do a three week sprint cadence. Then you would have a 15 min meeting every day and on top of that you have a planning session, review and retrospective that would take up a couple of hours each. That's it. Those are all the meetings in Scrum.
Have I been in organisations claiming to be "agile" and "doing scrum" where my entire calendar has been filled with meetings? Ohhh yes.
But that hasn't been the fault of Scrum, if anything it has been the fault of the organisations unwillingness to let go of the old processes. Scrum has simply been added on top.
Instead of enabling the teams and putting trust in them to make decisions control is sought by management resulting in a bunch of reporting meetings etc. Most of which fly in the face of agile and Scrum.
@@DanielLiljeberg I was so annoyed with the meetings in my previous job that I decided to start writing them up in secret. When did they start, when did they end, how much time was spent, now many participants, which participants etc.
I came to the horrible conclusion that I spent more than 30% of my weeks in meetings on average... usually evenly spaced out during the day so that the only time I actually got any work done was when I arrived early in the morning. Whenever I got back into the groove there was another meeting... but of course I was expected to complete my tasks regardless of the meetings.
Was that the fault of agile or scrum? Maybe not, but today if a company even mentions that they are working with scrum or agile I am running in the opposite direction.
@@DanielLiljeberg OMG, finally some common sense amongst all the utter nonsense I've been reading!
I'm a junior programmer. My company's daily meetings last at least 90 minutes, even more, other meetings are the longest. Each spring developers are scolded because the objectives are not finished. Each time we are asked to estimate the difficulty and the time to complete a task, the estimates are divided by two or three, and we are given these revised objectives. Before each PI We have the right to a speech about technical debt. But when we say that there are too many meetings and the objectives are unrealistic we are told that this is the method and we must follow it for more productivity. Sometimes I am fed up with it, even if I love to code.
This has nothing to do with agile. This is a sign you work is a dysfunctional environment with managers who don’t understand what’s going on. You either have to become an authority there and fix it or move on. Your work place is broken, thus the work you are doing is broken.
Agile scrum doesn't work because what it INSISTS you do in the development lifecycle is diametrically opposed to what engineers need to write good software.
I'm a Senior Software Engineer with over 25 years of experience writing software. What I need to deliver good software is: 1) Thorough requirements and technical documentation. 2) All dependencies I have on others to be completed BEFORE I begin my actual coding. 3) Uninterrupted time to write the code.
What I get is incomplete requirements (because : iteration), unfinished dependencies sometimes with no estimate on when the dependency will be completed (because: agile!), and constantly being pulled off sprint tasks to deal with troubleshooting prod problems or do hot-fixes for high priority bugs (because: management).
And for the Agile Kool-Aid drinkers....don't start with the "OH NO! YOU CAN'T GET ALL REQUIREMENTS UP FRONT!!! THAT'S WATERFALL!" just know this: Not being able to get ALL requirements up front is not an excuse to not try to get as many of them as you can upfront, and just screaming "WATERFALL! WATERFALL!" doesn't mean it's a bad way to proceed. Seriously, get over yourselves.
I can’t even agree with this enough. The amount of meetings we attended were just ridiculous. I probably only had about 1 or 2 hours per day to do any development work.
Well tbf that is the oppoaite of agile work. So your company really wasn't following an agile progress
@@TheMathias95 A lot of companies do not follow the real agile, that's the thing.
My worst agile experience include pointing sessions (with official pointing cards), estimating meetings, daily standup meetings (where we were required to stand up), “ceremonies” where everyone did a presentation of progress, and the retrospective. Also, there were project meetings with team members to discuss what actually needed to be done. All we really needed were the project meetings and updates to Jira.
Same. Constant meetin. Standup, prepare planning, discuss with team to help them to finish their ticket. Validate each step with QT, UX, PM. Changing the color of a button takes more than a day!!!!!
Curious why there is so many meetings? Is it because no one can see the "big picture" of the project as a whole?
The spy observation was on point. You're not paranoid, just aware
I can conform that this is exactly what is happening to me.
To get back to real Agile, we have to call it something else. Then we'll have 5 years of good times until the PMS ruin that too :)
Managerial-type people will always try to make themselves "relevant".
LOL - what like communism.
😂😂😂
Like all evil things, they survive because of morons saying 'you did it the wrong way. Now let's try it again, but this time, the right way, ok?'
@@joanvallve7647 dumb people love things that simplify into a set of rigid rules that, when followed, they think will produce the best results. Religions, economic theories, etc., are all designed to make a complicated world simple. Trying to apply one thing to everything is a sure way to do the wrong thing.
Thank GOD someone is finally saying out loud what I have felt for years. Businesses are like misguided children these days and hop on whatever trend comes along without question. The best project managers I have ever seen are ones who have done the job (or similar projects) for years, have experience and knowledge and can guide the process because they have been thoroughly involved and understand what needs to be done. These people know how to get from A to Z... not like some dork with a spreadsheet who thinks if you ask the right questions, you can manage anything whether you know anything about the project or not.
Just an example... I interviewed with an IT project manager once who looked at my resume and said "Oh, you know how to do this? That's good because honestly, I don't know what it means rack a server" What? How does someone like that become an IT PROJECT MANAGER? 😠
It's not "these days" - it's been this way forever - I can't even count the number of fads I've been through. In my view it's some combination that is tuned to the team/task that actually works best. From the "Rational Process" - centered around RationalRose, to something the Clear Case folks defined, honestly I've lost track. I remember back in '94 Peer Programming became a fad and Fidelity tried to get us to use it... we all unanimously said NO WAY - but NASA uses it! 😄
Because IT Project Managers are often not technical. This is often a problem because while they can organise tasks they don't have any appreciation for what is involved in that task. This means if the person allocated says 10 days to do it, they just accept it, even if, in reality, it's 2 days work...or 200
Backlog grooming is not a meeting, it's part of the job of the product owner to refine the backlog.
and the team...
I'm working for a very small team inside of a huge enterprise that *claims* to be "agile". In that team we practice *actual* agile, bottom-up, continuous reflections, no standups, one scheduled meeting per week. And we're moving *fast*. Faster than anyone thought would be possible.
And I understand why a lot of managers hate agile without one of those frameworks: their position becomes questionable. Who should a manager manage if the developers manage themselves? The other reason is: true agile works best when you have devs who are mostly senior and/or passionate.
So what do managers do? Hire juniors, who are cheaper and need guidance. Thus managers add scrum/safe to have pretend-guidance, and keep their jobs. A huge W for managers.
Agile is the ultimate job security for PO and SM
I'm happy to hear at least someone is doing actual agile..
100% agree. Good Sr devs make managers worse than redundant. It puts managers in the position of getting in the way, slowing everything down and being one more mouth to feed (useless pay check that could go to more or better Sr Devs)
My dream company would be the inverse of this top heavy clown world where there are like 2 highly productive developers for every 8 useless people... it should be mostly a company of Architects at the top, then senior Software engineers... and a small sprinkle of HR people for recruiting top talent and paying them very well so they want to stay and are self-managing and passionate. Architects can do the job of project manager but the Sr Devs should make it light work because they're self organizing. Tech leads are also good to have a clear chain of command to resolve disputes quickly. I'd run a lean company so that the budget can be spread amongst a smaller number of highly productive team mates rather. Quality over quantity... large dev teams don't scale anyway!
By the way... I am now living in Brazil where living costs are cheap. If you want a good worker for cheap - I'd gladly leave the shitshow I currently work at... I have 5 years experience as a SWE.
In my 6 years of working as ux designer, I was baffled by the resistance to do even a 'simple' ux research such as interviews or observations with a target group at the beginning. And Agile was one of the main reasons for such a mindset. No wonder the products we worked on later failed miserably. And I ended wirh burnout.
Because the worst people to get detailed requirements from are the users. Believe you me, beyond the basic functionality, they don't know or care about what they want until you actually give them something. Then all of a sudden they know - and always did apparently - exactly what they wanted. If you're doing this on a routine basis you'll never get anything finished.
In my 25 years as a developer, and most recently as CTO, I can tell you that it's a huge waste of time. The users are terrible designers and will make a lot of bad suggestions. It's much better to simply ask them what they need on a non-technical level, and then design it yourself. Once they get to actually use the UI, they'll be able to tell you what they find inconvenient, and you can iteratively improve it.
@@FinnGamble well, that's what I meant. Of course you don't ask users to design the product literally.
Agile should be called rigid. Anyways how hard is UI anyways we literally have 30 years of examples to take inspiration from from games to apps to websites.
Find some you like and use them. Nobody is going to give good feedback unless theyre more intelligent and capable than you.
@@FinnGamble exactly. I've been in this game for nearly 20 years and I couldn't agree more.
i (a software dev) now work in a company where the upper management wants the software division to use Agile, but no one in the software division wants it.
this is a nightmare. since the upper management knows nothing about Agile, and the ones tasked with implementing it, hates it.
we are forced to do everything wrong, and are afraid to tell anyone.
I worked at an internet news magazine one time, one of the founders came back from a sabbatical and said something like, “Maybe we should switch to Ruby on Rails, that seems really popular.” It was ten years old at that time, and it was clear from the many disparate components and lack of any real design much less documentation that this actually had a chance of getting attention! What was it Jobs said, allegedly… “It doesn't make sense to hire smart people and tell them what to do; we hire smart people so they can tell us what to do.”
Tell 'em you are doing what they wish. Meanwhile, do what better fits you. Afterall, that's the _Agile Manifesto._
The fools want to 'do Agile'. You can't do an adjective. As usual these idiots want to mandate that which they know nothing about because it's trendy.
Hmmm...the best software developers I've work with (45 years experience) prefer Agile...perhaps your company is not doing it right...the least experienced tend to not like it because it holds them accountable, forces them to more transparency, and dates matter.
@@errrzarrr, the Manifesto is actually anti what you suggest...but the point is well taken...management is wrong to demand Agile without the team buying in...if most of the team hates it, then one of two things: (a) they have little experience doing Agile correctly, or (b) too many juniors on the team, or (c) they are afraid to expose their lack of competence, lack of skill, or lack of drive...such people hate accountability, transparency, and being held responsible...or (d) management sucks.
When I was first introduced to Agile many years ago, sprints were 1 month long. I miss those days. Also scrums were 2 or 3 days a week. This was doable. But now sprints are 2 weeks and standups are every day. I don’t think management realizes that a 15-minute standup wastes at least an hour. If you start work at 9am and standup is 9:30, you’re now sitting and doing nothing because you can’t get deep in to coding for 30 minutes. Then standup rarely lasts only 15 minutes. And then after standup, it’s bio break and a drink. Now most of the morning has gone by. Then we have backlog grooming, planning, retros, etc. The point system has never made sense to me and means something different to every SM I’ve had. But then you also do hours for tasks. Let’s stick with one metric please. If 13 points is roughly 1 sprint, then just say 2 weeks instead of 13 points. And honestly I have never seen an accurate estimate…ever. You can say it will take 1 week but it takes 3 weeks…or maybe only a day. I should stop ranting now lol.
You're absolutely correct. Business has always been challenged with traditional software development methodology because management has too little ability to track progress in near real-time. Agile flips this on its head by introducing "micro-inspection" (and hence micro-management) at the cost of inflicting "death by 1000 cuts" on developers.
I still don’t understand what a scrum master does and why they are needed
As a scrum master, it's to make yourself obsolete. Train the dev team to work together and on their own, train the product owner to effectively figure out what the client wants and teach everyone how to refine into atomic and well defined user stories. Once the machine starts rolling, get out. Go to another team. If there is a scrum master for a long time, it means that either the team is not willing / able to pick up scrum, or, more likely, a bad scrum master.
The SM is the interface between the Dev Team and the outer world.
The SM is also the lubricant in the team. He/she is there to avoid or help overcome impediments.
The SM is the guardian of the agile methodology, the guardian of the team schedule, the guardian of the procedures, the guardian of the team rituals.
The SM is the guardian of the memory of the team and the project.
That's some of the tasks of an SM.
Yes, I've been a SM in a scrum/agile team before 😉
@@superpieton this evangelical nonsense is why people hate on scrum 😂
They are not needed. We do not use a scrum master. We use squad based development and each squad collectively manages their sprints.
@@superpieton SM's should be be there to teach the process and leave.. Not be a part-time psychologist, coz you don't have anything else to do.
A study indicated that people trip and fall mostly at the first or last step of stairs. And it further suggested that we should remove both these steps to prevent people falling. 😅
I'm a CSM. And a SE and Architect, 30 years in the biz. Agile is a way for consulting companies to make $$$. Most companies do not even do full Scrum, they use daily standups as a way to micro-manage. Full scrum has roles that (barely) make it work as a methodology. Remove those roles (program manager for instance) and failure is inevitable. I did just fine for twenty years prior to scrum, using waterfall and then rational unified process based on use cases. Use cases worked, and identified wtf you were building. The fallacy is that scrum produces working software. It may produce some software, but it rarely produces what the end user actually needs. It also makes engineers have to basically apologize (in toxic environments) for research spikes, requirements gathering, architecture or any other fundamentals of software engineering for which there used to be formal process.
Software engineering practices are on the decline. See 737 MAX, and be very afraid.
As a former Dev, now CIO/CTO, we do Agile Lite. We let the customer (internal employees) stack rank, we build what they want in "functional phases"...maybe you call that Waterfall, Sprints don't have a deadline decided by me, it's not 2 weeks hard and fast, and we work our backlog. We have happy customers getting what they need and have measurable progress. You don't have to buy into the cult. Maybe the sprint is 5 days, and maybe it's 3 weeks, I don't care, and why should you? In either case, we have to stack rank so the customer feels they are getting the value, but outside of that, I'm not giving you a full delivery schedule because your requirements are not fully qualified. People can't articulate requirements until they use it, so we eat the elephant one bite at a time.
This is exaclty the format I use with my team and barring any blocked work, we are always releasing new stuff that our internal and external customers asked for.
Great video. In my experience, agile/scrum is misused far more often than it's done right. I was on a project where they had daily scrum meetings consisting of 20+ people, over half of whom were participating from a remote location by phone! Somehow we managed to get products out the door, but it was in spite of project management, not because of it.
I don't really think we should move from agile as the title suggests, but as you say in the video, we should move away from over-zealous implementations of SCRUM. In my team Agile works and is not overwhelming with meetings. We do have them, but they don't get in the way of day to day work and we have a reasonable approach to it. But SCRUM in other teams is a messy burden that makes use of three different project management tools and has their members sitting in meetings all day. In other cases, some teams just have waterfall disguised as Agile.
At the end of the day, agile methodologies are a lot like programming patterns - tools that can help you do your job if applied correctly. But as with programming patterns, if you follow them dogmatically and don't properly assess your actual situation at hand to see what fits best, you end up making things harder for you.
Yes. We need a better management culture and for managers to actually understand what they manage, not moving on from agile. Agile is an instrument, not a silver bullet.
A lot of "agile" I've seen was a combination of worst attributes of agile and waterfall. You have a two week long spring, 1 hour daily meeting with 15-people team and everyone talks about everything but nobody offers any help to others (it's too long already), documentation is not done at all, there is not sprints or tasks for tech debt, budget and features are per-planned for half a year, nothing ever gets removed from any sprint, and any extension of time goes with increase in scope.
the primeagen has a better solution in his recent video about agile being dog doodoo.
Id rather just GSD than sit in random meetings.
@@MikkelzuI think I remember watching his video on the topic but don't remember the details. His videos are hit or miss for me in terms of how agreeable I find them.
But your summary doesn't sound good either tbh. "Getting shit done" without catching up with colleagues regularly is also a recipe for disaster in my opinion. A good team is aware of the work as a whole and its status and can react appropriately. A lot of the times it happens that I hear something on a SCRUM that I know something about which then allows me to provide input. To me that's healthy. Our stand-ups are rarely longer than 15 minutes of the work day, so I hardly consider it to be a barrier in the way of GSD. As with most things, it's all about balance
@@MikkelzuWorth noting is that my impression is that Primegean is a very code oriented person, but being an engineer extends way beyond how many words per minute you can type and how efficient you are with VIM. Most of the work in my experience is discussing and understanding requirements and making sure you got them correctly, so meetings are a necessary evil
@@vlad-rs8pb Same for me on his videos.
My take on GSD being better is a bit nuanced but overall I agree with some aspect. I think a standup is fine (as long as it doesnt devolve into chatter), and periodic review periods as a team to check if the direction is still right etc is also good.
However I dont believe that sprints, retros, refinements and the whole shebang is necessary at all. I think if a developer has a blocker or needs help that the first case should be low barrier communication to ask for help. Now, at my work at least, most people just wait 3 days for the 2 hour long refinement thats planned in when they have a blocker of some kind instead of asking me or another senior for help.
GSD with periodic communication and letting the bureaucrats do the bureacracy is to me much more productive than forcing a group of developer to spend almost 35% (if we look at the example in the video by Dee, the reddit dude with 13 hours of meetings) of their work week on meaningless meetings.
I will concede and say i am a certified agile/scrum hater and I will probably never see the appeal of it after having worked with it in such a misappropriated way
You hit the nail on it's head. I have almost two decades of experience in Software development. I have not yet met a developer who cherishes or looks forward to going to in to these meetings. That says a lot how developers feel about these blood sucking, life expectancy diminishing meetings.
Ironically Agile was invented to cure the annoying "status meetings" that existed pre-Agile
I think its a huge issue that developers, look down on meetings and communication as much as a HUGE portion does to day , also lack of documentation and want to work all the time like at home making a small hobby project for themselves.
Tje resistance to whow their work and sometimes even sabotage is part of why the meeting size and numbers grow because there is a huge culture of unprofessionalism and even antagonism.
It makes an impenetrable wall that makes it hard to work as a unit and even harder to make a good org that is more than its parts.
@@michaelk.jensen1611 there are developers that have to high of a sense of value for themselves.. and also a developer that refuses to communicate is one that will soon have no job.
But on the other hand the excess of meetings can cut into valuable development time. Can't get that feature done if you keep talking to me.
@@acasualviewer5861 what I'm thinking is that part of what creates a lot of meetings is this culture and dislike for meetings and communication.
Then as a consequence of that, meetings increases because people feel they are walled out and not in the loop , or other ways.
So I believe that mindset actually might be part of why there are more meetings.
So in effect the dislike (that I think often are kneejerk like reactions) of meetings and communication is a significant factor in creating even more meetings.
@@michaelk.jensen1611 interesting perspective.
I do agree that sometimes rather than looking through a PR for hours in Github, it might be easier to just have a call with the developer and have him explain the code to you. Saves everyone a lot of time.
Being too afraid to have face to face contact is not healthy.
Thank you, I appreciate your thoughts!
Agile is not the holy cow. A process must support the business - it's not about using blindly a methodology. If your process doesn't work, change it, reflect, adopt, repeat.
I don't think there is a one-size-fits-all methodology. As PM I'm always trying to force the business side to come up with concepts which are well-thought through because one of the issues I see is that we loose planty of time in requirements discussions once we started coding. The business side is often misinterpreting agile with I-can-change-my-requirements anytime in opposite to waterfall where proper specs are required upfront. We have a lot of people in the middle and upper management who actually have no idea what software development and engineering is about. But these people are often the decision makers or "owners", they naturally need more communication and therefore meetings. I really blame mainly the business side for the explosion of meetings in software development. But again, if your process doesn't work, escalate it and try to change it. Otherwise I only recommend to consider looking for a new job. Don't waste your life in stupid meetings and boring companies 🙃
This is a really solid comment. Well put
I dont blame business for the explosion of meetings. I blame middle management 😂
Tell the person who controls the budget that your team spends 32% of their time on meetings - and you’ll get their full support to cut those numbers down 🥲
@FranzAllanSee lol this isn't true, considering executives love meetings as well
@@ChiTheAesthete it’s their job to be in meetings. But if ICs are spending more than 15% of their time in meeting, there’s an argument to be made. If it’s 30% or more - even a way stronger argument 😁 it’s like hiring 10 devs but only 7 are working 😂
Management doesn't know anything about software because they don't talk to software departments. It all goes through PM's. Chinese whispers style.
Great video, really like your approach. So recognizable. My 2 cents: it is fundamentally wrong to see ( by the managers ) , agile is something for the team to execute. It is however in the first place for the managers to come into action, removing the impediments and making themselve not needed any more, creating a real agile environment. If there is real self-management made happen, there is no pressure. If a team can operate independently, there are no further alignments/meetings required. Agile is not about practices to do, but about creating an environment that makes it possible!
My two cents. Agile exists because no manager can justify spending lots of time to write proper requirements, without producing any code in the meanwhile. Unfortunately Agile started to pop up in the aerospace field. Very scary.
Waterfall is soooo much easier. The basic idea is that you write the documentation before you write the code. You might have to revise the documentation several times before you are happy with the design. But revising documentation is vastly easier than revising code. And when you get to the point of writing code, your job is easy and fun because all the technicalities of have been well thought-out.
Can't say I have ever worked on something so simple waterfall really worked. Documentation was hundred pages+ and it always became a hell of changes after a few months due to changes of requirements as well as additional knowledge gained doing development.
Waterfall had many issues. But I agree it was not evil like Agile is. It is evil from it's conception. Agile manifesto is on some extent BS because it focuses on developer's empowerment while ignoring the fact that software is just a tool wich serves purposes developers mostly donesn't understand and doesn't have to know either.
@@joanvallve7647 what is evil in agile?
What makes you think it is focused on the developers? And why do you think developers do not need to know what they are building?
Personally I think the biggest problem with agile is that it is not there to give the business the information they really would like to have: what they get, when they get it, and what it will cost. It is a methodology to give business a way to steer development accepting that this can't be estimated with any precision. Unfortunately many think it is a methodology meant to answer these questions - and then it goes terribly wrong.
@@lmoellebI can tell you that I work on medical devices and iterative waterfall is the way to go. You cannot deliver safety and quality in 2 week sprints. You can call it stretched - out agile, call it FRED, call it whatever you want. You've got to do up front design, documentation, prototyping, BEFORE showing to customer. Especially if customer is an MD or surgeon. They tend to be high ego people and surprisingly ignorant of the effort involved in making a safe and effective product, unless they've done it before. "It's got to be easy to use" they say over and over again, as if we don't know that. But it's got to be safe as well, and that costs time and money. Testing, unit tests, CI/CD, static analysis. You can sort of stuff this into a scrum framework, but get rid of the word sprint. Because if you sprint! You're likely to fall and twist you ankle....
@@lmoelleb The problem is right there, hundreds of pages.
Those do not get written by experienced developers analyzing the project goals and matching those with the actual data, but by non-developers and other corporate bureaucrats.
Based on unverified data and promises of data to be delivered in a certain way, nothing is tested in advance.
But with Waterfall done right, it is smooth sailing and you start with a working model that has proven the data fits and can efficiently supply the project requirements.
But when it is done badly at the start, it's just as much a mess as with any other development method.
I totally agree except for one thing. Scrum/SAFe is not the only way of Agile; they are frameworks that are almost anti-Agile. However, they call themselves "Agile" because they are like a Trojan horse within Agile principles. A good methodology that fits Agile principles is Kanban.
I would argue Scrum can facilitate agile product development very well (unless it is on theatre ofc). If I have a flow of work, Kanban is often a perfect fit. But if the mission is to develop a product in a complex environment Scrum tends to work better. The empirical inspect and adapt cycle fits well with iterative workflow in close collaboration with the customers/users.
We form a hypothesis, we test it and make decisions based upon the outcome.
@DanielLiljeberg I agree that Scrum can be good in complex environments initially, and after some time, Kanban will probably be the better one again.
I've seen one company that went bankrupt because of bad management. and I think scrum played a big silent role in this.
BTW - I just don't go to meetings I have nothing to contribute to. But... I'm old (see another post on another of your videos) so no one cares if I am there or not. I keep the stakeholders apprised via written reports. If anyone has a question, they have my email address. Also, I have that exact copy of the Agile Manifesto that you display on my wall (I have acted as a Project Manager in many different development paradigms). The comment 'too many meetings is too many meetings' is an extremely cogent point. Years ago a manager of mine had a poster in our meeting room that suggested "Don't let a meeting become an event where minutes are kept and hours are wasted". I have always remembered that.
I coordinated the V DevOps life cycle (Waterfall framework), and I agree. The department integrated continuous integration (a precursor of DevOps) to respond to customer needs outside standard development. Nowadays, with a misunderstanding of the Agile framework (used as a micromanagement tool against people, not for products), you have too many meetings for a few valuables at the end. The tests are not done correctly to satisfy the desire to go on the market quickly. Then, you have the customer feedback several times. The product is not implementable: there are too many significant errors or bugs.
I already quit software development because Agile is actual hell. Switched back to cyber and not looking back.
They force agile now in cybersec too unfortunately... Which obviously works as terrible as one may think. Source: I work in cybersec and some projects are run in scrum/agile.
@@mllenessmarie how does it even work
@@dmitryurbanovich4748 We have a project, for example, to improve/review existing SIEM and to implement SOAR for the client. And along with it goes the design and the documentation, there are calls and discussions - and that's where agile comes in - all that preparation and actual implementation is in sprints and daily calls. Believe it or not, but did some projects where there was even retro xD At least we don't measure effort in story points.
@@mllenessmarie CrowdStrike has entered the chat.
@@dmitryurbanovich4748 Sorry, didn't notice the comment earlier. Basically, if you provide cybersecurity services to the client - e.g. the migration from one cybersecurity platform to another (EDR, SIEM, firewalls), then that whole work is being tracked using scrum. There's spring splanning, kanban board with tasks, daily stand ups etc.
My main issue with agile is in how many startups and small companies use the small iterations to replace the need for a plan or documentation of one.
Many simply don't have a specification of requirements for version 1.0, or 2.0 for that matter.
Without that specification it becomes virtually impossible to also set up a test plan for QA to go through before signing the release papers.
Developers don't necessarily like to document too much, but if you're supposed to work in parallel it helps to "waste some time" at the beginning by specifying the overall goal, also to prevent scope drift.
I was educated in the old IBM-style waterfall method, which is also tedious and feels slow, it's not perfect, but it allows for a complex component taking longer than many of the smaller ones, you don't aim for having a fully compilable version every week. You just make unit tests according to specs, and then all the pieces are supposed to work when they're ready to be put together.
In the last 12-15 years, I've seen many agile teams, and had agile forced on my team a couple times. I've never seen agile work. I don't think I've ever seen it done following the manifesto properly either.
We've kept a few of the ideas but changed them. We don't do daily scrum. Weekly. Sprints are a quarter. Sprint planning and grooming are done annually.
What do we do when work comes in and needs done sooner? Manager decides priority.
We also do a weekly status report. That report takes a few hours because its not really just a report, it is a weekly presentation to the exec management. They want to see 50-100 of these each week, and go through them quickly finding blockers, issues, and who is doing actual work vs. pretending.
Every "Agile" project I've seen goes about 268% longer than planned.
Be careful not to confuse agile and scrum. They are not one in the same. You can be agile and not use the scrum framework. And doing scrum does not make you agile.
Like politics, the biggest problem is when companies allow and promote people who actually want to manage others...to manage others. That one attribute should spell immediate disqualification. If dev teams are to ultimately 'manage themselves' then managers need to be promoted, by force if neccessary : ), from within the dev teams themselves.
Was a PM in video games for 8 years. Used only what we founf usefull in agile : Scrum planning/review (merged), scrum meetings. We created highlevel stories and the teams broke it down in tasks. Agile was not used to micro managed at all (PMs in video games don't have time for that). No idea what all the other meetings you mentionned are. Maybe a Director or team lead had an extra meeting here and there but it's part of their job. I don't remember one team member complainning about having too many Agile related meeting. We used waterfall for art and Agile for tech and it worked pretty well.
So true, Agile is what businesses use to hide the fact that the really have no committment to following a methodology and just want to hide the fact that they operate from the top of the organization by the seat of their pants.
The Agile problem is compounded by ignoring the reality of development personalities. Extroverts migrate towards management and they feel like they are doing something by warming seats in meetings. Meanwhile the real developers - those who actually do work - are forced to waste time in unproductive meetings where - as typical introverts - they get so bored that they zone out.
In my long career the only methodology that I saw produce real high quality products is the data-first Structured Engineering that we used to survive Y2K. But it requires true commitment by the corporation and proper training of all participants, including some from the business areas.
I dont agree with the title but I do agree with what you say in the video, Agile is the way to go imo but if the management misuse it and doesn't implement it right it will hurt the productivity,
I am a Scrum master. It was going good in my company and developers were happy with the sprints.
But one day the company implemented Agile 2.0. Since then we are just following scrum ceremonies for the sake of it and micromanagement is at peak. Burnout seems a very small word to me.
We have project managers, senior project managers, product managers, group product managers, product specialists, sr. product specialists, SCRUM masters and agile coaches on the IT side, NONE of whom can write a line of code or even a SQL query. And we are proud of it. :))
But does anything actually useful ever get done?
I am so thankful that I am old enough to have missed the Agile and Scum methodologies. I am old enough that we used the Waterfall methodology combined with common sense and small iterations It worked well and was responsive to customer feedback.
I know little about Scrum and Agile but every time I learn something new about them, I just shake my head.
"Small iterations" and "responsive to customer feedback" are the core of Agile. It seems like your team - just as countless other teams - has invented agile software development 🙂
The main problem isn't even the meetings. The main problem is that noone has any idea what are we actually building and how it should work
Same experience, I hate agile, I hate SCRUM, I hate SAFe Agile, I hate PM's, I hate Scrum masters, I hate grooming meetings, I hate retrospective meetings, I hate it all.
Will never go back to those type of companies.
I agree... But 95% of companies want you to do Scrum and SAFE. That sucks. I miss the good old days working with waterfall approach (no meetings at all).
I love agile. I hate Scrum and SAFe and all the other processes that claim to be agile but are the complete opposite to what agile actually is.
Agile isnt scrum or safe.
You have some validity in most of those opinions. You also have to keep in mind that if you hate reflecting on how you can do better or mistakes you have made, ie retospective, are truly an engineer?
Sounds like you hate your job.
We have created an entire class of people whose only skill is running meetings and unfortunately, they have too much say.
YES, Yes, yesssssssss!!!!! Finally, someone is speaking out.
Dee, good segment. The mythology transition was all about speed of delivery replacing quality. The complaint, in my day, was how long it took to get a "FIX" for a newly discovered bug. The reality was different of course. The level 3 (SW engineer owning the product) would VERIFY and identify the failing code, and then generate a fix that was released as a BETA software install. The grand issue was that the (Agile Software) fix required regression testing to insure no unexpected behavior changes to the code and a BETA site sign-off. It was the NEW kids pushing the Academic Agile Software development as a way to get rid of the PESKY Documentation, Installation process development, Installation Testing installs, Regression Code Testing, Release documentation, Release to BETA approval, BETA site buy in for testing and sign-off. They just wanted to develop and throw it over the wall, respond to it's broke, develop and throw it over the wall etc. Essentially making the user the software testing manager with the production site being the software testing environment.
Such a great video, thanks for sharing your thoughts! I’ve worked in product and project management (15yrs!) and now a re-skilled as a developer, so I can see both sides of the argument! Agile is not the problem, but the interpretation of it, is what causes so many issues. Biggups!
Spies!!! I never thought about it that way! Your video speaks volumes! Keep up the great work! Subscribed!
I'm not a software dev, I've just recently started working in a dev-ish role and because of technology migration I'm working in two projects. We all here do "agile". My main team works closely with our PMs, we have 2 status meetings every week, and one sprint planning every two. They usually last less than 15 minutes.
In the other project, I have a daily status meeting, usually more than half an hour. It's still way less than people describe, but even that is a bit much for me.
Status meetings aren't the devil - some people do need to have frequent checks or they'll start to procrastinate - that includes me. But I find that talking about what I did every day is useless as the tasks take more time and I have other work to do. I very much prefer the rare meetings and being encouraged to actually talk to people if I have any questions. I know that if I have a meeting next day, my questions will just wait for that and it slows my work down.
People love to hear their own voice. I was a brutal dictator as the scrum leader and kept the discussion as short as humanly possible. What did you do yesterday? What will you do today? You have at most 90 seconds. Snap snap around the group and out of there. Any other issues are dealt with after people are set free. Meetings suck the life out of the team. People only needed to know what others were working on so they could collaborate that day. Pure agile, where programmers were assigned to random tasks each day never works. Developers have specific skills. The write the test first and then write the code worked perfectly. If done well, agile works. The problem is that people will slowly revert to long meetings and too many meetings and old habits and it can collapse.
I've done that too, and the other folks loved it.
But that breaks down the moment some manager above me muscules his way into the meetings. If I can't (politely) shut him up, it goes to hell. Even if I can shut him up the first few times, before long he feels a need to Exert His Authority. It surely goes to hell after that.
Then I encouraged team members to set up their own ad hoc meetings as needed, including ONLY the relevant folks, when something needed to be worked out.
That works until the manager gets wind of it; then he'll insist in being invited to every such meeting - which derails them.
Then the only route left it to have ad hoc conversations with the relevant folks OUTSIDE of any 'meeting'.
Wow, I just came across your video. I retired from a large company several years ago. Before retiring, I was part of several Agile projects for a few years. Your video and many of the comments here bring back so many anxious feelings and not so good memories. It’s like I time-travelled back to that time. I never felt that our SCRUM meetings were worth all the time that was devoted to them. So many times I said to some colleagues, just let me get the fricken work done! Stop wasting so much time talking about doing the work and just get it done. Endless meetings, even about the smallest of things. I frequency felt stressed and lots of anxiety. Finally, I would get to the end of the workday and then think I have to do the same non-productive crap the next day. I hope I didn't offend anyone here. Thank you for your video. It's nice to know I wasn't the only person who felt this way!
Excellent! Thank you for sharing this; I loved it!
I agree 100% with this, agile is not the problem, is how 95% of bussiness implement it, and it comes to this: Bro reads agile manifesto and it says "Individuals and interactions over processes and tools", bro flips it and it goes like "processes and tools over Individuals and interactions ". Scrum master is indeed the herper of agile, because is the perfect plan to enter the tech industry without knowing a crap of it, Just give to an SM a team of devs so he can micromanage them and get paid for it, profit without writing a single line of code.
Please can someone tell me what "Individuals and interactions over processes and tools" really means in any material sense. It's like saying "you must go down before going up". That's the problem with agile it really has no meaning. Development of any product of any meaningful size has always been done in cycles. The Waterfall method is just something dreamed up to justify agile and subsequent consulting.
@@charlesd4572 The agile manifesto is really a compendium of best practices to any given project of any nature, is not strictly reserved to software engineering, that why is so ambiguous, but if you want to narrow to what devs do on agile teams it's not complicated to understand: for example, "individuals and interactions over processes and tools" in SWE is really putting devs needs over the ceremonies of, let's say scrum, that in practice means "we don't need your freaking meetings, let me do my freaking job". Like the video said, one of the main issues of scrum is that there is too many (ofter useless) meetings, and maybe you can skip some meetings that aren't that necessary, more if you're short of time to meet your sprint goals. Some SM and managment evangelize so much scrum that they don't care if meetings took 40% of your time and still you're asked to meet your sprint goals, that's why almost every dev hates scrum. The framework should adapts to the teams needs, maybe we should make that daily meeting twice a week (change the name if you want tho), maybe that 1 on 1 is not neccesary, Jira can do the backlog grooming automatically and maybe we don't need that meeting either. Frameworks adapts to devs and not backward, "but we need to have those meetings if not we're not doing scrum", well, we're not then, and screw scrum and screw the SM and screw managment, I need to do my freaking job so bother someone else with your little meetings.
Some people just want to have meetings all the time because it makes everyone feel important. If you bring up the fact that there too many meetings, they'll schedule a meeting to discuss it.
I remember when I was new on a Team, my first Dev Job. I said after a few months that we could make things better and gave two examples. Instead of just doing that non bureaucratically (or reject it) we scheduled a monthly 'retrospective'. I did not knew what it was and said: Why we do not JUST decide to do it or not, like the Agile Manifesto says? But I thought maybe they know more. On the Retrospective it was awful. When any of us brought on a topic to change, one of the other blocked it. Learning: I wanted to change something, it resulted in a 2+h time waste every month.
As a developer that does project management for my team, I would say this nailed it. Well-articulated and accurate. Subscribed!
I never had to suffer under Agile, so I can't comment to that. I did go to a lot of meetings in my career. Your discussion reminded me of a colleague at my first workplace, Texas Instruments. His name was Art. He was an affable and extremely knowledgeable guy. He became my go-to co-worker when I had a question no one else could answer.
I eventually noticed that every time we had a department meeting, Art was never there. He wasn't absent or sick. He just didn't go. Ever. Except once when he was getting an award for his excellent work and was asked (begged) by his manager to attend.
I eventually asked him about it. Art replied that he didn't find it useful to go to the department meetings as he never learned anything and he was better off spending the time getting his work done. I concurred, but I was way too lacking in cred to pull off the same stunt. Art was so invaluable to the department that he just didn't give a flip about what management thought of him.
Art was my God.
I cannot complain: We are a small team of 4 devs, 1PO and 1SM and doing Kanban. Our iteration turns last one week. Review + Planing is done in roughly 45min. The trick: we do not estimate anything, and issues are done, when they are done. Our PO trusts our jugdement: When we think a refactoring might be necessary we are allowed to do it. No questions asked. The result is a healthy codebase with almost no Sonar issues and +83% code coverage.
Right on. Agile is a philosophy, not a methodology. The problem is not about being agile, but doing Agile™ (i.e. Scrum). Scrum sells to large late-adapter organizations; they have managers who want to keep their jobs, and budget to burn on scrum consultants to adopt it.
Agile people (PMs, Scrum masters, POs, whoever) are non-technical people trying to get a job and a position in a technical teams without learning technicalities, nor honoring its complexity. They are there for themselves only, posing a middleman's between engineers and the clients, but only having a whip as their position justification. Not technical knowledge, not domain knowledge, nothing. Once I get bored, I will switch to job in which I'll be making money by asking every day 'how is your task progressing?', 'what is your estimation?', and dragging boxes in Jira. brainless, but priceless
They're Aristocrats, Bureaucrats, and Charlatans attempting to micromanage, commodity, 'trendify', and cash in on a Cargo Cult. The Agile Industrial Complex.
Astute
Actually, if someone forced me to maintain Jira instead of doing actual work, I would refuse even if they doubled my pay. (Already rich, from non-bullshit jobs.)
I enjoyed your video essay, probably because it reflects my thoughts on Agile as well. There are a few comments I have. Some background on me, I have retired early from a technology career, but over the course of my career I spent 15 years as a software developer, 2 years in UX and as a business analyst, and another 12 years as a scrum master.
The Scrum Master Role: I think for some the role is--as you say--no more than tracking progress and checking boxes. I dug in my heels and only reluctantly performed those tasks. In my view the scum master has one objective: to maximize developer performance and well-being. That objective places the scrum master as a servant leader who monitors the well being of the team and ensures they are able to focus on work AND that they are working on the right problems to deliver sprint objectives. Statistics on individual performance, projecting work plans weeks or months ahead, reporting to the engineering manager on day-to-day minutiae, all of this is rubbish. If you have a role like a scrum master that protects the team and removes organizational roadblocks that can be the difference between a successful project and an unsuccessful one.
Agile was understood by my former organization as a way they could proceed to make unlimited requests week to week changing the focus of teams on the whims of stakeholders who had no obligation to commit to any of their ideas. In waterfall, you had better get your ideas organized and your feature requests fully formed and ready for analysis and development, because a change to them is costly and highly visible to your senior leadership. Under Agile (done poorly) stakeholders can make changes to core features days away from launch.
At my former organization I worked for them for 7 years, and in that time I worked on 5 interrelated projects that totaled a budget of approximately $450 Million USD. All of them had negative ROI, and not one of them satisfied the business or the customer or the development teams involved. It was one enormous half billion dollar clust--mess. While there was no single cause, my interpretation of the issue is that a majority of the failure of the project could have been addressed by falling back to core Agile principles.
I ultimately retired because our company stopped even giving lip service to following The Agile Manifesto and my role became one that focuses solely on data entry into Jira, reporting and maximizing velocity without regard to the overall performance or well-being of the team.
Your video really struck a chord with me. I don't usually write paragraph long comments to YT videos. Thanks again.
Tech PM here. Am Agile. What attracted me to Agile: as a PM, I get to contend for my teammates. My teammates are Devs and Engineers.
The moment the higher ups try to use me to micro-manage my teammates, I push back against the higher ups and I buffer for my teammates.
I love love love being a good PM. It is a real joy.
I (30 years engineering) was agreeing with you until the end… ultimately, we build things for the customer(s), that is the whole point of the whole thing, including the Agile process and what it hopes to deliver (in small chunks, frequently). Agile 2.0, then, might be starting with the OG Agile Manifesto, NOT treating it like a library that can be wrapped with the latest misguided bureaucracy and worse, and adapting it to the team, situation, and deliverables at hand. Agile 2.0 is maybe a formally-defined Composable Agile…
Can you remember a time when we built large software projects in one big cycle - I can't and I've been in this game quite a while too.
@@charlesd4572 Read the Feynman Appendix to the Challenger Report… be honest with team and management and develop a system that works so that delivery to the customer doesn´t kill them.
Agile => micro management
Which is the exact opposite of what the manifesto states.
Agile is the complete opposite to micromanagement. It works really well. But people who call Scrum agile are deluded: Scrum is the completely opposite to agile.
Ever since Agile was adopted in all my companies it has been a tool for micro management. At the end of the sprint and if you don’t delivery a “feature” it is always why don’t you deliver the feature on time. Two to three times a week would had hour long or longer scrum to discuss the current deliverables for the sprint. This is from industries like aerospace, industrial controls, to storage. All the same
No Agile is NOT micro management. Micro managers have hijacked agile.
Agile/Scrum is a micromanagers dream framework
"Being in meetings is not an excuse to not getting your work done" "Now, on to the scrum of scrum's meeting."😮
The fallacy of needing a really experienced developer to be a PM is what will sink your ship. Full stop.
I concur with virtually all of what you said in this video, I think a new way forward is needed to allow workers to find a better balance and optimise their efforts.
Happy workers are more productive workers in the long run. Micro management and meetings achieve the opposite, lowering productivity. The ball is in your court now, managers!
I wish your channel success, I'm definitely subscribing!
Software projects are failing because companies decide to place in software management positions HR people who are comletely irrelevant with the subject of software without any former experience with code just because they believe they can be managers. These people because they are completely lacking the ability to understand a situation end up trying to push their teams when it's not really possible. To companies always select former software developers for software management positions, don't fall for the HR crap arguments that a person is more social than another, or that he will deliver faster etc.
It's not going anywhere. There is too much tied up in consulting.
Sometimes I have a feeling that we are kinda being bullied by those who dont know anything about software engineering.
I was trained with ITIL, which was built for IT service management, but can be applied to almost anything. One of the key factors that my instructor kept reminding us was that it's meant to be guidelines, not requirements, and specifically pointed to Agile as an example of what happens if you take all guidelines as requirements.
It could be that the ITIL I worked with was built well, but it usually makes sense, and if I didn't like something, was encouraged to bring it up to see if it could be done better for our team.
100% agree. My problem is not with Agile, but that Agile, when misunderstood, always ends up turning against developers when there are problems. For example, principle 7 of the Agile manifesto ends up being interpreted as the delivery of functionality since what is not seen is not perceived as an increase in value. In this way, real ticking time bombs are created in many companies.
As software engineers, we must also contribute to transforming the culture of organizations; we all want to work comfortably. Videos like this are very helpful in spreading and creating this kind of awareness, so thank you very much.
Very interesting video. I’m in IT (but not developer) and day 1 when agile came out I said, this will greatly stress and put under pressure developers, this is not a good method as it is…This need to be changed because at the end this is human beings..
Not really defending agile but if a consulting company did the study it’s probably because they want to sell something else
Agile when used to micro-manage things leads to too many meetings. Leadership loves it coz they get to see what's happening on a daily basis. Developers hate coz of the daily interference. In my opinion, the best solution to not get burnt out is to increase the sprint cycle from 2 to 3 or 4 weeks.
Leadership *think* they get to see what's happening on a daily basis.
#1 Great video
#2 You and your research are 100% correct
#3 As a senior technical BA, too many non-technical people do not understand or implement agile well.
#4 One of the issues is putting the same resources on multiple projects, this means one person might have multiples of all the meetings mentioned.
This means hours of meeting, no work.
Same issues on my job. Never been a fan of meetings, and that's what scrum is all about. Vague requirements pretty much necessitate the meetings. Waterfall can be slow up front, to get the requirements done, but once you have them it goes pretty fast. I'd personally prefer some kind of hybrid development system, an expedited waterfall that gets the requirements at around 70%, then allow the devs to talk with the PO during implementation to get the nitty gritty details
I'm an old man with 20plus years of waterfall experience. New to agile as well. Other than the hype, listening to your video, I'm thinking the problem not in the process (maybe) but rather in dividing the scrum target which are prob too ambitious and too all over the place (not focused)?
Because, knowing your team capacity and productivity rates are core skills of project managers.
If the team is in perpetual condition of burning out, what does that say about the pm skill in managing the workload and team productivity?
Waterfall? Really. You did the entire project without any review of the product during development - no feedback at all (not even alpha, beta and release). Waterfall is a strawman made up by the same folks that came up with Agile.
@@charlesd4572 waterfall is a linear development process. It is clear because it is divided into stages. You move to the next stage when you’re done with the current stage. You don’t start implementing until you’ve clarified what the client wants. You don’t start writing user manuals until you’re done implementing. This is much better project management because it’s to the point.
Agile I feel should only be used in issue tracking/feature requests. Things that are not the core infrastructure but rather amendments. When you’ve ready acknowledged there’s a large codebase to work off of and a lot of competing directions to steer it in. As others have stated, can’t be dogmatic about it. Sprints and meetings are too disruptive and the end-target is too I’ll-defined in Agile. The various manager roles such as product manager, program manager, and project manager decouple software devs from the planning process and relegate us to code monkeys. I understand “Agile” in startups where you do Extreme Programming for prototyping but Agile in big co is something very different and a reflection on the company being unfocused, top-heavy, chasing too many projects, bring a simp for customers who don’t know what they want and isolating devs from the planning portion of software development. I’m not impressed with Agile at all.
@@mecanuktutorials6476 in that sense then yes. I think the problem with agile is that it assumes users know exactly what they want. They don't, they have a broad idea of functionality and until they get the product (and by that I mean at least an alpha stage one) they won't care enough to think hard about any specific part of it. Of course once they get something they'll pretend to have known exactly what the wanted all along.
@@charlesd4572 "I think the problem with agile is that it assumes users know exactly what they want" Agile is about the opposite of that.. the idea is to work in small increments, so the customers/stakeholders/users understanding and requirements has many opportunities to grow and change while the product is being developed.
@@charlesd4572 Absolutely not true. The waterfall monicker was coined by Winston Royce in the early 70s to describe the flawed process of trying to apply industrial economics, as descibed by Thomas to software development. It was never meant to actually be used. Agile is a set of values and principles described by a team of leading developers in 2001. Royce was not one of them. The stuff being discussed here as nothing or very little to do with the values and principles that were put forward then. The stuff discussed here is not an agile culture but an appropriated terminology.
Competent developers despise Agile
Wait - Scrum Masters with programming background actually exist?
😂😂😂😂😂😂like for real😅😅😅....
😂😂😂
@@George-W-Jenson I mean why should you be a Scrum Master if you can program? It is like rejecting being a Wizard for pursuing a career in Data Entry
The role of the SCRUM master should best be carried out by the dev team. The SCRUM master HAS to be part of the team, if not, its bullshit. The role is very simple and small, certainly not more than 20% of full time.
ha ha.. .. scrum master.. really .. ha ha..
I'm not a developer but I really enjoyed watching your detailed, fair and courteous analysis of your part of the industry. I hope there are more ppl like you.
I've been around and seen many many SW development ideologies. Two in a box. Extreme programming. Pragmatic programming. The Grady Booch method. Agile. Scrum(-but). What I found works best (especially if you're building/integrating new hardware) is to plan (only plan) using waterfall and slice the release into ~one month chunks where you hit some major milestone in each chunk (e.g. bootloader running on new board). Then to execute each milestone use some kind of iterative method. Scrum works, and there are others, but the best I found is the Spiral Model. Once you're in execution the manager's role is to get the team what they need and protect them from outside crap, (like meetings). Once a milestone is met, you have a party an update the overall plan. In summary: plan using waterfall (big gantt charts, the whole works), divide into milestones, execute each milestone with some kind of iterative model, celebrate each milestone, update the plan and keep iterating. And protect the team.