@@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
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.
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!
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.
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 😉
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 🙂
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.
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 now work in a modern waterfall environment. Lots of meetings (6 hours this week, but 2 new projects launching, so this isn't typical) but usually about 3 hours of meetings a week, and one of those is an on-call handoff for a team in China and us in the west. The org I left, and several before then, who were SAFe Agile, or Scrum, easily, double that would be normal, with periods that were even more meetings. To be honest, can't believe I'd prefer waterfall to agile in practice, because in theory, I prefer agile to waterfall. Sadly, theory and practice, as we devs know, rarely live in the same house.
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 😂
We sort of follow some elements of agile, in that we have a daily standup which takes about 5 minutes to state whether we had blockers from the previous day, and what we're working on that day. We don't have formal sprints, but we schedule update releases with bug fixes and requested features. Larger scale releases are timetabled, but we don't have a "You MUST get it out the door" mentality, as more often than not, we have to switch to implementing a different feature or fix at the request of the clients. The key is to be adaptable, and to keep each other informed. It doesn't need 13 hours of meetings per week which chew up the time of everybody. A quick once round the table so everybody knows what everyone else is doing, followed up a short phone call or email between people directly involved in those changes is enough. It might not be the most "modern" approach, but it works well for us, and gives us a lot more time to actually do the work. It doesn't scale well to larger teams though. We're a small company, and this working practice really does play to our strengths.
As a COBOL programmer, it is clear to me that after companies like Microsoft argued the slow and controlled environment with systems analyst driven development could save money getting rid of them, having been tempted by "saving money" the companies paying for development eventually realised that uncontrolled developers can't work, so some bright spark decided meetings and coordination was the solution. Systems analyst based procedures and processes of controlled delegation is always the solution... "systems analyst"... this is what IBM, Siemens, NASA and MIT did and man got to the moon and banks had working systems.... The problem is that developers don't like being told what to do... actually customers (or marketing/sales) decides what a system should do and developers need to have a "translator" for those wishes to be converted to a coordinated system to meet those needs. That was the function of procedures and the specifications written by systems analysts. The young are fools, but they get an ego trip and a high salary...;)
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'm so frustrated. My company teaches agile and practices it - in my opinion successfully. Then I hear the horror stories of people hating agile with a passion, and every time it turns out they're doing something that goes against every sentence of the agile manifesto. Scrum and safe especially sound nothing like agile. Do we have to rename the thing we're doing because the middle managers of the world have ruined our good name? Side note, my phone keeps auto correcting agile to asshole. Should I take the hint? Ahhh, I'm just so tired of bad management. There's no framework in the world - be it waterfall, agile or anything else - that can survive managers like that. We're just end up reinventing the same ways of working with new names because it always degenerates into middle managers exerting power and destroying the company.
One issue I have experienced is that the job of a developer is to write code, learn new stuff, fix bugs, write documentation, etc. etc. Also, when you are in the zone and you have to go to a meeting, usually unproductive, you have lost the focus and have to spend 15 minutes or so to get back into the zone again. Worst case scenario is several meetings with an hour gap in between, so basically you will never get really productive. Better to have the meetings back-to-back and then be left alone. The job of a project manager, however, is, for the most part, to go to meetings. Meetings with the project team, stake holders, company meetings, etc. etc. Hence, a PM with too many holes in their calendar is not working. And this is, I think, where poor PM's don't get the developer point of view, that meetings are a waste of time. Too often there is no proper agenda about what to discuss, so it's kind of free floating. I have even had a PM that, during a meeting that ran shorter than the scheduled hour, said "OK, we have 30 minutes left. What should we discuss now?". I raised my hand and asked, "Can we go back and do some work then?" The PM looked at like he didn't understand my point.
Interesting video, thanks for posting. I'm a product owner and scrum master, and have a few comments. Agile is a manifesto, not a methodology. Scrum is a type of methodology; a way of implementing Agile. A good SM will take care of their team and be careful not to put too much work on them during the sprints. Metrics are important, but not everything. I still believe Agile and Scrum are great and when done well, provide a consistent work experience and tempo for developers.
I don't know how this came across my feed, but this is fairly on-point. The company I work for tends to have the problem of force-completing sprints and pushing to prod things that are not fully flushed out. All in the name of having increased communication and output... unfortunately it takes away from the quality of the products themselves. It appears to be a knee-jerk reaction to the fact that the rest of the company didn't used to know what was in the pipeline or when it would be deployed, so they couldn't properly work with and amplify the efforts (ex. support, marketing, etc). However, the way in which it is done seems to have resulted in the devs being burnt-out & non-communicative unless they are commanded to by their superiors, as well as siloing development status to try and offset the unreasonable timeframes... all resulting in the fact that we now _still_ don't know what's going on until it's deployed AND have less communication. All that with what I would consider a skeleton crew of devs.
As a contact lead/principle developer, the first thing I end up doing on nearly every job, is fixing the agile processes and putting it back in the hands of the development team.
We are using a more human version of scrum with: delivery meeting, task refinement, sprint planning and retrospective. That's all. So far it is a good experience and something that any company should do. Other meeting like the daily standup, 1-1 etc... are just useless.
Nowadays, Agile is being hijacked by useless project managers and business people. They use meetings to showcase their work and importance. Nine out of ten projects could be completed without them. Additionally, two-thirds of development teams spend meetings wasting time instead of coding. Only a few hardcore developers actually put in 8-10 hours of productive coding. The main problem lies with the leaders who believe they can run a company without technical backgrounds. They feel the need to hire two more project managers and nine juniors instead of keeping the four hardcore developers and tripling their salaries. In the end, it would be cheaper and five times faster, but CEOs are often coward, cheap people and unwilling and incapable to manage a company differently.
It's ultimately all about control. Agile gives employers the chance to micromanage teams. Some projects can't really be done that way but many can or are modified to fit the methodology. What i've observed is that the key outputs (that take time to do) from waterfall are the very things which are ignored in Agile implementations, the documents , the testing and the requirements analysis phases particularly. But all is not lost, some companies recognize the issues and use a modified version of Agile that does work. For instance only the middle phases are performed as sprints but the first and last phases are performed as usual. Most times an EPIC cannot be implemented in the short sprint timescales, so it is split into stories which are split into a series of sprints. That seems to work much better.
I've worked for organizations that tried to use agile/scrum in all of the wrong ways. The worst was a VP who, among other things, compared velocities across teams, assuming that story points were fixed units of work, and harassed the teams with lower velocities to get the devs to quit. What really happened was that some teams caught on to what he was doing faster and just bumped up their estimates for every single story, so they'd always be the "high performing" teams. It was complete nonsense, but this guy just wouldn't get it.
I have many years of experience working in both Agile and non Agile projects. In my experience, Agile significant decreases productivity due to the following reasons: 1) The managers mostly do nothing besides pretending to manage 2) Lots of time wasted on useless meetings which also distracts devs from their work prior to and after the meetings, further negatively impacting productivity 3) Sprints almost never correspond to the time required to complete a task and they're a useless and time wasting concept 4) The childish routines like daily's make developers feel like children, it's really demoralizing 5) Developers have to devote energy planning what they will say in the daily meetings instead of focussing solely on their work. 6) Daily's often replace or interfere with informal and much more productive meetings on topics only involving a small subset of the developers.
As a Network Cisco guy interesting to see how the other side of the house does things (My last job as a Senior Network Engineer/Network Lead I spent most of my time in Meetings using up all my time meaning I would have less time for the things that needed to be done on a time line)
Retired Database Architect here. Before Agile, I used to have a joke that said: “You start coding and I’ll go upstairs and see what they want”. To which everyone would laugh. Enter Agile. Now my joke is literally a methodology! What a fucking disaster software development has become. My whole world was a damn JIRA ticket!
I have seen teams prefer Kanban. They aren’t tied to a sprint, instead it’s how much we can safely add to the next release. You can still plan deadlines and scope can still flex. Any methodology done poorly won’t end well for anyone. Unfortunately there are many well meaning but ineffective Scrum Masters, Coaches, and Project Managers. Companies have a hard time finding good ones because the hiring manager doesn’t have the relevant experience to know what to look for. So they hire mirrors of themselves.
"Planted by leadership to be spies." You're right, Dee. And to your other point, nobody declines meetings, because then you get "feedback" from people (which you can't even see who wrote it) telling your "Resource Manager" that you are not supporting the mission. So then your Resource Manager puts you on an "Individual Development Plan", or IDP. That's basically the same thing as a PIP (Performance Improvement Plan), except that an IDP does not require management to actually begin the PIP process with HR oversight. You see, HR keeps (or used to keep) managers from violating labor law. Like laying off somebody without having proper documentation of the things they're doing wrong. Or firing them without cause. So the IDP acts the same way as a PIP, but HR has no visibility into the IDP. And if the employee doesn't show improvement via the IDP, well then, there's always another "skills layoff" around the corner. A manager who needs to unload a few employees does not need to have a PIP on an employee in order to lay them off. Instead, the manager can just insist that it's not a "performance decision", but instead it's a "lack of skills for the role" kind of thing. And if the manager has an IDP on the employee and the manager has documented even just a few loosely-worded instances where the employee may have done something wrong, not improved, whatever; the manager can use THAT to justify the layoff due to "lack of skills". It's really really popular for senior managers to force their line managers to make the line managers' employees engage in poorly directed remedial activities like "talk less in meetings", "don't make a person feel bad with your words", or "get 8 hours of training in this-or-that on Weekends for the next quarter". It's childish and insulting, especially when you have to apply the Agile "manifesto" to your best, most experienced team members. You're just damaging people's careers, and I despise it with a passion. You know you're in a truly evil organization when you have more administrators than you do available technicians on your teams. And you've reached the innermost circle of Hell when you, as a manager, realize that you have an IDP on one team member for "interrupting team members during meetings" and an IDP on another team member for "not participating in meetings". And a third IDP on yet another team member for "criticizing the Scrum Master" (or the Project Owner, Orchestrator, etcetera). Agile is a farce. It was created by bureaucrats. Continuous Development rarely works well on a 2-week sprint cycle. If your company has it, then your company hates its most skilled developers. But it all balances out in the end, because very soon, your best, most skilled developers will hate you, and then they will leave. If you don't lay them off first.
I can't agree more and imagine if you are multiple projects, you will end up delivering nothing. Plus nobody challenge the estimates that come up from the sprint plan. Everybody does not have any interest to keep the estimates low
With 46 years experience, I have seen good (supportive) managers and bad (interfering) managers and I'm in total agreement. The methodology used doesn't matter as long as reasonable procedures are used (although I think the 'latest cool pretty toy' is usually.not a real solution and can rigidify the development process)
As a project manager who learned waterfall approach we worked with our developers to map out a plan for success. When moving to Agile you need to discuss what is actually possible in those two weeks and what is NOT possible. Agile does not work when you have development that needs more than two weeks of effort. A good project manager works with their team to achieve reasonable goals. My personal goal has to work with our team to be successful but to be realistic with what can be achieved.
People don’t know how to work anymore. Several times I worked with agile, always a disaster. Too many meetings, too operational and never a clear vision. Before development please do proper design thinking first.
The #1 goal of Project Managers in most companies is to report upwards. That's it. I have even heard them say that they cannot make projects fail; they can only make it succeed. if a project fails it is someone else's fault.
Agile is about the customer and requests the developers to accept changes (quickly). Waterfall is the opposite: long development cycles with few possibilities to interact with the customer about the current result. Agile frameworks are the problem because they don‘t connect the developer with the customer finally. Scrum isn‘t „the agile way“, it‘s a working style to involve developers and manage workload. The topic stays unanswered: why and how is management causing problems by requesting to follow Agile?
I don't think Agile is all that bad, but I'm sure that the negative examples mentioned are real. I' ve been working for a major blue chip company as a PM for many years. For me, Agile is a tool box. You don't have to introduce every possible type of meeting. In my projects, (depending on project size), we have a daily scrum or just a scrum meeting every other day. Then we have sprint planning and review. We do have retrospectives, but I belive we should have less.I feel, that's all the meetings that are required for a developer to attend. Generally, I feel the most efficient projects have a combination of waterfall and AGILE, waterfall for the big picture and the important milestones, AGILE on a more granular level. I love to have a good old-fashioned Project Plan. User Stories should be derived from that project plan. I know, I'm a bit of a heretic here, but developers should know about the essential milestones and when to meet them. In my experience the combination of a minimum amount of meetings plus a milestone plan is a guarantee for efficiency and productivity.
Agile done well has valuable and tight feedback loops across the whole process, so things like TDD and CI/CD where the team gets feedback and the process itself helps the team do better. Often I've seen teams who are moving from Waterfall to Agile over committing every sprint. Rather than taking small bite sized pieces and growing their throughput by "sharpening the axe" of their processes.
It genuinely sounds like this framework's base problem is in who attends the meetings. Like.. PM should meet with team leads, that makes sense. But it is up to the team leads to take information from that meeting down to the individual members of their teams. Which I would put on them, as they know their team. So if the most effective thing is a 10m huddle with their team in the morning - do it. If they know their people are better suited to just send them an email with the minutes from the PM meeting - do that instead. Bottom-of-the-totem-pole workers (Not meant to be derogatory, companies run BECAUSE of how essential these people are) shouldn't be continually interrupted to go to meetings that amount to high-level people talking to other high-level people about high-level things. Like... PMs should have the standard open-door policy where you can approach them with an issue, but they should almost never be approaching individuals as they don't know what they might be interrupting in workflow. That's why you have team leads. PM needs something from a section, they go find team lead and that lead will make sure it gets taken care of because they know the workflow of their specific team and when the task can be interjected without fucking things up. Just my opinion /shrug
As an architect I'm not a fan of the perceived lack of design phase. SAFe kinda handles that but I am yet to see agile work in a large corporate environment from a control perspective
Agile is too difficult for many. If somehow everything - architecture, org structure and process - somehow align most businesses don't know what to do if one element goes out of balance. If you only know an Agile 'recipe', e.g. Scrum, without knowing the fundamentals of Lean you are almost certain to fail.
One not minor reflection about your last statement: focus on the development process instead of customers or business, surely will drive you to ruin. Computing is a subordinating discipline of business processes , producing or servicing final customers. Therefore, no matter the way you organize better to avoid the recurring burning out, accomplishment of business objectives is simply vital. I would say all efforts should be focused on making the development service understandable, predictable and trustworthy . While the more business people consistently see awkward, non-emphatic, arrogant who never accomplish a deadline developer , therefore the more will fantasize about replacing you people with a robot.
Agile does not fit into corporate paradigm driven by finance outcomes. That is costs can be predictable, and then this means we need to micromanage output, add more layers, add more meetings etc. end result, you can not operate Agile, and at best it’s a crap version of waterfall or linear project with a bunch of meetings named after the Agile methods. It’s the worst of both worlds!
I work in a agile team but since I am the only Software Engineer I am free to do whatever I want. For my projects, I use a waterfall approach since it works better and I am able to deliver higher quality features instead of crappy code that does the job but isn't ideal. The previous team followed an agile approach and today the code that they wrote is basically undocumented and unreadable, probably because they were trying to pump out features as fast as possible instead of actually engineering the project.
Agile - throw buggy code over the fence before anyone notices. Someone else can fix the problems, that's boring and difficult. A better approach is understand, design, write, test, repeat, taking the necessary amount of time for each which you won't know until you start. Get a contract for as high a price as possible, and share the money for early completion as bonus.
I think scrum would be best used to manage the waterfall process... let it be more receptive to scope change. If that's done the development becomes less wasteful. That and add the software needs (core updates) as a customer.
Well, data analyst here, not software dev. - semantics - it's programming as well, just different languages. I don't even know what our system is called. We meet for a few minutes in the morning about 1.5h into the day, talking about what we did the past day and plan that day, ask for collab and such. Takes usually 15min. On Mondays, this meeting is a meeting about what is due that week and if we can meet that deadline. On Thursdays, the meeting is 1h as professional development where something along the line of a cool method, a new snippet or a dashboard is presented and critiqued. Could also be an intro course to a new tool or software. 1 on 1 is only once a month. We all work remote and every last Friday, we meet for lunch.
Project managers exist for a reason, the bigger the org, the more necessary they become. For better or worse. Agile is fitted into everything, and I think it might be worth asking, if that makes sense. Maybe if a company exceeds 300 (800, 1000, whatever number) employees, agile just won't fit anymore.
The problem is very often that PMs don't understand your job and feel like their only way not to loose control of the project is to micromanage it to pieces. I am very lucky to work in a small business that doesn't have as many BS jobs having people struggle to look like they are doing something, but it happened to me a few times, and I had been quite bold protesting it, even going as far as saying : 'Either you trust me, or you fire me.' I am all about good communication and constant adjustments because most often clients don't really know what they really want and no reasonable amount of analysis will give you as much feedback as demos. But I will not stop what I am doing just to make some person feel important. If you want work done, please let me work. Nothing is more infuriating than being constantly interrupted to be told things are not going as fast as they should. No s**t Sherlock!
The one thing I have always loathed about Agile is MVP and that whole "get to market first" while missing key pieces of the puzzle. In reality, the true answer is somewhere between Agile and Waterfall.
There are no ideas in agile which are not also covered in every other cyclic development model. What is different is the order of implementation and the importance of each component in the model. In the more classic cyclic model (such as waterfall) great amounts of effort are put into designing the entire product and an extensive review of that design before the product is implemented . Agile makes design and its documentation less important, while producing some element of implementation becomes more important. Hence, in agile, we are apt to measure once and cut many times, with all of the potential for wastage that such a process entails. With what I've just said, I think I'm repeating Dee, but I could be wrong.
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.
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.
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 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.
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.
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.
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.
@@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.
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 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.
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.
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.
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.
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 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!
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 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 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.
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 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.
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!!!!!
My problem with all of this is: All these processes and methodologies feel like they have been created to create jobs for people who don't actually want to create things, but rather feel entitled to appear useful
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.
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.
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.
As you mention Agile isnt really the issue. Having been in this game for some 30+ yrs, Ive seen production systems come and go, to name a few that I "had" to do courses on, Topdown Bottom Up, Waterfall, Kanban (of course), Agile and a number of other weird ones more relevant to manufacturing that software eng. The reality is, processes _arent_ the cause of bad development environments, people are. I have worked in _amazing_ agile projects (where I was team lead, scrum master and system architect in different projects) and I have worked in utterly chaotic and stupid agile projects. The key differences are _not_ the process, they are the people. Whether its management structure issues (this is very common in big industries like gov and defense) or whether its the ego's and developers being utterly fanatical about following strict agile processes (this destroyed one project I worked on). In one agile project I had a _single_ person be so obnoxious and just toxic to the whole team we sat down with the Chief Engineer to 'extract' them from the team and have them work on solo tasking. The team then built absolutely excellent simulation systems and solutions from then on. So before you become "that dev" that says "oh agile sucks", look around. See what is causing the main frictions and remove them. Sometimes people just dont _like_ high communication environments, so remove them and use them more effectively. Something I will say, one of the most successful projects I helped run/develop with a wonderful team resulted in some of the best communication across disparate skillsets (3d artists, C#/C++ coders, Java coders, designers and scenario creators) which had many of these people actually expanding their skillsets and working on tasks they had never done - artists doing C# and Scripts, Designers doing C# and script, and coders jumping into Art and Design. That was actually _due_ to the agile processes we put in place to make people feel comfortable helping each other when their loads (tasking) seemed a little high. This works.
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
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.
@@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.
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.
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.
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 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've watched two of your videos so far and I absolutely love them. I'm not that deep in your channel yet but I'm a software engineer for a rather large name that I can't mention here because people would know it. TLDR, please read "The Phoenix Project" if you haven't already. I'm a big believer in doing DevOps (done correctly) which is not a software or just about CI/CD pipelines but about the ideals of lean manufacturing put in practice. I hope you check it out and would love a video with your thoughts. I'll go check if there is one already right now but, if not, please consider :)
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'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.
Scrum should be outlawed for safety critical products. It puts unnecessary time pressure on developers and testers, which could make them overlook latent bugs in the code. I have worked as an engineer since 1982 and as a software engineer since 1987, mostly in safety critical real time embedded software in the commercial avionics and medical device industries. Scrum is incompatible with embedded safety critical software. In making big architectural changes, a task can take much longer than a silly two-week sprint with nothing to show for it until the task is completed to some degree. The same can be said when working on low level software that interfaces the hardware, such as when you have to spend time in the lab using an oscilloscope to verify the data coming across a shift register. Sure, it doesn’t interfere with your work when doing something trivial like changing the layout of a few buttons on a GUI, but even then, with all those pointless meetings, it is a colossal waste of time. In my first DO-178 (safety critical standard) job, by not being rushed and micromanaged, I was able to discover latent bugs in an avionics product that was written in assembly language that other engineers had overlooked. It was usually a comparison statement using a variable using indirect addressing versus direct addressing. That is similar to misusing a variable that is defined as a pointer to an int as an int or vice versa. The data that was in that location just happened to be a value that coincidentally would work, but it was subject to change to something that might not work in the future. Getting things done FAST should NEVER be the primary goal in safety critical software. And I am not anti-process. Safety critical standards like DO-178B in aerospace and IEC 62304 in the medical device industry define the SDLC, but the things they define make sense, like requiring 100 percent path coverage in testing flight code, because you don’t want to be flying near an airport and find out the altitude reading froze up because the code is stuck in a while loop. All the things I see being done name of agile scrum make no sense. Unfortunately, even some aerospace companies are starting to do this agile scrum nonsense. It has the look of - All the cool kids do agile scrum, so the cool kid wannabes emulate the cool kids to try to be cool themselves.
Ah yes, I remember when a UK government (Tory) minister in charge of the benefits system, proudly climbed to his feet and announced that the (so far failing) benefits IT system was going to move to Agile. I literally fell off my chair laughing. He knew zilch, nada, bupkiss about Agile, let alone anything to do with IT. And the project to date had been waterfall but with _constant_ political interference and scope changes. And he had got persuaded by some "special advisor" that Agile was the answer...
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.
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.
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 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.
![Yailin La Mas Viral, @kreizyk.official - Dale 2 (Remix) [Video Oficial]](http://i.ytimg.com/vi/JaYHBzgqz94/mqdefault.jpg)
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
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.
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!
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 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.
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 🙂
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.
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've seen one company that went bankrupt because of bad management. and I think scrum played a big silent role in this.
I now work in a modern waterfall environment. Lots of meetings (6 hours this week, but 2 new projects launching, so this isn't typical) but usually about 3 hours of meetings a week, and one of those is an on-call handoff for a team in China and us in the west. The org I left, and several before then, who were SAFe Agile, or Scrum, easily, double that would be normal, with periods that were even more meetings. To be honest, can't believe I'd prefer waterfall to agile in practice, because in theory, I prefer agile to waterfall. Sadly, theory and practice, as we devs know, rarely live in the same house.
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.
We sort of follow some elements of agile, in that we have a daily standup which takes about 5 minutes to state whether we had blockers from the previous day, and what we're working on that day. We don't have formal sprints, but we schedule update releases with bug fixes and requested features. Larger scale releases are timetabled, but we don't have a "You MUST get it out the door" mentality, as more often than not, we have to switch to implementing a different feature or fix at the request of the clients. The key is to be adaptable, and to keep each other informed. It doesn't need 13 hours of meetings per week which chew up the time of everybody. A quick once round the table so everybody knows what everyone else is doing, followed up a short phone call or email between people directly involved in those changes is enough. It might not be the most "modern" approach, but it works well for us, and gives us a lot more time to actually do the work. It doesn't scale well to larger teams though. We're a small company, and this working practice really does play to our strengths.
As a COBOL programmer, it is clear to me that after companies like Microsoft argued the slow and controlled environment with systems analyst driven development could save money getting rid of them, having been tempted by "saving money" the companies paying for development eventually realised that uncontrolled developers can't work, so some bright spark decided meetings and coordination was the solution.
Systems analyst based procedures and processes of controlled delegation is always the solution... "systems analyst"... this is what IBM, Siemens, NASA and MIT did and man got to the moon and banks had working systems....
The problem is that developers don't like being told what to do... actually customers (or marketing/sales) decides what a system should do and developers need to have a "translator" for those wishes to be converted to a coordinated system to meet those needs. That was the function of procedures and the specifications written by systems analysts.
The young are fools, but they get an ego trip and a high salary...;)
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
I'm so frustrated. My company teaches agile and practices it - in my opinion successfully.
Then I hear the horror stories of people hating agile with a passion, and every time it turns out they're doing something that goes against every sentence of the agile manifesto. Scrum and safe especially sound nothing like agile. Do we have to rename the thing we're doing because the middle managers of the world have ruined our good name?
Side note, my phone keeps auto correcting agile to asshole. Should I take the hint?
Ahhh, I'm just so tired of bad management. There's no framework in the world - be it waterfall, agile or anything else - that can survive managers like that. We're just end up reinventing the same ways of working with new names because it always degenerates into middle managers exerting power and destroying the company.
One issue I have experienced is that the job of a developer is to write code, learn new stuff, fix bugs, write documentation, etc. etc.
Also, when you are in the zone and you have to go to a meeting, usually unproductive, you have lost the focus and have to spend 15 minutes or so to get back into the zone again.
Worst case scenario is several meetings with an hour gap in between, so basically you will never get really productive. Better to have the meetings back-to-back and then be left alone.
The job of a project manager, however, is, for the most part, to go to meetings. Meetings with the project team, stake holders, company meetings, etc. etc.
Hence, a PM with too many holes in their calendar is not working.
And this is, I think, where poor PM's don't get the developer point of view, that meetings are a waste of time. Too often there is no proper agenda about what to discuss, so it's kind of free floating.
I have even had a PM that, during a meeting that ran shorter than the scheduled hour, said "OK, we have 30 minutes left. What should we discuss now?".
I raised my hand and asked, "Can we go back and do some work then?" The PM looked at like he didn't understand my point.
Interesting video, thanks for posting. I'm a product owner and scrum master, and have a few comments. Agile is a manifesto, not a methodology. Scrum is a type of methodology; a way of implementing Agile. A good SM will take care of their team and be careful not to put too much work on them during the sprints. Metrics are important, but not everything. I still believe Agile and Scrum are great and when done well, provide a consistent work experience and tempo for developers.
At a past job, after daily standup we would go straight into refinements. Those kind of days mentally drained me
I don't know how this came across my feed, but this is fairly on-point. The company I work for tends to have the problem of force-completing sprints and pushing to prod things that are not fully flushed out. All in the name of having increased communication and output... unfortunately it takes away from the quality of the products themselves. It appears to be a knee-jerk reaction to the fact that the rest of the company didn't used to know what was in the pipeline or when it would be deployed, so they couldn't properly work with and amplify the efforts (ex. support, marketing, etc). However, the way in which it is done seems to have resulted in the devs being burnt-out & non-communicative unless they are commanded to by their superiors, as well as siloing development status to try and offset the unreasonable timeframes... all resulting in the fact that we now _still_ don't know what's going on until it's deployed AND have less communication. All that with what I would consider a skeleton crew of devs.
As a contact lead/principle developer, the first thing I end up doing on nearly every job, is fixing the agile processes and putting it back in the hands of the development team.
We are using a more human version of scrum with: delivery meeting, task refinement, sprint planning and retrospective. That's all. So far it is a good experience and something that any company should do. Other meeting like the daily standup, 1-1 etc... are just useless.
Nowadays, Agile is being hijacked by useless project managers and business people. They use meetings to showcase their work and importance. Nine out of ten projects could be completed without them. Additionally, two-thirds of development teams spend meetings wasting time instead of coding. Only a few hardcore developers actually put in 8-10 hours of productive coding. The main problem lies with the leaders who believe they can run a company without technical backgrounds. They feel the need to hire two more project managers and nine juniors instead of keeping the four hardcore developers and tripling their salaries. In the end, it would be cheaper and five times faster, but CEOs are often coward, cheap people and unwilling and incapable to manage a company differently.
It's ultimately all about control. Agile gives employers the chance to micromanage teams. Some projects can't really be done that way but many can or are modified to fit the methodology. What i've observed is that the key outputs (that take time to do) from waterfall are the very things which are ignored in Agile implementations, the documents , the testing and the requirements analysis phases particularly. But all is not lost, some companies recognize the issues and use a modified version of Agile that does work. For instance only the middle phases are performed as sprints but the first and last phases are performed as usual. Most times an EPIC cannot be implemented in the short sprint timescales, so it is split into stories which are split into a series of sprints. That seems to work much better.
I've worked for organizations that tried to use agile/scrum in all of the wrong ways. The worst was a VP who, among other things, compared velocities across teams, assuming that story points were fixed units of work, and harassed the teams with lower velocities to get the devs to quit. What really happened was that some teams caught on to what he was doing faster and just bumped up their estimates for every single story, so they'd always be the "high performing" teams. It was complete nonsense, but this guy just wouldn't get it.
I have many years of experience working in both Agile and non Agile projects. In my experience, Agile significant decreases productivity due to the following reasons:
1) The managers mostly do nothing besides pretending to manage
2) Lots of time wasted on useless meetings which also distracts devs from their work prior to and after the meetings, further negatively impacting productivity
3) Sprints almost never correspond to the time required to complete a task and they're a useless and time wasting concept
4) The childish routines like daily's make developers feel like children, it's really demoralizing
5) Developers have to devote energy planning what they will say in the daily meetings instead of focussing solely on their work.
6) Daily's often replace or interfere with informal and much more productive meetings on topics only involving a small subset of the developers.
in my case. retrospective is skipped and it is sprint to next sprint. Got worked up easily hence better to quit
As a Network Cisco guy interesting to see how the other side of the house does things (My last job as a Senior Network Engineer/Network Lead I spent most of my time in Meetings using up all my time meaning I would have less time for the things that needed to be done on a time line)
Retired Database Architect here. Before Agile, I used to have a joke that said: “You start coding and I’ll go upstairs and see what they want”. To which everyone would laugh. Enter Agile. Now my joke is literally a methodology! What a fucking disaster software development has become. My whole world was a damn JIRA ticket!
I have seen teams prefer Kanban. They aren’t tied to a sprint, instead it’s how much we can safely add to the next release. You can still plan deadlines and scope can still flex.
Any methodology done poorly won’t end well for anyone. Unfortunately there are many well meaning but ineffective Scrum Masters, Coaches, and Project Managers. Companies have a hard time finding good ones because the hiring manager doesn’t have the relevant experience to know what to look for. So they hire mirrors of themselves.
"Planted by leadership to be spies." You're right, Dee. And to your other point, nobody declines meetings, because then you get "feedback" from people (which you can't even see who wrote it) telling your "Resource Manager" that you are not supporting the mission.
So then your Resource Manager puts you on an "Individual Development Plan", or IDP. That's basically the same thing as a PIP (Performance Improvement Plan), except that an IDP does not require management to actually begin the PIP process with HR oversight. You see, HR keeps (or used to keep) managers from violating labor law. Like laying off somebody without having proper documentation of the things they're doing wrong. Or firing them without cause.
So the IDP acts the same way as a PIP, but HR has no visibility into the IDP. And if the employee doesn't show improvement via the IDP, well then, there's always another "skills layoff" around the corner. A manager who needs to unload a few employees does not need to have a PIP on an employee in order to lay them off. Instead, the manager can just insist that it's not a "performance decision", but instead it's a "lack of skills for the role" kind of thing.
And if the manager has an IDP on the employee and the manager has documented even just a few loosely-worded instances where the employee may have done something wrong, not improved, whatever; the manager can use THAT to justify the layoff due to "lack of skills". It's really really popular for senior managers to force their line managers to make the line managers' employees engage in poorly directed remedial activities like "talk less in meetings", "don't make a person feel bad with your words", or "get 8 hours of training in this-or-that on Weekends for the next quarter".
It's childish and insulting, especially when you have to apply the Agile "manifesto" to your best, most experienced team members. You're just damaging people's careers, and I despise it with a passion.
You know you're in a truly evil organization when you have more administrators than you do available technicians on your teams. And you've reached the innermost circle of Hell when you, as a manager, realize that you have an IDP on one team member for "interrupting team members during meetings" and an IDP on another team member for "not participating in meetings". And a third IDP on yet another team member for "criticizing the Scrum Master" (or the Project Owner, Orchestrator, etcetera). Agile is a farce. It was created by bureaucrats. Continuous Development rarely works well on a 2-week sprint cycle. If your company has it, then your company hates its most skilled developers. But it all balances out in the end, because very soon, your best, most skilled developers will hate you, and then they will leave. If you don't lay them off first.
I can't agree more and imagine if you are multiple projects, you will end up delivering nothing. Plus nobody challenge the estimates that come up from the sprint plan. Everybody does not have any interest to keep the estimates low
With 46 years experience, I have seen good (supportive) managers and bad (interfering) managers and I'm in total agreement. The methodology used doesn't matter as long as reasonable procedures are used (although I think the 'latest cool pretty toy' is usually.not a real solution and can rigidify the development process)
As a project manager who learned waterfall approach we worked with our developers to map out a plan for success. When moving to Agile you need to discuss what is actually possible in those two weeks and what is NOT possible. Agile does not work when you have development that needs more than two weeks of effort. A good project manager works with their team to achieve reasonable goals. My personal goal has to work with our team to be successful but to be realistic with what can be achieved.
People don’t know how to work anymore. Several times I worked with agile, always a disaster. Too many meetings, too operational and never a clear vision. Before development please do proper design thinking first.
The #1 goal of Project Managers in most companies is to report upwards. That's it. I have even heard them say that they cannot make projects fail; they can only make it succeed. if a project fails it is someone else's fault.
Agile is about the customer and requests the developers to accept changes (quickly). Waterfall is the opposite: long development cycles with few possibilities to interact with the customer about the current result. Agile frameworks are the problem because they don‘t connect the developer with the customer finally. Scrum isn‘t „the agile way“, it‘s a working style to involve developers and manage workload. The topic stays unanswered: why and how is management causing problems by requesting to follow Agile?
I don't think Agile is all that bad, but I'm sure that the negative examples mentioned are real. I' ve been working for a major blue chip company as a PM for many years. For me, Agile is a tool box. You don't have to introduce every possible type of meeting. In my projects, (depending on project size), we have a daily scrum or just a scrum meeting every other day. Then we have sprint planning and review. We do have retrospectives, but I belive we should have less.I feel, that's all the meetings that are required for a developer to attend.
Generally, I feel the most efficient projects have a combination of waterfall and AGILE, waterfall for the big picture and the important milestones, AGILE on a more granular level. I love to have a good old-fashioned Project Plan. User Stories should be derived from that project plan. I know, I'm a bit of a heretic here, but developers should know about the essential milestones and when to meet them. In my experience the combination of a minimum amount of meetings plus a milestone plan is a guarantee for efficiency and productivity.
Agile done well has valuable and tight feedback loops across the whole process, so things like TDD and CI/CD where the team gets feedback and the process itself helps the team do better. Often I've seen teams who are moving from Waterfall to Agile over committing every sprint. Rather than taking small bite sized pieces and growing their throughput by "sharpening the axe" of their processes.
It genuinely sounds like this framework's base problem is in who attends the meetings. Like.. PM should meet with team leads, that makes sense. But it is up to the team leads to take information from that meeting down to the individual members of their teams. Which I would put on them, as they know their team. So if the most effective thing is a 10m huddle with their team in the morning - do it. If they know their people are better suited to just send them an email with the minutes from the PM meeting - do that instead. Bottom-of-the-totem-pole workers (Not meant to be derogatory, companies run BECAUSE of how essential these people are) shouldn't be continually interrupted to go to meetings that amount to high-level people talking to other high-level people about high-level things. Like... PMs should have the standard open-door policy where you can approach them with an issue, but they should almost never be approaching individuals as they don't know what they might be interrupting in workflow. That's why you have team leads. PM needs something from a section, they go find team lead and that lead will make sure it gets taken care of because they know the workflow of their specific team and when the task can be interjected without fucking things up.
Just my opinion /shrug
As an architect I'm not a fan of the perceived lack of design phase. SAFe kinda handles that but I am yet to see agile work in a large corporate environment from a control perspective
Agile is too difficult for many. If somehow everything - architecture, org structure and process - somehow align most businesses don't know what to do if one element goes out of balance. If you only know an Agile 'recipe', e.g. Scrum, without knowing the fundamentals of Lean you are almost certain to fail.
One not minor reflection about your last statement: focus on the development process instead of customers or business, surely will drive you to ruin. Computing is a subordinating discipline of business processes , producing or servicing final customers. Therefore, no matter the way you organize better to avoid the recurring burning out, accomplishment of business objectives is simply vital. I would say all efforts should be focused on making the development service understandable, predictable and trustworthy . While the more business people consistently see awkward, non-emphatic, arrogant who never accomplish a deadline developer , therefore the more will fantasize about replacing you people with a robot.
Agile does not fit into corporate paradigm driven by finance outcomes. That is costs can be predictable, and then this means we need to micromanage output, add more layers, add more meetings etc. end result, you can not operate Agile, and at best it’s a crap version of waterfall or linear project with a bunch of meetings named after the Agile methods. It’s the worst of both worlds!
I work in a agile team but since I am the only Software Engineer I am free to do whatever I want. For my projects, I use a waterfall approach since it works better and I am able to deliver higher quality features instead of crappy code that does the job but isn't ideal. The previous team followed an agile approach and today the code that they wrote is basically undocumented and unreadable, probably because they were trying to pump out features as fast as possible instead of actually engineering the project.
Sometimes I have a feeling that we are kinda being bullied by those who dont know anything about software engineering.
Agile - throw buggy code over the fence before anyone notices. Someone else can fix the problems, that's boring and difficult. A better approach is understand, design, write, test, repeat, taking the necessary amount of time for each which you won't know until you start. Get a contract for as high a price as possible, and share the money for early completion as bonus.
Scrum (Sprints) and Agile are not the same thing. Scrum is a type of Agile, so is XP and Kanban. Do not use Scrum as a synonym for Agile.
I think scrum would be best used to manage the waterfall process... let it be more receptive to scope change.
If that's done the development becomes less wasteful. That and add the software needs (core updates) as a customer.
Well, data analyst here, not software dev. - semantics - it's programming as well, just different languages. I don't even know what our system is called. We meet for a few minutes in the morning about 1.5h into the day, talking about what we did the past day and plan that day, ask for collab and such. Takes usually 15min.
On Mondays, this meeting is a meeting about what is due that week and if we can meet that deadline.
On Thursdays, the meeting is 1h as professional development where something along the line of a cool method, a new snippet or a dashboard is presented and critiqued. Could also be an intro course to a new tool or software.
1 on 1 is only once a month. We all work remote and every last Friday, we meet for lunch.
Project managers exist for a reason, the bigger the org, the more necessary they become. For better or worse. Agile is fitted into everything, and I think it might be worth asking, if that makes sense. Maybe if a company exceeds 300 (800, 1000, whatever number) employees, agile just won't fit anymore.
The problem is very often that PMs don't understand your job and feel like their only way not to loose control of the project is to micromanage it to pieces.
I am very lucky to work in a small business that doesn't have as many BS jobs having people struggle to look like they are doing something, but it happened to me a few times, and I had been quite bold protesting it, even going as far as saying : 'Either you trust me, or you fire me.' I am all about good communication and constant adjustments because most often clients don't really know what they really want and no reasonable amount of analysis will give you as much feedback as demos. But I will not stop what I am doing just to make some person feel important. If you want work done, please let me work. Nothing is more infuriating than being constantly interrupted to be told things are not going as fast as they should. No s**t Sherlock!
The one thing I have always loathed about Agile is MVP and that whole "get to market first" while missing key pieces of the puzzle.
In reality, the true answer is somewhere between Agile and Waterfall.
There are no ideas in agile which are not also covered in every other cyclic development model. What is different is the order of implementation and the importance of each component in the model. In the more classic cyclic model (such as waterfall) great amounts of effort are put into designing the entire product and an extensive review of that design before the product is implemented . Agile makes design and its documentation less important, while producing some element of implementation becomes more important. Hence, in agile, we are apt to measure once and cut many times, with all of the potential for wastage that such a process entails. With what I've just said, I think I'm repeating Dee, but I could be wrong.
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.
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.
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 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.
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.
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
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.
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.
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 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.
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.
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.
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.
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 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.
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 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.
The spy observation was on point. You're not paranoid, just aware
I can conform that this is exactly what is happening to me.
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.
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 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.
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?
My problem with all of this is: All these processes and methodologies feel like they have been created to create jobs for people who don't actually want to create things, but rather feel entitled to appear useful
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.
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.
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.
"Software engineers hate what Agile has become."
We've hated it all along. I think I first heard the term "frAgile" around 15 years ago.
As you mention Agile isnt really the issue. Having been in this game for some 30+ yrs, Ive seen production systems come and go, to name a few that I "had" to do courses on, Topdown Bottom Up, Waterfall, Kanban (of course), Agile and a number of other weird ones more relevant to manufacturing that software eng. The reality is, processes _arent_ the cause of bad development environments, people are. I have worked in _amazing_ agile projects (where I was team lead, scrum master and system architect in different projects) and I have worked in utterly chaotic and stupid agile projects. The key differences are _not_ the process, they are the people. Whether its management structure issues (this is very common in big industries like gov and defense) or whether its the ego's and developers being utterly fanatical about following strict agile processes (this destroyed one project I worked on). In one agile project I had a _single_ person be so obnoxious and just toxic to the whole team we sat down with the Chief Engineer to 'extract' them from the team and have them work on solo tasking. The team then built absolutely excellent simulation systems and solutions from then on.
So before you become "that dev" that says "oh agile sucks", look around. See what is causing the main frictions and remove them. Sometimes people just dont _like_ high communication environments, so remove them and use them more effectively. Something I will say, one of the most successful projects I helped run/develop with a wonderful team resulted in some of the best communication across disparate skillsets (3d artists, C#/C++ coders, Java coders, designers and scenario creators) which had many of these people actually expanding their skillsets and working on tasks they had never done - artists doing C# and Scripts, Designers doing C# and script, and coders jumping into Art and Design. That was actually _due_ to the agile processes we put in place to make people feel comfortable helping each other when their loads (tasking) seemed a little high. This works.
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
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.
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.
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.
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.
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 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've watched two of your videos so far and I absolutely love them. I'm not that deep in your channel yet but I'm a software engineer for a rather large name that I can't mention here because people would know it. TLDR, please read "The Phoenix Project" if you haven't already. I'm a big believer in doing DevOps (done correctly) which is not a software or just about CI/CD pipelines but about the ideals of lean manufacturing put in practice. I hope you check it out and would love a video with your thoughts. I'll go check if there is one already right now but, if not, please consider :)
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'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.
It's not going anywhere. There is too much tied up in consulting.
We have created an entire class of people whose only skill is running meetings and unfortunately, they have too much say.
Scrum should be outlawed for safety critical products. It puts unnecessary time pressure on developers and testers, which could make them overlook latent bugs in the code.
I have worked as an engineer since 1982 and as a software engineer since 1987, mostly in safety critical real time embedded software in the commercial avionics and medical device industries. Scrum is incompatible with embedded safety critical software. In making big architectural changes, a task can take much longer than a silly two-week sprint with nothing to show for it until the task is completed to some degree. The same can be said when working on low level software that interfaces the hardware, such as when you have to spend time in the lab using an oscilloscope to verify the data coming across a shift register. Sure, it doesn’t interfere with your work when doing something trivial like changing the layout of a few buttons on a GUI, but even then, with all those pointless meetings, it is a colossal waste of time. In my first DO-178 (safety critical standard) job, by not being rushed and micromanaged, I was able to discover latent bugs in an avionics product that was written in assembly language that other engineers had overlooked. It was usually a comparison statement using a variable using indirect addressing versus direct addressing. That is similar to misusing a variable that is defined as a pointer to an int as an int or vice versa. The data that was in that location just happened to be a value that coincidentally would work, but it was subject to change to something that might not work in the future. Getting things done FAST should NEVER be the primary goal in safety critical software. And I am not anti-process. Safety critical standards like DO-178B in aerospace and IEC 62304 in the medical device industry define the SDLC, but the things they define make sense, like requiring 100 percent path coverage in testing flight code, because you don’t want to be flying near an airport and find out the altitude reading froze up because the code is stuck in a while loop. All the things I see being done name of agile scrum make no sense.
Unfortunately, even some aerospace companies are starting to do this agile scrum nonsense. It has the look of - All the cool kids do agile scrum, so the cool kid wannabes emulate the cool kids to try to be cool themselves.
Ah yes, I remember when a UK government (Tory) minister in charge of the benefits system, proudly climbed to his feet and announced that the (so far failing) benefits IT system was going to move to Agile. I literally fell off my chair laughing. He knew zilch, nada, bupkiss about Agile, let alone anything to do with IT. And the project to date had been waterfall but with _constant_ political interference and scope changes. And he had got persuaded by some "special advisor" that Agile was the answer...
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.
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..
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.
Spies!!! I never thought about it that way! Your video speaks volumes! Keep up the great work! Subscribed!
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.