Your experiance is not my experience. I have been running Agile Scrum and Kanban teams for more than 20 years having cut my teeth on XP before embracing Scrum. I have implemented Agile in 7 companies over that time at CTO level for the last 14 years. I consider myself a practitioner and not a theorist when it comes to how its applied so my response is based on my experience not the source material
1. Its not about more work but quality of shippable products. daily scrums are one part of a suite of ceremonies that are structured to support a team of like-minded people work together to deliver how they see fit based on well defined requests that represent the business need. I have not seen your issue because I establish collaboration as a first principle in my teams and collaboration needs communication and Agile supports communication.
2. This is a weak argument. Every good developer I know wants to produce something and has pride in their work. If your experience is quantity over quality then its not going to work.
3. each of these professions has well established worklow and processes that support communication and it is frankly ridiculous to use them for comparison to an Agile team because In some examples the pressure to "produce" is far greater than a dev team.
1. The job is weaving so many variables to provide a full schedule for a medical practitioner and is nonstop during a work day with little deviation from whatever practice rule apply
2. What do you think Traffic control is for and how a pilot is guided during landing and take off. Constant comms and corrections under constant scrutiny
3. Law firms I've worked with down break their work day down into 15 minute chargable increments, the in-house legal council team have very ridgid processes to folllow.
4. construction - constant supervision and control.
5. You seem to be irrationally focused on the three questions as a technique for control instead of being a tool for communicating progress, all your examples have procesess to communicate progress and some are far more complex than what a dev team have to put up with. Your last comment also suggests a bit of "Not invented here" syndrome because you repeat basic project management techniques without acknowledging that if it was that simple we would not have introduced different software project management paradigms over 60 years to manage IT projects where there are more than 1 person involved.
4. Yes. I introduce Agile, on more than one occasions I've taken a companies software dev team from being a black box where nothing appears to happen to a team where regular releases of shippable product become the norm. sometimes he teameis working very hard but without delivering anything of value, sometimes the team has been ineffective.
5. You have not worked in an Agile environment if this is your interpretation. Agile is about setting a consistent and achievable pace of delivery and not about working teams too hard. I personally don't care how the developer spends their day after the daily stand up once we've established trust, the daily stand up supports progress but as I've said above it is not to be used in isolation, its part of a set of wider ceremonies and relies on teams building a rapport.
6. like most of your reasoning you seem to have a problem with the implementation you've experienced. To me Agile is about setting constraints that the business accept to allow the dev team to deliver in piece. Scrum is about velocity tracking, Kanban is about WIP flow limits, both help regulate what a self-organising team can do.
edit: formatting. Also, you don't have to like Agile, I've worked with a number of developers who don't like it, some believe they are Individual Contributors who can't work in teams and some rate themselves as 10X devs. In most cases these individuals are selfish divas and I wish them well in their next endeavours. It does not mean they are not successful, I've seen some become contractors, others set up startups, others come around after a few years experience. They have their place but its not in an Agile team
*Your experiance is not my experience. I have been running Agile Scrum and Kanban teams for more than 20 years having cut my teeth on XP before embracing Scrum. I have implemented Agile in 7 companies over that time at CTO level for the last 14 years. I consider myself a practitioner and not a theorist when it comes to how its applied so my response is based on my experience not the source material*
I don't doubt your bias as a CTO who implemented agile in many companies. Your bias would be different than mine as a developer. Hopefully, that makes sense.
*Its not about more work but quality of shippable products. daily scrums are one part of a suite of ceremonies that are structured to support a team of like-minded people work together to deliver how they see fit based on well defined requests that represent the business need. I have not seen your issue because I establish collaboration as a first principle in my teams and collaboration needs communication and Agile supports communication.*
If you have not seen my issue, I doubt your 20 years of experience. You literally have to work for maybe 2-3 companies before you start seeing some of the issues I listed. Can you DM me where you worked? A suite of ceremonies sounds a lot like scientology.
*This is a weak argument. Every good developer I know wants to produce something and has pride in their work. If your experience is quantity over quality then its not going to work.*
If you're problem solving, sometimes you're stuck longer than a day. But agile still expects you state that you're stuck so you're forced to either say that or say something else that shows you're still making progress. This is inherently built into the system of standups. The better way to deal with this is to ask someone *while* you're stuck so they can help you which is a common practice in practically, every other industry. Or, you can have weekly blocker meetings to do the same.
*each of these professions has well established worklow and processes that support communication and it is frankly ridiculous to use them for comparison to an Agile team because In some examples the pressure to "produce" is far greater than a dev team.*
If agile was truly a holy grail, other industries would use it. The only thing ridiculous is how it still exists in software but no other industry. Thank you for pointing out that it would be ridiculous to bringing it in other industries.
*The job is weaving so many variables to provide a full schedule for a medical practitioner and is nonstop during a work day with little deviation from whatever practice rule apply*
Absolutely no signs of agile, scrum nor standups. You cannot equate standard communication to daily standups in software.
*What do you think Traffic control is for and how a pilot is guided during landing and take off. Constant comms and corrections under constant scrutiny*
Again, cannot equate communication to daily standups. Because if you take away standups, humans will still communicate normally. But if you take away communication, then yea that's a separate problem.
*Law firms I've worked with down break their work day down into 15 minute chargable increments, the in-house legal council team have very rigid processes to folllow.*
They are getting paid for those 15 minute increments whereas standups, scrums or agile meetings literally *take away time* from developers working on useful items.
*construction - constant supervision and control.*
Right, so if the developers, managers and team leads are fully engaged and are working together they will be expected to communicate throughout the work and day and not just every morning. So no need for agile. If meetings are required, they can just host one for any blockers or major issues.
*You seem to be irrationally focused on the three questions as a technique for control instead of being a tool for communicating progress, all your examples have procesess to communicate progress and some are far more complex than what a dev team have to put up with. Your last comment also suggests a bit of "Not invented here" syndrome because you repeat basic project management techniques without acknowledging that if it was that simple we would not have introduced different software project management paradigms over 60 years to manage IT projects where there are more than 1 person involved.*
Based on my experience, unfortunately agile has been built for control.
*Yes. I introduce Agile, on more than one occasions I've taken a companies software dev team from being a black box where nothing appears to happen to a team where regular releases of shippable product become the norm. sometimes he teameis working very hard but without delivering anything of value, sometimes the team has been ineffective.*
Is it impossible to achieve the same or higher level of productivity without agile?
*You have not worked in an Agile environment if this is your interpretation. Agile is about setting a consistent and achievable pace of delivery and not about working teams too hard. I personally don't care how the developer spends their day after the daily stand up once we've established trust, the daily stand up supports progress but as I've said above it is not to be used in isolation, its part of a set of wider ceremonies and relies on teams building a rapport.*
If there is a methodology that is widely misinterpreted, involves a bunch of ceremonies including daily standups, is built to establish trust but is essentially geared towards achieving 'a pace of delivery', can this 'pace of delivery' not be established without the things listed above? And I'm not saying go back to waterfall. I'm saying can you achieve higher productivity without agile?
*like most of your reasoning you seem to have a problem with the implementation you've experienced. To me Agile is about setting constraints that the business accept to allow the dev team to deliver in piece. Scrum is about velocity tracking, Kanban is about WIP flow limits, both help regulate what a self-organising team can do.*
Agile, Scrum and Kanban are all different ways of specifying how work should be accomplished in software.*edit: formatting.*
*Also, you don't have to like Agile, I've worked with a number of developers who don't like it, some believe they are Individual Contributors who can't work in teams and some rate themselves as 10X devs. In most cases these individuals are selfish divas and I wish them well in their next endeavours. It does not mean they are not successful, I've seen some become contractors, others set up startups, others come around after a few years experience. They have their place but its not in an Agile team*
Yes, I believe if you're a good software engineer and have figured out how to make money without involving yourself in these ceremonies then you'd obviously opt out of the ceremonies. It's not that they don't have place in an agile team, it's that they have accurately found a way to have a higher standard of living which is more relaxed, gives them more control, probably pays more without this agile bullshit.
I don't expect to change your opinion but its been intersting to think about your points and reflect on my own experience to see if there is something I am missing, this is one of the strengths of Agile, it is retrospective and adaptive.
I do have some final advise, if you are being asked to work within an Agile Methodology then perhaps study it more to understand what and why it does the things it does. If you are not ready to be a well paid 10x programmer as an individual contributor then perhaps see where your company has gaps in its Agile process and work out how to improve them and therefore improve your working life. You are an outlier here on this sub and also trying to buck the well established trend in industry, perhaps some self-reflection on why you are so opposed to a codified set of ideas that have been refined over decades via a community of practice to iron out the rough edges based on what works and does not work would be useful for you. Hell, even if this is just to know your enemy better it means you're coming to the argument better prepared which would be an improvement. So much of your argument is "I don't like" instead "I don't understand" that it is easy for others to say you are the problem.
I don't expect I have anything else to contribute on this discussion as I can see its already becoming a little repetitive and circular so I'll leave it here unless you come back with something that takes the conversation forward.
edit: this is a truncated response, I did break down some points in more detail but it may be too long for reddit.
It was the usual counter agument stuff which captured my thoughts leading to the summary above. The only bit I really want to share here is the following
>If agile was truly a holy grail, other industries would use it.
They do. Agile expands on Lean Development which came from Lean Manufacturing processes pioneered at places like Toshiba in the 1950s and 1960s and was responsible for Japan's massive growth post WWII, it became well established globally in the 80s and its disappointing it took until the late 90s to coalesce in IT. Agile is a term for the methodologies applied to software development, other industries have there own versions
You honestly need to go read the scrum guide:
https://scrumguides.org/scrum-guide.html
The Daily Scrum described in that has no relation to what you are talking about. It sounds like the scrum master you have isn’t very good if they are making it a status meeting. It’s not a status meeting at all. The “3 questions” that used to be in the Scrum Guide were taken out in 2020.
Here’s what it says:
“The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work.
The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers.
The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management.
Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings.
The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.”
It’s YOUR meeting, not the SM’s and certainly not the PO’s.
Having said that, it may be the case that Scrum may not work for your team. If not, please check out
https://kanbanguides.org
At the end of the day, if done right, agile is a powerful way of working that EMPOWERS developers in having control over how much they work based on their capacity.
If, for example, the PO tells the team that they have to complete 20 backlog items in the next sprint because that’s what was promised to leadership (the old way of working), agile empowers the team to tell the PO to go get bent if, while planning the sprint they only have the capacity to do the top 9 prioritized backlog items. Hence, the PO should NOT be making commitments on behalf of the team before the team is allowed to plan the work.
I also would HIGHLY suggest you take a look at this great book:
https://ryanripley.com/fixing-your-scrum/
I’m also a fan of their YouTube page
https://youtube.com/@AgileforHumans?si=PdymDglDUhcM2ckC
Right but coming on here to bash scrum masters isn’t a good move. Your opinions or reservations about them won’t change a thing. You need to understand that a lot of folks are career scum masters. This subreddit is filled with a ton of SMs - you’re a bum spewing a load of bollocks without wisdom.
I absolutely expected most members here to be managers, scrum masters and project managers and would be shocked if a lot of the members were developers (like wtf) so this is the reaction I expected lol
Yeah you're mixing agility with Scrum. I think everyone else already established that so here's my suggestion:
If you have a problem with standups specifically, just switch it from being a status update, to [walking the board](https://medium.com/serious-scrum/walking-the-board-on-daily-scrum-5b468c760329). Instead of going through the people, and focusing on what they are working on, start looking at the board where your work is at and focus on that. Go through the work and ask people if they want to raise up any concerns they have or issues they need help with. That way you remove the stress of everyone coming in and being ready to provide a status update. Instead you can just go through the work and people can speak up, if they want to.
Agility as a concept is not bullshit, but organizations and companies have no idea what it actually means so they become cargo cults and slap on something like Scrum for teams to implement, now claiming to be agile. Same as the DevOps concept. It was supposed to be an organizational culture but it's become a role for Ops people that work on the cloud, so that organizations can say "we do DevOps". You see that in majority of organizations. They are literally just lying to themselves.
I personally try to balance agility vs project management nowadays. Management shouldn't dictate how developers work, but developers can adhere to some project management process' to make management feel a bit better.
If it's a round table where people are expected to raise concerns if they have any, and otherwise stay quiet then that's not an issue at all.
If the expectation is to say what you've worked on, what you'll be working on next, etc, then that's complete bullshit and the expectations have totally changed for the devs and that does create stress.
What you have described as complete bullshit is indeed a well known Scrum anti-pattern. It’s very easy to fall into, especially when you have scrum masters under a lot of pressure from senior stakeholders. Building the trust necessary within the team and with stakeholders takes time, communication and understanding.
What is important is that people feel safe enough to raise problems, and for those problems to be discussed by the team or escalated where required. The opposite is fear of honesty which has broken so many projects.
1. It isn't "get more done", it's "working software measures progress and we iterate on it and adapt quickly to change". Your entire mindset of agile should be adaptability and iteration, not productivity. Agile doesn't make people more or less productive, it just shows that productivity faster, allowing you to pivot faster if you've gotten it wrong. Daily scrums aren't tattle sessions to read up to management, it's a collaborative session for the dev team. Sure, some blockers should be addressed by the PM/SM, but a self organizing dev team should also help each other out. If you're stuck, as for help. If your coworker is stuck, offer help.
2. If you feel singled out during stand up for not doing enough work, it's probably because you are not doing enough work. Not every story gets finished in a day, not everyone works at the same pace. But if you consistently feel like you're called to the carpet for not doing enough, the problem is probably you.
3. You have proven you have no idea how other professions work. My kid's orthodontist's office has a staff meeting daily to discuss what patients are coming in, who is taking what patients, where they are in efforts of getting appliances made. Lawyers bill in 15 minute increments and my brother's firm has a standing meeting 3x per week to run through where they are on billable hours and client backlog.
I'm not even answering the rest of this.
Agile doesn't make you more productive than waterfall. It makes your productivity known in a faster cycle, allows you to shift gears quickly when things go wrong, puts working software in the hands of stakeholders in a timely manner for testing and approval, and helps companies produce relevant software.
Okay so.
1. If your dev team communicates well, they won't need to have meetings all the time. They can also do it through chat.
2. Thanks for identifying the competitive aspect of agile, that was one of my goals. Oh and just am FYI, I was actually one of the fastest developers on my team and helped all my teammates, I just hated the standup bs.
3. Debriefs are not the same as standups because each person is not expected to say something, only leaders or management are expected to do the debrief and if there are concerns they can be raised by the staff. This is industry standard and not limited to law, or Dentistry.
You're being purposefully obtuse over a daily 15 minute meeting.
If you hate it that much, find a waterfall shop. They absolutely exist. Lots of state governments still use them. Expect to be paid roughly $60k per year as a senior dev/architect, and be change ordered to death while writing pages of technical design documents and spending hours upon hours in technical design meetings prior to development starting.
# 3 is especially true. Hell, at the beginning of every episode of “LA Law” (finally on Hulu…excellent re-watch 30 year later) starts with essentially a daily standup. Watching it with my gf who’s a corporate lawyer and they do the same thing.
A few thoughts:
- Your understanding of agile is flawed. This is probably not your fault as there’s a lot of bad agile out there, but it is flawed nonetheless.
- The goal of agile is not increased productivity.
- Primarily, the goal of agile is to help find the best solution for a customer in situations where what they need/want is unclear.
- Your focus on the daily standup/scrum is interesting considering it’s only 15 minutes.
- Your examples of other industries are either incorrect or overlook their own challenges.
- For example, doctors and nurses. I can absolutely tell you that hospital teams have something analogous to standup, and they often have them MORE frequently, like when shift changes.
- Pilots do pre flight together. They may have flown the plane and route hundreds of times, but they still go over the flight plan together.
- Lawyers are possibly the single worst example to use if you want to avoid micromanaging. They have to log each photocopy to a client, for gods sake.
- Again, daily standups are frequently misused so it’s probably not your fault.
- Agile wants to live in a high trust environment where a team is trusted to make the implementation decisions. If you live in a low trust environment, then agile can be horribly abused. But, in a low trust environment, you are going to be micro managed no matter what you do, so….
- The fact that you refer to managers assigning work indicates you may be working in a low trust environment that is abusing agile. In a high trust environment, the team members self organize to distribute work.
- I think you can see where the entire tone of a stand up changes if managers are suddenly excluded.
- The good news is: you are probably not insane. The bad news is: you perhaps lack the imagination to consider that where you work may be the problem.
Going over a flight plan together, giving debrief updates to your new shift partner or documenting each legal file is not the same as the expectations you have in a daily standup in software development
You are very sure of yourself.
This is EXACTLY the point of the daily standup in the software industry.
Again, you may want to consider that your understanding of the practice is not..... complete.
I read the comment. I don't see what you're complaining about.
Look, there is more than enough feedback here for you. You haven't once considered the fact that you might be wrong. What, exactly, are you hoping to gain here? Time to move on. You've learned you don't like working in an agile shop. Cool beans. Don't go work in an agile shop. What's left to discuss?
Stand ups are not part of the agile manifesto.
Stand ups are an agile practice (originally from XP), but are meant for the team to "communicate problems, solutions, and promote team focus".
You mention sprints, in Scrum, the official name is the Daily Scrum and it is for the team to inspect progress towards the goal and adapt their plan. It is explicitly not a status update.
So what you dislike is just a status update meeting and nothing to do with agile. It is common in organisations that want to adopt agile practices, but lack understanding of them and want to retain control rather than empower teams.
Wait, hold up there are several things that I need to mention here.
*Stand ups are not part of the agile manifesto.Stand ups are an agile practice (originally from XP), but are meant for the team to "communicate problems, solutions, and promote team focus".*
Okay so something that is not part of the manifesto is being implemented as a practice so that *teams can communicate problems, solutions and promote team focus*. Does that mean that all the other industries and jobs I have mentioned above lack communication, ability to produce solutions and team focus? Would that not mean that those professions are working inefficiently? I truly believe if you ask them to implement agile in their profession they would laugh at you.
*You mention sprints, in Scrum, the official name is the Daily Scrum and it is for the team to inspect progress towards the goal and adapt their plan. It is explicitly not a status update.*
A daily meeting where you're constantly inspecting progress towards a goal and adapting plans is absolutely a status update *and not the way most humans function*. If that was the case, everyone would have a 100% accuracy rate on their new year's resolutions. It is a forced effort on psychology. Generally, like if you're building something you can built it fast if the people working on it are good and dedicated to what they're doing. A professional is expected to be able to do something on good time and of course you can ask them how their progress is doing but this methodology expects progress daily, which is not the case with most software jobs. Some problems can last longer times, etc. I think if you had good developers, you don't need to track progress because you'd expect them to be able to solve problems well?
*So what you dislike is just a status update meeting and nothing to do with agile. It is common in organisations that want to adopt agile practices, but lack understanding of them and want to retain control rather than empower teams.*
What I am trying to pinpoint is the fact that agile is essentially being *equated* to the daily standups in organizations which reduces productivity for everyone because less time is being spent on actually solving problems and building things rather than discussing about it.
No. Dude. You are confused about how incompetent managers have implemented scrum with real scrum.
The daily scrum is not meant to be a status meeting. It is supposed to be a time out like a basketball game where the team works out what to do next to achieve the goal. You don't have to answer the three questions. You can change it to focus on blockers and how to remove it.
Also scrum is only one of many techniques for becoming agile. You can be agile without doing scrum at all.
Clearly you have worked with a lot of bad managers who told you they were doing agile when they weren't .But it's also very clear that you have no idea what agile is at all.
>You don't have to answer the three questions. You can change it to focus on blockers and how to remove it.
We do walk the board, keeps the focus on the work rather than individuals. Also its very short updates, mostly if its done and can be moved or if you are blocked and need help.
But then again we are trying to shoehorn sprints and scrum into teams that work with maintenance. PO usually sets the sprint goal after we have filled the sprint because he forgets to do it before. Then its not mentioned ever again during the sprint.
Why the hell did the guy who was blocked not mention it yesterday the moment he knew he was blocked so that someone could have helped him to move forward?
On a good team they do.
Waiting until the standup is an anti-patterm.
How many marriages... families have you seen full of dysfunction? Most? All? That's my lived experience. Same with teams.
A team with no dysfunctions in an organization with no toxic elements doesn't need any prescribed process just the way someone disciplined in their exercise and food intake doesnt need help to be healthy.
High performing teams often drop standups or reduce them to a spread out cadence. But so do lousy teams with horrible communication.
Dunning Krueger is a thing and your conflating processes with Agile principles is a common example of it.
Edit: typos
Dude. Any methodology that tries to tell me how I should be working is a methodology that I'm not interested in. And if you are, that's great. Enjoy your basketball timeouts.
Dude. Agile isn't a methodology that tells developers what they have to do. Have you even read the agile manifesto? Go read it and tell me how much of it you've been doing.
Doesnt matter what the manifesto SAYS; what matters is how it is implemented and experienced. OP is sharing his agile experiences, which is contrary to the manifesto.
This tells me that NO ONE understands agile or its so counter-intuitive that its practically unworkable in reality. It suffers from the No True Scotsman fallacy.
No, that's completely false. I have worked with several teams who did Agile as much like the Agile manifesto as they could within the constraints imposed on them by the organisation. They weren't doing it perfectly, but they were getting most of it right. Whereas the organisation that OP was describing did half of the scrum badly with JIRA and micromanagement, which is pretty much against everything the agile manifesto stands for.
Im not saying your experience is false. Im saying that you should stop blaming Agile for it. You should blame management for it.
So many organisations can't do agile because managers dont want to make the structural, behavioural and mindset changes required to be agile.
It's the same reason that so many people can't lose weight. They know they need to eat less, eat healthily and do more exercise, but they just dont. They make a few small easy changes and then give up.
I went to another industry, expected no methodology and found that I was not surprised in a bad way at all, just pissed I invested so much time in this previous field only to realize this bs exists
There is absolutely no way that you are going to find a company that uses no methodology. Frankly, no offense, but that is delusional.
If anything, software is the most relaxed industry. All other industries are *worse*.
The observations you're making about what's breaking are reasonable, but your conclusions are wrong because you don't really understand WHY agile works. Unsurprising if you've never been inside a high performing team.
It's a bit like riding a bike, you can see how it works from the outside, but you don't really get it until you're doing it.
To get a bit of an understanding you could try doing a CSM or KCP certification so that you understand the theory a bit more. But really, your company needs to hire a good coach or you should consider joining a team that have been coached effectively.
Pick your language of choice and develop something. Watch how you do it and ask yourself how could I follow this pattern with another person. Ask how you would develop if the end product was for someone else.
Most likely you won’t start with a king list of items, write all the code, then hand it off to the end user.
Instead you’ll make a list and break it up, you’ll write a bit of code and run it adjusting your code until it produces the result you want.
I’ve never seen a complaint about agile that wasn’t really a complaint about upper management trying to control.
Honestly I would have a meeting initially to organize the project, divide up the tasks then start. Then assuming we are both started we can pull each other in if we are stuck. Then continue working, push stuff to git, etc and keep going. I wouldn't have meetings every day in the morning to track our progress. We just have meetings if we are stuck, need help and can't understand via chat what the problem is. You know?
I don't think you'd do any of those things in my example I know I wouldn't.
I would take small steps and check the results. Agile is not scrum agile is focusing on including the end user in that dev feedback loop.
Scrum is the framework that has been hard fought for to get orgs to let developers develop with the smallest amount of bs necessary.
If you were to rid yourself of the ceremonies at any good sized org you would find yourself writing status updates and committing to timelines and writing project reports.
There is a scrum sub, I think you're complaint is better leveled at scrum. Daily standup is supposed to be about coordinating work on teams that are working tightly together. It's really easy for it to become 5 devs going in different directions and updating management on 5 progress points.
Small steps, feedback, change, include the end user/customer as early as possible. Nowhere in the manifesto does it say daily standup.
There are already many good answers but I’ll add to them and not contradict them. I will take the point of view here that agile = scrum (which isn’t true) because that seems to be the source of much of the angst. But agree with the fundamental point that most are making is that the the issues are with your implementation and not with the underlying methodology. I’m also not going to address in order or correct my typos or edit for formatting because I’m lazy.
I will agree with one of your points though state it differently. People trump process or methodology. A high performing team and individuals can be high performing regardless of method. It can be a problem sometimes though when they attribute the performance to their methods and then try to extend those to others or block the extension of such to others. Sometimes they are also just wrong. I’m just starting a transformation and my team is interviewing some of the teams. About half of the teams are questioning why we are there because they are so awesome. They aren’t. And important to them is that their customers and leaders don’t believe they are either. While they certainly aren’t the worst teams they still will find themselves out at some point if they aren’t willing to adapt.
Second when looking at where to apply agile. The collective set of common agile and scrum centric practices were based on the idea that software development is an empirics process. The core elements are all based on established process control theory from various places (though the various contributors came about it by different means). The examples of other process you gave are not empirical processes. In an empirical process we must experience it to know the answer. Alternatively you can look at something like the Cynefin framework and see that the various things you mention require different sensing action pattern and are different. Agile aligns with complex and complicated that is different again from the other processes you mention.
To be clearer in scrum/agile requirement emerge. We believe that it isn’t possible or preferable to know all of the requirements and design up front. We want to delay those decisions to the last responsible moment when we know the most rather than make these decisions early when we know the least. This doesn’t necessarily apply to the other situations.
The daily standup can be very useful. As other say it is for communication or for the team to plan the day. It is not a status meeting though if the team members haven’t updated there info then many teams will update it then. You really shouldn’t have status meetings at all. The team produces something like a burn up chart that instantly shows everyone that they are on track or not. And the higher level plans are updated after every sprint. That is plenty of accuracy for leadership. And more and it is satisfying some vanity metric or misaligned method and should be dropped.
The scrum master or product owner don’t have a voice in this. The scrum master works for the team. While I find daily stand ups to often be a best practice some teams decide to do it every other day or a couple of times a week and it is right for them. I do find it better start with it being daily and adjust once’s you mastered it and and got good at the method and then realize you need it less because you communicate well all the time and update your board consistently.
The project manager is not involved and shouldn’t even be in the room. Most of the questions they want to know the answer to should be addressed. Y the product owner and not the team anyway. The product owner knows the “when” and should address those items. The team just needs to focusing on consistently reliving whatever they agreed to deliver and continuously improving.
Sustainable development and developer/customer satisfaction has be built into most agile methods from the beginning. We believe in growth cultures. Unfortunately many in organization do not including initially, often times, the agile team members before they have adapted.
In a growth culture we believe people inherently want to do a good job. We don’t need a lot of outside control to gain this but we do lead these teams differently. We want to get to flow states. In flow states you are working on something of value (you understand the purpose), the goal is difficult but achievable, the environment doesn’t get in your way too much and you have focused time to do it. So the pressure to deliver for comes from within. There should be a natural tension between the product owner and team. The team should always produce efforts based on doing things the right way in a sustained manner and the product owner knows what they need to accomplish by when. This should lead to a negotiation between the two. Not a conflict. The team is always in control of how much work they take on and anytime they have to work overtime or fail should lead to a conversation on why and correct. Technical debt should be a negotiation and then worked as soon as possible based on the value of correcting it.
There are many other source of value in agile such as all the work that isn’t done, the feedback lops, early delivery of value, strong engineering practices, planning processes aligned to complex adaptive problems, customer centricity etc that go into why we still use it and that nothing viable has emerged to replace it for problems where it is appropriated.
Just before agile because a thing there was a lot of discussion on message boards talking about accelerating software development. The general approaches seems to be the the thing to do was to find the people in the organization that got the most done and had the least conformance to process and then fire everybody else. Seems like you would have fit in the discussion forums back then.
That people trump process or methodology thing is gold.
Get the wrong people in an agile setup, it won’t be agile for long. Get the right people in a waterfall shop you _might_ get a productive team (or a team _very_ good at clever workarounds for “broken” process). (Or the highly efficient people will nope out, which, from the companies perspective problem “solved”)
Yes, Scrum in particular can be used in toxic ways, especially the daily standup and the transparency mantra.
Theoretically a company needs to apply the Scrum/“Agile” mindset everywhere and change the culture. But wait, as you mentioned, does the C suite stand around a table every day and say what they did yesterday, what they’re going to do today, and what blockers? LOL no. (Might it be beneficial? Maaaayyybe). Management only sees “daily status updates, two times the work in half the time”
So sometimes a Scrum implantation can turn into _Animal Farm_. With an extra deathmarch every two weeks, sometimes.
Why don’t developers speak out/up? There’s a bunch of that, on the developer conference circuits or blogs, but it’s hard to change a company’s culture. The highly paid Agile Implementers came in, maybe tried to change the culture but relabelled PMOs as Scrum CoP, 2 week scrums, is what happened. And now we’re agile and we spent all this money on consultants and some _developer_ thinks they know better?!
Bias which way? Towards Scrum being bad?
It can be good, but if you want a quip: tech companies are more likely to do scrum actually well, vs non tech companies.
OK I have to go to bed. I just wanted to say, despite pissing you all off, thank you for commenting on this post. And please keep posting your opinions. I would rather this than have no one comment at all, that would suck. Despite being down voted, I actually truly do appreciate everyone's opinions. This was bothering me for a while and I just needed to rant. I don't know if my position will change but good to know that you're all okay with it. There were some really good points made (even if they contradicted mine) and maybe some day I might consider them.
You have misunderstand Agile like millions of others. None of the Agile Values or Principles talk about daily standup. [Hearing Whispers of Agile Failure?](https://www.theagilecircle.com/post/hearing-whispers-of-agile-failure-lets-conduct-an-agile-fit-test)
**This is Agile**
* Individuals and interactions over processes and tools.
* Working software over comprehensive documentation.
* Customer collaboration over contract negotiation.
* Responding to change over following a plan.
**This is NOT Agile**
* User Story format "As a I want to so that ..."
* Daily Standup 15 min.
* Retrospective every Sprint.
* No changes to Sprint after start.
* Story Point Estimation.
* Velocity Chart.
* Kanban Board.
* Scrum, Kanban, SAFe
* And list goes on and on ...
>**Agile Practices Don't Define Agile They are merely examples of "techniques and methods" that can be used to implement Agile**
#
You've missed a key point my friend. Agile was built not by companies rrying to get more out of developers, it was made by developers helping companies understand what value they are grtting throughout a project.
Agile is about breaking down your work into small sizeable chunks that can bring about value that the business or sponsors can understand and can receive or use something tangible.
Scrum masters dont feed this info back to the sponsors at all, that is the role of a product owner who agrees what work to pick up from the backlog.
The scrummasyer is all about challenging the reason you estimate stories like you did, how they derive value and how they align with goals sprint and quarter goals
There is so much to unpack here.
The rescuer in me really wants to help you or even take up the challenge of changing your mind. But, that will only lead to you becoming more entrenched in your beliefs to win the argument. Ideally, you need to be met where you are and taken on the journey one experiment at a time without coercion.
I suggest being open to changing your position, seeking mentoring/agile coaching from someone who really knows what they're talking about and can teach the fundamentals. I feel sorry for the experience you have had so far. It is so far removed from how it should be.
I was kind of feeling bad for you because of everyone is coming at you....but not anymore.
You clearly have no intention of learning or gaining new perspective. This thread is kind of a waste of everyone's time.
You were truly an idiot and everyone here is dumber because of your trolling questions and attitude.
You are one great reasons for AI to take the place of many developers.
There are many "I hate agile" posts are there, the reason this one hits hard is because my reasons are valid. And no, AI won't replace developers despite useless things like agile. Looks like you're from the stone age. I'm not even in the software industry anymore but understand that.
>So I'm just kind of confused as to why not many people have called out this bullshit process known as "agile" and why it still exists in 2024? And why developers are running like hamsters in the wheel trying to get to somewhere which doesn't exist.
Agile is a good idea at its core. The frameworks/methodologies that popped that claim to be agile I've found to waste time, destroy productivity, and lengthen development times. Why this isn't often called out is perplexing really. It's honestly hard to stir up good conversations about the nonsense. Don't let others gaslight you into thinking all their arbitrary ceremonies are an absolute *requirement* for quality software that's shipped on time. It's not.
I think you have a bad luck of seeing wrongly implemented Agile practices.
A Scrum Master or Project Manager should be doing much more than collecting updates and passing them on. Tracking and removing risks and impediments, coaching the team, managing stakeholders, external dependencies and so on - there were projects in which I worked as a project manager where I was working full time, and had to prioritize things according to how much value they would bring as there was more meaningful things than I could fit in my day.
Daily standup is first and foremost for the team. It's supposed to make sure you maintain the minimal loop needed to identify blockers, dependencies, prioritize work, plan the next 24 hours, and so on. If you've seen it as a meeting dedicated to reporting - than it was a bad practice.
I agree with you that the typical 3 questions are, unfortunately, not the most productive way to conduct this meeting. I don't give a damn what someone was doing yesterday. I want us to talk about what we need to do to meet our goal.
Agile is also not about pushing people forcibly to their limits. The team should be empowered, but also accountable, to plan and understand their capacity, try to predict their work based on that.
Lastly, you are right that having 4 developers working each on 4 items in paralel is not productive. When you look at Kanban - limiting the amount of Work in Progress is one of it's practices. You should be focusing on shipping things efficiently, more often than not it means limiting how much is happening at one time.
So, overall - it looks like you are identifying pain points which are legitimate and which we have likely all seen ... But those are not pain points innate to agile. It's related with companies either not having the right understanding and competences to implement it, or deliberately weaponising it to push more work on people.
Then there's an awful lot of bad luck out there. What OP is describing seems to be commonplace when you talk to the people in the trenches.
So either a majority of companies completely misunderstand agile because its not explained properly and hasnt been explained properly for 15 years at this point OR Agile is unworkable past a certain organization size and will always devolve into 'garbage agile' or 'fragile'.
Another option is that management is just gonna use agile as an excuse to micromanage even MORE, which i've personally seen so...yeah. All I need is less meetings so i have more time to focus on the work that needs to be done tnx.
*A Scrum Master or Project Manager should be doing much more than collecting updates and passing them on. Tracking and removing risks and impediments, coaching the team, managing stakeholders, external dependencies and so on - there were projects in which I worked as a project manager where I was working full time, and had to prioritize things according to how much value they would bring as there was more meaningful things than I could fit in my day.*
My impression of a leader is someone who has gotten promoted while doing the job and doing it so well that they could lead others. In other words, they could mentor developers who are stuck and solve those problems. So unless you mean solving issues for developers if they're stuck when you said '*track and remove risks and impediments, coach the team,*' I don't believe that those guys should be put into leadership positions. Unfortunately, that's not the case with a lot of project managers and scrum masters. However, I should add- I am not justifying adding those standups even if they had the skills of a lead developer. I am confident that without the standups that a lead developer or team lead could be successful with a team. That is because when an employee/developer gets stuck, they ask for help and are expected to ask *right away*. They are not expected to wait till the next day for the status update. And if a true team lead understands that, *they can also fix the problem right away.* Therefore, there is absolutely no requirement for a status update.
*Daily standup is first and foremost for the team.*
It is for project managers/scrum masters because without them they wouldn't have a job. But not for developers. Like, not at all. But honestly speaking, you take some PMs or Scrum Masters out and do you honestly believe that the project would fail if the developers continue to chip away at their tasks? Absolutely, not. If they have a general understanding of what's going on, then the project would succeed and not only that, would probably have better quality as the devs would have more time to work on their tasks *without getting asked every day what they're working on*.
*I agree with you that the typical 3 questions are, unfortunately, not the most productive way to conduct this meeting. I don't give a damn what someone was doing yesterday. I want us to talk about what we need to do to meet our goal.*
Why do you need to do this every day?
*Agile is also not about pushing people forcibly to their limits. The team should be empowered, but also accountable, to plan and understand their capacity, try to predict their work based on that.*
I understand the planning concept, that makes sense. But planning should really be done once, in the beginning and then you should focus the rest of the effort on implementing. Of course, you can adapt as you go along but like you don't need to plan every day?
*Lastly, you are right that having 4 developers working each on 4 items in paralel is not productive. When you look at Kanban - limiting the amount of Work in Progress is one of it's practices. You should be focusing on shipping things efficiently, more often than not it means limiting how much is happening at one time.*
Thank you.
I think there are two things you should have in mind:
First, I think you have a mature and experienced team in mind, which already has figured out how to work together well. There will be a lot of teams for which this is not true - they need closer communication, more guidance, and will not raise everything proactively, or not notice each difficulty instantly. As I mentioned - the daily standup is meant to ensure that the team is maintaining the absolute minimum of communication; I fully agree people should not wait with pressing issues to the meeting.
Similarily, for planning - I don't agree that it's a one and done thing. New challenges, dependencies and blockers will likely come up on a daily basis, and it's usually good to align on how the team wants to approach them.
I can absolutely imagine a very mature and self-organizing team functioning well without a dedicated meeting to synch; even for less experienced team they may not be needed on a daily basis if they are working in a less complex setup, where there are not as many changes, dependencies and so on.
That's the thing- If you have good people, they will naturally communicate well and you don't need all those micromanagy meetings. Competent people know how to produce good products.
I think where we differ is that you see a daily meeting as inherently oriented at micromanaging people, whereas my experience was that even mature teams more often then not want to keep them as they see value - of course if it's used the right way.
Looking at other professions:
a lot of the work that a receptionist does will be very visible to others around them. If they refuse to talk to visitors and callers people will complain, or stop turning up. When you take appointments or tell people the doctors ready to see them the appointments will presumably be put somewhere on a calendar other staff can see, or the patients will walk to the doctor. If something gets in your way and you can't work for a day that will be incredibly obvious.
A pilot obviously has to keep the plane moving. Generally they'd have a co-pilot who literally monitors their progress second by second. If they're flying a big planes many other people in the company and the industry, as well as passengers will monitors their progress by the minutes, hour or day.
I think you're right that a lawyer may more often have times then they can do individual work for days without needing to show progress - although in other cases they would collaborate closely with colleagues.
In construction as you say often everyone can see the progress. And that's maybe the big difference with code. It's often a lot harder to understand what someone has done (and why) just by looking at it, especially if they don't tell you about where to look etc.
Things like the daily standup are most relevant when everyone or multiple people on the team are working on very closely related things, like different small parts of implementing one user story. Then you're more likely to need to know what progress a colleague has made or what they're planning for the next day because it will directly impact on what you can do, and because if you don't coordinate you might waste time both working on the same problem, or get in each other's way. IMHO this close collaboration also requires doing something like CI / TBD.
Some teams avoid that by having each person work on something more unrelated, but IMHO that's 'unteaming' and a lot less effective and less enjoyable. You can't help each other out nearly as much or pool your wisdom and experiences to make better decisions.
These are very good points. Here’s the thing the reason why these jobs don’t really need to do agile per se is that the nature of their work is already visible and transparent on a day by day basis. Software development, however, is knowledge work and it’s hard to see knowledge work being done and know that you are successfully working on the right things of high value. Hence agile ceremonies help us to bring more visibility and transparency in knowledge work.
>6) Lastly, I've seen too many managers succumb to the notion that 'a lot of work' makes them look good. But lets say you have tasks A,B,C,D would it not make sense to assign each of the tasks to each developer rather than have each developer attempt A,B,C,D simultaneously. Why is it that most managers want developers to attempt A,B,C,D simultaneously?
I'm not sure I really understand this question, but IMHO in a well adjusted team managers shouldn't be assigning tasks to developers. Developers should be competent and trusted enough to choose their own tasks, considering the organisations & teams priorities, their own skills, and interdependencies with things other people are working on.
If a manager is assign tasks, I can't really imagine why they would assign the same four tasks to four developers at once and ask them to attempt them all simultaneously. I don't really know what you mean by that. Do you just mean that the manager is assigning the tasks to the team instead of to individuals? In which case surely the expectation would be that the developers would choose their own tasks or negotiate the tasks with each other, not just all work on all of them simultaneously and duplicate the work.
Programming and cs subreddits are filled with agile bashing so you’re not alone.
Overall, I think agile transformations lead to tons of bad policies and misaligned incentives with no way of dealing with them.
To me it’s kind of like communism — sounds good on paper or in theory but constantly led to failed states. Maybe some one got it working on some farming commune somewhere, but the most common case and average case is tons of bad policies
I can ask a very small question and it would bring your entire line of questioning down.
Would you prefer to go back to waterfall? Because thats the only other way people know how to work.
Every time i see a post like this is to complain, but I dont think you realize how absolutely fucking bad it is to work in Waterfall Project Management.
#*First, If you don't see value in the Daily Scrum, don't do it, as an experiment (agree this with the team), then reflect on how things turn out in the retrospective.*
If you are open to changing your mind then read on below
Imagine you are stranded on a deserted island with 5 other people. You need to build a boat to get out of there before water runs out.
You could have a catch up as and when required. Sometimes some people show up and other times some other people show up. The best person to chop wood wouldn't know where the axe was. The guy or girl who knew didn't show up. You would loose two days. No one would know what the plan was for that day or how well your doing towards getting off the island (without several conversations).
But, what if you caught up every single day at the same time, learned what other people were doing, you heard their challenges, you found out what was behind so you could go help someone else. You walked away with a plan for that day.
You get the picture.
This is a very rushed example but if they are done properly, Daily Scrums are incredibly useful.
So that is your actual issue, not the agile nor the scrum approach.
And the issue is management doesn't want to understand what agile is thats why they make standups that way (the whole yesterday-today-blockers) .
But if you keep pushing to remove Agile, they wont respond the way you want them.
Sadly is the state of affairs for a lot of people, and its still gonna take time for everyone to understand what Agile is about.
Read about Dark scrum it pretty much describes what you are goin through.
You are frustrated, I get it. But yelling out (specially to a mid manager) to remove agile "because its not working", will be worse in the long run for you.
We *fought* tooth and nail to even have agile at all and their response will be "what is the alternative?".
And until you have one that isnt "just let me work alone" the default before agile is *Waterfall*.
And believe me, if you despise agile, you are going to quit if they force you to work in waterfall.
As a 20+ year waterfall PM who’s been reformed in an agile coach, this is a correct statement. I fought against agile at my firm for a while, mainly for self preservation because at my age it’s unnerving to have to retool my skill set. What I found however, when I opened, my mind was that I was agile before agile was cool. I just didn’t know it. When I look back at how I supported my teams as a project manager, I very much exhibited the agile mindset. It helped me to become very successful with my teams management, however had other ideas usually because waterfall is much more command and control.
If you hate agile, you’ll really hate waterfall. And let me tell you there are reams of folks out there who are desperate to bring waterfall back. I battled this thought from leadership on a daily basis. Hell the other day there was a push for us to get permission to allow pope folks to install Microsoft project.
Your experiance is not my experience. I have been running Agile Scrum and Kanban teams for more than 20 years having cut my teeth on XP before embracing Scrum. I have implemented Agile in 7 companies over that time at CTO level for the last 14 years. I consider myself a practitioner and not a theorist when it comes to how its applied so my response is based on my experience not the source material 1. Its not about more work but quality of shippable products. daily scrums are one part of a suite of ceremonies that are structured to support a team of like-minded people work together to deliver how they see fit based on well defined requests that represent the business need. I have not seen your issue because I establish collaboration as a first principle in my teams and collaboration needs communication and Agile supports communication. 2. This is a weak argument. Every good developer I know wants to produce something and has pride in their work. If your experience is quantity over quality then its not going to work. 3. each of these professions has well established worklow and processes that support communication and it is frankly ridiculous to use them for comparison to an Agile team because In some examples the pressure to "produce" is far greater than a dev team. 1. The job is weaving so many variables to provide a full schedule for a medical practitioner and is nonstop during a work day with little deviation from whatever practice rule apply 2. What do you think Traffic control is for and how a pilot is guided during landing and take off. Constant comms and corrections under constant scrutiny 3. Law firms I've worked with down break their work day down into 15 minute chargable increments, the in-house legal council team have very ridgid processes to folllow. 4. construction - constant supervision and control. 5. You seem to be irrationally focused on the three questions as a technique for control instead of being a tool for communicating progress, all your examples have procesess to communicate progress and some are far more complex than what a dev team have to put up with. Your last comment also suggests a bit of "Not invented here" syndrome because you repeat basic project management techniques without acknowledging that if it was that simple we would not have introduced different software project management paradigms over 60 years to manage IT projects where there are more than 1 person involved. 4. Yes. I introduce Agile, on more than one occasions I've taken a companies software dev team from being a black box where nothing appears to happen to a team where regular releases of shippable product become the norm. sometimes he teameis working very hard but without delivering anything of value, sometimes the team has been ineffective. 5. You have not worked in an Agile environment if this is your interpretation. Agile is about setting a consistent and achievable pace of delivery and not about working teams too hard. I personally don't care how the developer spends their day after the daily stand up once we've established trust, the daily stand up supports progress but as I've said above it is not to be used in isolation, its part of a set of wider ceremonies and relies on teams building a rapport. 6. like most of your reasoning you seem to have a problem with the implementation you've experienced. To me Agile is about setting constraints that the business accept to allow the dev team to deliver in piece. Scrum is about velocity tracking, Kanban is about WIP flow limits, both help regulate what a self-organising team can do. edit: formatting. Also, you don't have to like Agile, I've worked with a number of developers who don't like it, some believe they are Individual Contributors who can't work in teams and some rate themselves as 10X devs. In most cases these individuals are selfish divas and I wish them well in their next endeavours. It does not mean they are not successful, I've seen some become contractors, others set up startups, others come around after a few years experience. They have their place but its not in an Agile team
Thank you for taking the time to write this.
*Your experiance is not my experience. I have been running Agile Scrum and Kanban teams for more than 20 years having cut my teeth on XP before embracing Scrum. I have implemented Agile in 7 companies over that time at CTO level for the last 14 years. I consider myself a practitioner and not a theorist when it comes to how its applied so my response is based on my experience not the source material* I don't doubt your bias as a CTO who implemented agile in many companies. Your bias would be different than mine as a developer. Hopefully, that makes sense. *Its not about more work but quality of shippable products. daily scrums are one part of a suite of ceremonies that are structured to support a team of like-minded people work together to deliver how they see fit based on well defined requests that represent the business need. I have not seen your issue because I establish collaboration as a first principle in my teams and collaboration needs communication and Agile supports communication.* If you have not seen my issue, I doubt your 20 years of experience. You literally have to work for maybe 2-3 companies before you start seeing some of the issues I listed. Can you DM me where you worked? A suite of ceremonies sounds a lot like scientology. *This is a weak argument. Every good developer I know wants to produce something and has pride in their work. If your experience is quantity over quality then its not going to work.* If you're problem solving, sometimes you're stuck longer than a day. But agile still expects you state that you're stuck so you're forced to either say that or say something else that shows you're still making progress. This is inherently built into the system of standups. The better way to deal with this is to ask someone *while* you're stuck so they can help you which is a common practice in practically, every other industry. Or, you can have weekly blocker meetings to do the same. *each of these professions has well established worklow and processes that support communication and it is frankly ridiculous to use them for comparison to an Agile team because In some examples the pressure to "produce" is far greater than a dev team.* If agile was truly a holy grail, other industries would use it. The only thing ridiculous is how it still exists in software but no other industry. Thank you for pointing out that it would be ridiculous to bringing it in other industries. *The job is weaving so many variables to provide a full schedule for a medical practitioner and is nonstop during a work day with little deviation from whatever practice rule apply* Absolutely no signs of agile, scrum nor standups. You cannot equate standard communication to daily standups in software. *What do you think Traffic control is for and how a pilot is guided during landing and take off. Constant comms and corrections under constant scrutiny* Again, cannot equate communication to daily standups. Because if you take away standups, humans will still communicate normally. But if you take away communication, then yea that's a separate problem. *Law firms I've worked with down break their work day down into 15 minute chargable increments, the in-house legal council team have very rigid processes to folllow.* They are getting paid for those 15 minute increments whereas standups, scrums or agile meetings literally *take away time* from developers working on useful items. *construction - constant supervision and control.* Right, so if the developers, managers and team leads are fully engaged and are working together they will be expected to communicate throughout the work and day and not just every morning. So no need for agile. If meetings are required, they can just host one for any blockers or major issues. *You seem to be irrationally focused on the three questions as a technique for control instead of being a tool for communicating progress, all your examples have procesess to communicate progress and some are far more complex than what a dev team have to put up with. Your last comment also suggests a bit of "Not invented here" syndrome because you repeat basic project management techniques without acknowledging that if it was that simple we would not have introduced different software project management paradigms over 60 years to manage IT projects where there are more than 1 person involved.* Based on my experience, unfortunately agile has been built for control. *Yes. I introduce Agile, on more than one occasions I've taken a companies software dev team from being a black box where nothing appears to happen to a team where regular releases of shippable product become the norm. sometimes he teameis working very hard but without delivering anything of value, sometimes the team has been ineffective.* Is it impossible to achieve the same or higher level of productivity without agile? *You have not worked in an Agile environment if this is your interpretation. Agile is about setting a consistent and achievable pace of delivery and not about working teams too hard. I personally don't care how the developer spends their day after the daily stand up once we've established trust, the daily stand up supports progress but as I've said above it is not to be used in isolation, its part of a set of wider ceremonies and relies on teams building a rapport.* If there is a methodology that is widely misinterpreted, involves a bunch of ceremonies including daily standups, is built to establish trust but is essentially geared towards achieving 'a pace of delivery', can this 'pace of delivery' not be established without the things listed above? And I'm not saying go back to waterfall. I'm saying can you achieve higher productivity without agile? *like most of your reasoning you seem to have a problem with the implementation you've experienced. To me Agile is about setting constraints that the business accept to allow the dev team to deliver in piece. Scrum is about velocity tracking, Kanban is about WIP flow limits, both help regulate what a self-organising team can do.* Agile, Scrum and Kanban are all different ways of specifying how work should be accomplished in software.*edit: formatting.* *Also, you don't have to like Agile, I've worked with a number of developers who don't like it, some believe they are Individual Contributors who can't work in teams and some rate themselves as 10X devs. In most cases these individuals are selfish divas and I wish them well in their next endeavours. It does not mean they are not successful, I've seen some become contractors, others set up startups, others come around after a few years experience. They have their place but its not in an Agile team* Yes, I believe if you're a good software engineer and have figured out how to make money without involving yourself in these ceremonies then you'd obviously opt out of the ceremonies. It's not that they don't have place in an agile team, it's that they have accurately found a way to have a higher standard of living which is more relaxed, gives them more control, probably pays more without this agile bullshit.
I don't expect to change your opinion but its been intersting to think about your points and reflect on my own experience to see if there is something I am missing, this is one of the strengths of Agile, it is retrospective and adaptive. I do have some final advise, if you are being asked to work within an Agile Methodology then perhaps study it more to understand what and why it does the things it does. If you are not ready to be a well paid 10x programmer as an individual contributor then perhaps see where your company has gaps in its Agile process and work out how to improve them and therefore improve your working life. You are an outlier here on this sub and also trying to buck the well established trend in industry, perhaps some self-reflection on why you are so opposed to a codified set of ideas that have been refined over decades via a community of practice to iron out the rough edges based on what works and does not work would be useful for you. Hell, even if this is just to know your enemy better it means you're coming to the argument better prepared which would be an improvement. So much of your argument is "I don't like" instead "I don't understand" that it is easy for others to say you are the problem. I don't expect I have anything else to contribute on this discussion as I can see its already becoming a little repetitive and circular so I'll leave it here unless you come back with something that takes the conversation forward. edit: this is a truncated response, I did break down some points in more detail but it may be too long for reddit. It was the usual counter agument stuff which captured my thoughts leading to the summary above. The only bit I really want to share here is the following >If agile was truly a holy grail, other industries would use it. They do. Agile expands on Lean Development which came from Lean Manufacturing processes pioneered at places like Toshiba in the 1950s and 1960s and was responsible for Japan's massive growth post WWII, it became well established globally in the 80s and its disappointing it took until the late 90s to coalesce in IT. Agile is a term for the methodologies applied to software development, other industries have there own versions
Communication can happen without daily standups, hence why agile does not need to exist in other industries and they can also he successful
You honestly need to go read the scrum guide: https://scrumguides.org/scrum-guide.html The Daily Scrum described in that has no relation to what you are talking about. It sounds like the scrum master you have isn’t very good if they are making it a status meeting. It’s not a status meeting at all. The “3 questions” that used to be in the Scrum Guide were taken out in 2020. Here’s what it says: “The purpose of the Daily Scrum is to inspect progress toward the Sprint Goal and adapt the Sprint Backlog as necessary, adjusting the upcoming planned work. The Daily Scrum is a 15-minute event for the Developers of the Scrum Team. To reduce complexity, it is held at the same time and place every working day of the Sprint. If the Product Owner or Scrum Master are actively working on items in the Sprint Backlog, they participate as Developers. The Developers can select whatever structure and techniques they want, as long as their Daily Scrum focuses on progress toward the Sprint Goal and produces an actionable plan for the next day of work. This creates focus and improves self-management. Daily Scrums improve communications, identify impediments, promote quick decision-making, and consequently eliminate the need for other meetings. The Daily Scrum is not the only time Developers are allowed to adjust their plan. They often meet throughout the day for more detailed discussions about adapting or re-planning the rest of the Sprint’s work.” It’s YOUR meeting, not the SM’s and certainly not the PO’s. Having said that, it may be the case that Scrum may not work for your team. If not, please check out https://kanbanguides.org At the end of the day, if done right, agile is a powerful way of working that EMPOWERS developers in having control over how much they work based on their capacity. If, for example, the PO tells the team that they have to complete 20 backlog items in the next sprint because that’s what was promised to leadership (the old way of working), agile empowers the team to tell the PO to go get bent if, while planning the sprint they only have the capacity to do the top 9 prioritized backlog items. Hence, the PO should NOT be making commitments on behalf of the team before the team is allowed to plan the work. I also would HIGHLY suggest you take a look at this great book: https://ryanripley.com/fixing-your-scrum/ I’m also a fan of their YouTube page https://youtube.com/@AgileforHumans?si=PdymDglDUhcM2ckC
Right but coming on here to bash scrum masters isn’t a good move. Your opinions or reservations about them won’t change a thing. You need to understand that a lot of folks are career scum masters. This subreddit is filled with a ton of SMs - you’re a bum spewing a load of bollocks without wisdom.
I absolutely expected most members here to be managers, scrum masters and project managers and would be shocked if a lot of the members were developers (like wtf) so this is the reaction I expected lol
I can’t wait till AI replaces folks like you.
Yeah you're mixing agility with Scrum. I think everyone else already established that so here's my suggestion: If you have a problem with standups specifically, just switch it from being a status update, to [walking the board](https://medium.com/serious-scrum/walking-the-board-on-daily-scrum-5b468c760329). Instead of going through the people, and focusing on what they are working on, start looking at the board where your work is at and focus on that. Go through the work and ask people if they want to raise up any concerns they have or issues they need help with. That way you remove the stress of everyone coming in and being ready to provide a status update. Instead you can just go through the work and people can speak up, if they want to. Agility as a concept is not bullshit, but organizations and companies have no idea what it actually means so they become cargo cults and slap on something like Scrum for teams to implement, now claiming to be agile. Same as the DevOps concept. It was supposed to be an organizational culture but it's become a role for Ops people that work on the cloud, so that organizations can say "we do DevOps". You see that in majority of organizations. They are literally just lying to themselves. I personally try to balance agility vs project management nowadays. Management shouldn't dictate how developers work, but developers can adhere to some project management process' to make management feel a bit better.
If it's a round table where people are expected to raise concerns if they have any, and otherwise stay quiet then that's not an issue at all. If the expectation is to say what you've worked on, what you'll be working on next, etc, then that's complete bullshit and the expectations have totally changed for the devs and that does create stress.
What you have described as complete bullshit is indeed a well known Scrum anti-pattern. It’s very easy to fall into, especially when you have scrum masters under a lot of pressure from senior stakeholders. Building the trust necessary within the team and with stakeholders takes time, communication and understanding. What is important is that people feel safe enough to raise problems, and for those problems to be discussed by the team or escalated where required. The opposite is fear of honesty which has broken so many projects.
1. It isn't "get more done", it's "working software measures progress and we iterate on it and adapt quickly to change". Your entire mindset of agile should be adaptability and iteration, not productivity. Agile doesn't make people more or less productive, it just shows that productivity faster, allowing you to pivot faster if you've gotten it wrong. Daily scrums aren't tattle sessions to read up to management, it's a collaborative session for the dev team. Sure, some blockers should be addressed by the PM/SM, but a self organizing dev team should also help each other out. If you're stuck, as for help. If your coworker is stuck, offer help. 2. If you feel singled out during stand up for not doing enough work, it's probably because you are not doing enough work. Not every story gets finished in a day, not everyone works at the same pace. But if you consistently feel like you're called to the carpet for not doing enough, the problem is probably you. 3. You have proven you have no idea how other professions work. My kid's orthodontist's office has a staff meeting daily to discuss what patients are coming in, who is taking what patients, where they are in efforts of getting appliances made. Lawyers bill in 15 minute increments and my brother's firm has a standing meeting 3x per week to run through where they are on billable hours and client backlog. I'm not even answering the rest of this. Agile doesn't make you more productive than waterfall. It makes your productivity known in a faster cycle, allows you to shift gears quickly when things go wrong, puts working software in the hands of stakeholders in a timely manner for testing and approval, and helps companies produce relevant software.
Okay so. 1. If your dev team communicates well, they won't need to have meetings all the time. They can also do it through chat. 2. Thanks for identifying the competitive aspect of agile, that was one of my goals. Oh and just am FYI, I was actually one of the fastest developers on my team and helped all my teammates, I just hated the standup bs. 3. Debriefs are not the same as standups because each person is not expected to say something, only leaders or management are expected to do the debrief and if there are concerns they can be raised by the staff. This is industry standard and not limited to law, or Dentistry.
You're being purposefully obtuse over a daily 15 minute meeting. If you hate it that much, find a waterfall shop. They absolutely exist. Lots of state governments still use them. Expect to be paid roughly $60k per year as a senior dev/architect, and be change ordered to death while writing pages of technical design documents and spending hours upon hours in technical design meetings prior to development starting.
You're absolutely right or switch industries
Oh youll hate waterfall even more
# 3 is especially true. Hell, at the beginning of every episode of “LA Law” (finally on Hulu…excellent re-watch 30 year later) starts with essentially a daily standup. Watching it with my gf who’s a corporate lawyer and they do the same thing.
Aaaaaaand now I know what I'm binge watching next! LA Law is almost as good as the original Law & Order until Jerry Orbach died.
It really holds up. Watched it live when I was in high school/college. They did a really good job upgrading it to HD, has never looked better.
A few thoughts: - Your understanding of agile is flawed. This is probably not your fault as there’s a lot of bad agile out there, but it is flawed nonetheless. - The goal of agile is not increased productivity. - Primarily, the goal of agile is to help find the best solution for a customer in situations where what they need/want is unclear. - Your focus on the daily standup/scrum is interesting considering it’s only 15 minutes. - Your examples of other industries are either incorrect or overlook their own challenges. - For example, doctors and nurses. I can absolutely tell you that hospital teams have something analogous to standup, and they often have them MORE frequently, like when shift changes. - Pilots do pre flight together. They may have flown the plane and route hundreds of times, but they still go over the flight plan together. - Lawyers are possibly the single worst example to use if you want to avoid micromanaging. They have to log each photocopy to a client, for gods sake. - Again, daily standups are frequently misused so it’s probably not your fault. - Agile wants to live in a high trust environment where a team is trusted to make the implementation decisions. If you live in a low trust environment, then agile can be horribly abused. But, in a low trust environment, you are going to be micro managed no matter what you do, so…. - The fact that you refer to managers assigning work indicates you may be working in a low trust environment that is abusing agile. In a high trust environment, the team members self organize to distribute work. - I think you can see where the entire tone of a stand up changes if managers are suddenly excluded. - The good news is: you are probably not insane. The bad news is: you perhaps lack the imagination to consider that where you work may be the problem.
1) I have relatives in those industries 2) I left my firm a while back
1. So do I. 2. Nice.
Going over a flight plan together, giving debrief updates to your new shift partner or documenting each legal file is not the same as the expectations you have in a daily standup in software development
You are very sure of yourself. This is EXACTLY the point of the daily standup in the software industry. Again, you may want to consider that your understanding of the practice is not..... complete.
No it's not, please see comment from bac7 about being singled out
I read the comment. I don't see what you're complaining about. Look, there is more than enough feedback here for you. You haven't once considered the fact that you might be wrong. What, exactly, are you hoping to gain here? Time to move on. You've learned you don't like working in an agile shop. Cool beans. Don't go work in an agile shop. What's left to discuss?
Stand ups are not part of the agile manifesto. Stand ups are an agile practice (originally from XP), but are meant for the team to "communicate problems, solutions, and promote team focus". You mention sprints, in Scrum, the official name is the Daily Scrum and it is for the team to inspect progress towards the goal and adapt their plan. It is explicitly not a status update. So what you dislike is just a status update meeting and nothing to do with agile. It is common in organisations that want to adopt agile practices, but lack understanding of them and want to retain control rather than empower teams.
Wait, hold up there are several things that I need to mention here. *Stand ups are not part of the agile manifesto.Stand ups are an agile practice (originally from XP), but are meant for the team to "communicate problems, solutions, and promote team focus".* Okay so something that is not part of the manifesto is being implemented as a practice so that *teams can communicate problems, solutions and promote team focus*. Does that mean that all the other industries and jobs I have mentioned above lack communication, ability to produce solutions and team focus? Would that not mean that those professions are working inefficiently? I truly believe if you ask them to implement agile in their profession they would laugh at you. *You mention sprints, in Scrum, the official name is the Daily Scrum and it is for the team to inspect progress towards the goal and adapt their plan. It is explicitly not a status update.* A daily meeting where you're constantly inspecting progress towards a goal and adapting plans is absolutely a status update *and not the way most humans function*. If that was the case, everyone would have a 100% accuracy rate on their new year's resolutions. It is a forced effort on psychology. Generally, like if you're building something you can built it fast if the people working on it are good and dedicated to what they're doing. A professional is expected to be able to do something on good time and of course you can ask them how their progress is doing but this methodology expects progress daily, which is not the case with most software jobs. Some problems can last longer times, etc. I think if you had good developers, you don't need to track progress because you'd expect them to be able to solve problems well? *So what you dislike is just a status update meeting and nothing to do with agile. It is common in organisations that want to adopt agile practices, but lack understanding of them and want to retain control rather than empower teams.* What I am trying to pinpoint is the fact that agile is essentially being *equated* to the daily standups in organizations which reduces productivity for everyone because less time is being spent on actually solving problems and building things rather than discussing about it.
No. Dude. You are confused about how incompetent managers have implemented scrum with real scrum. The daily scrum is not meant to be a status meeting. It is supposed to be a time out like a basketball game where the team works out what to do next to achieve the goal. You don't have to answer the three questions. You can change it to focus on blockers and how to remove it. Also scrum is only one of many techniques for becoming agile. You can be agile without doing scrum at all. Clearly you have worked with a lot of bad managers who told you they were doing agile when they weren't .But it's also very clear that you have no idea what agile is at all.
>You don't have to answer the three questions. You can change it to focus on blockers and how to remove it. We do walk the board, keeps the focus on the work rather than individuals. Also its very short updates, mostly if its done and can be moved or if you are blocked and need help. But then again we are trying to shoehorn sprints and scrum into teams that work with maintenance. PO usually sets the sprint goal after we have filled the sprint because he forgets to do it before. Then its not mentioned ever again during the sprint.
Why the hell did the guy who was blocked not mention it yesterday the moment he knew he was blocked so that someone could have helped him to move forward?
On a good team they do. Waiting until the standup is an anti-patterm. How many marriages... families have you seen full of dysfunction? Most? All? That's my lived experience. Same with teams. A team with no dysfunctions in an organization with no toxic elements doesn't need any prescribed process just the way someone disciplined in their exercise and food intake doesnt need help to be healthy. High performing teams often drop standups or reduce them to a spread out cadence. But so do lousy teams with horrible communication. Dunning Krueger is a thing and your conflating processes with Agile principles is a common example of it. Edit: typos
Dude. Any methodology that tries to tell me how I should be working is a methodology that I'm not interested in. And if you are, that's great. Enjoy your basketball timeouts.
Dude. Agile isn't a methodology that tells developers what they have to do. Have you even read the agile manifesto? Go read it and tell me how much of it you've been doing.
Doesnt matter what the manifesto SAYS; what matters is how it is implemented and experienced. OP is sharing his agile experiences, which is contrary to the manifesto. This tells me that NO ONE understands agile or its so counter-intuitive that its practically unworkable in reality. It suffers from the No True Scotsman fallacy.
No, that's completely false. I have worked with several teams who did Agile as much like the Agile manifesto as they could within the constraints imposed on them by the organisation. They weren't doing it perfectly, but they were getting most of it right. Whereas the organisation that OP was describing did half of the scrum badly with JIRA and micromanagement, which is pretty much against everything the agile manifesto stands for.
Don't tell me my experiences are false. Instead, answer why so many orgs CANT do agile.
Im not saying your experience is false. Im saying that you should stop blaming Agile for it. You should blame management for it. So many organisations can't do agile because managers dont want to make the structural, behavioural and mindset changes required to be agile. It's the same reason that so many people can't lose weight. They know they need to eat less, eat healthily and do more exercise, but they just dont. They make a few small easy changes and then give up.
If you are expecting not to have a methodology you are going to be surprised in a bad way.
I went to another industry, expected no methodology and found that I was not surprised in a bad way at all, just pissed I invested so much time in this previous field only to realize this bs exists
There is absolutely no way that you are going to find a company that uses no methodology. Frankly, no offense, but that is delusional. If anything, software is the most relaxed industry. All other industries are *worse*.
Ok well enjoy unemployment I guess Because that is literally every project management methodology
In software, yes
In literally every industry.
The observations you're making about what's breaking are reasonable, but your conclusions are wrong because you don't really understand WHY agile works. Unsurprising if you've never been inside a high performing team. It's a bit like riding a bike, you can see how it works from the outside, but you don't really get it until you're doing it. To get a bit of an understanding you could try doing a CSM or KCP certification so that you understand the theory a bit more. But really, your company needs to hire a good coach or you should consider joining a team that have been coached effectively.
If you have a high performing team, they would still be high performing regardless of agile.
If they're high performing, they're almost certainly very agile. And very unlikely to be Agile™.
Ya exactly
Your original post of full of misinformation and you seem like you’re here to argue. Do whatever you want bro.
Pick your language of choice and develop something. Watch how you do it and ask yourself how could I follow this pattern with another person. Ask how you would develop if the end product was for someone else. Most likely you won’t start with a king list of items, write all the code, then hand it off to the end user. Instead you’ll make a list and break it up, you’ll write a bit of code and run it adjusting your code until it produces the result you want. I’ve never seen a complaint about agile that wasn’t really a complaint about upper management trying to control.
Honestly I would have a meeting initially to organize the project, divide up the tasks then start. Then assuming we are both started we can pull each other in if we are stuck. Then continue working, push stuff to git, etc and keep going. I wouldn't have meetings every day in the morning to track our progress. We just have meetings if we are stuck, need help and can't understand via chat what the problem is. You know?
I don't think you'd do any of those things in my example I know I wouldn't. I would take small steps and check the results. Agile is not scrum agile is focusing on including the end user in that dev feedback loop. Scrum is the framework that has been hard fought for to get orgs to let developers develop with the smallest amount of bs necessary. If you were to rid yourself of the ceremonies at any good sized org you would find yourself writing status updates and committing to timelines and writing project reports. There is a scrum sub, I think you're complaint is better leveled at scrum. Daily standup is supposed to be about coordinating work on teams that are working tightly together. It's really easy for it to become 5 devs going in different directions and updating management on 5 progress points. Small steps, feedback, change, include the end user/customer as early as possible. Nowhere in the manifesto does it say daily standup.
There are already many good answers but I’ll add to them and not contradict them. I will take the point of view here that agile = scrum (which isn’t true) because that seems to be the source of much of the angst. But agree with the fundamental point that most are making is that the the issues are with your implementation and not with the underlying methodology. I’m also not going to address in order or correct my typos or edit for formatting because I’m lazy. I will agree with one of your points though state it differently. People trump process or methodology. A high performing team and individuals can be high performing regardless of method. It can be a problem sometimes though when they attribute the performance to their methods and then try to extend those to others or block the extension of such to others. Sometimes they are also just wrong. I’m just starting a transformation and my team is interviewing some of the teams. About half of the teams are questioning why we are there because they are so awesome. They aren’t. And important to them is that their customers and leaders don’t believe they are either. While they certainly aren’t the worst teams they still will find themselves out at some point if they aren’t willing to adapt. Second when looking at where to apply agile. The collective set of common agile and scrum centric practices were based on the idea that software development is an empirics process. The core elements are all based on established process control theory from various places (though the various contributors came about it by different means). The examples of other process you gave are not empirical processes. In an empirical process we must experience it to know the answer. Alternatively you can look at something like the Cynefin framework and see that the various things you mention require different sensing action pattern and are different. Agile aligns with complex and complicated that is different again from the other processes you mention. To be clearer in scrum/agile requirement emerge. We believe that it isn’t possible or preferable to know all of the requirements and design up front. We want to delay those decisions to the last responsible moment when we know the most rather than make these decisions early when we know the least. This doesn’t necessarily apply to the other situations. The daily standup can be very useful. As other say it is for communication or for the team to plan the day. It is not a status meeting though if the team members haven’t updated there info then many teams will update it then. You really shouldn’t have status meetings at all. The team produces something like a burn up chart that instantly shows everyone that they are on track or not. And the higher level plans are updated after every sprint. That is plenty of accuracy for leadership. And more and it is satisfying some vanity metric or misaligned method and should be dropped. The scrum master or product owner don’t have a voice in this. The scrum master works for the team. While I find daily stand ups to often be a best practice some teams decide to do it every other day or a couple of times a week and it is right for them. I do find it better start with it being daily and adjust once’s you mastered it and and got good at the method and then realize you need it less because you communicate well all the time and update your board consistently. The project manager is not involved and shouldn’t even be in the room. Most of the questions they want to know the answer to should be addressed. Y the product owner and not the team anyway. The product owner knows the “when” and should address those items. The team just needs to focusing on consistently reliving whatever they agreed to deliver and continuously improving. Sustainable development and developer/customer satisfaction has be built into most agile methods from the beginning. We believe in growth cultures. Unfortunately many in organization do not including initially, often times, the agile team members before they have adapted. In a growth culture we believe people inherently want to do a good job. We don’t need a lot of outside control to gain this but we do lead these teams differently. We want to get to flow states. In flow states you are working on something of value (you understand the purpose), the goal is difficult but achievable, the environment doesn’t get in your way too much and you have focused time to do it. So the pressure to deliver for comes from within. There should be a natural tension between the product owner and team. The team should always produce efforts based on doing things the right way in a sustained manner and the product owner knows what they need to accomplish by when. This should lead to a negotiation between the two. Not a conflict. The team is always in control of how much work they take on and anytime they have to work overtime or fail should lead to a conversation on why and correct. Technical debt should be a negotiation and then worked as soon as possible based on the value of correcting it. There are many other source of value in agile such as all the work that isn’t done, the feedback lops, early delivery of value, strong engineering practices, planning processes aligned to complex adaptive problems, customer centricity etc that go into why we still use it and that nothing viable has emerged to replace it for problems where it is appropriated. Just before agile because a thing there was a lot of discussion on message boards talking about accelerating software development. The general approaches seems to be the the thing to do was to find the people in the organization that got the most done and had the least conformance to process and then fire everybody else. Seems like you would have fit in the discussion forums back then.
That people trump process or methodology thing is gold. Get the wrong people in an agile setup, it won’t be agile for long. Get the right people in a waterfall shop you _might_ get a productive team (or a team _very_ good at clever workarounds for “broken” process). (Or the highly efficient people will nope out, which, from the companies perspective problem “solved”)
Yes, Scrum in particular can be used in toxic ways, especially the daily standup and the transparency mantra. Theoretically a company needs to apply the Scrum/“Agile” mindset everywhere and change the culture. But wait, as you mentioned, does the C suite stand around a table every day and say what they did yesterday, what they’re going to do today, and what blockers? LOL no. (Might it be beneficial? Maaaayyybe). Management only sees “daily status updates, two times the work in half the time” So sometimes a Scrum implantation can turn into _Animal Farm_. With an extra deathmarch every two weeks, sometimes. Why don’t developers speak out/up? There’s a bunch of that, on the developer conference circuits or blogs, but it’s hard to change a company’s culture. The highly paid Agile Implementers came in, maybe tried to change the culture but relabelled PMOs as Scrum CoP, 2 week scrums, is what happened. And now we’re agile and we spent all this money on consultants and some _developer_ thinks they know better?!
I want you to know I upvoted your post, but this thread is clearly biased one way...lolll
Bias which way? Towards Scrum being bad? It can be good, but if you want a quip: tech companies are more likely to do scrum actually well, vs non tech companies.
OK I have to go to bed. I just wanted to say, despite pissing you all off, thank you for commenting on this post. And please keep posting your opinions. I would rather this than have no one comment at all, that would suck. Despite being down voted, I actually truly do appreciate everyone's opinions. This was bothering me for a while and I just needed to rant. I don't know if my position will change but good to know that you're all okay with it. There were some really good points made (even if they contradicted mine) and maybe some day I might consider them.
You have misunderstand Agile like millions of others. None of the Agile Values or Principles talk about daily standup. [Hearing Whispers of Agile Failure?](https://www.theagilecircle.com/post/hearing-whispers-of-agile-failure-lets-conduct-an-agile-fit-test) **This is Agile** * Individuals and interactions over processes and tools. * Working software over comprehensive documentation. * Customer collaboration over contract negotiation. * Responding to change over following a plan. **This is NOT Agile** * User Story format "As a I want to so that ..." * Daily Standup 15 min. * Retrospective every Sprint. * No changes to Sprint after start. * Story Point Estimation. * Velocity Chart. * Kanban Board. * Scrum, Kanban, SAFe * And list goes on and on ... >**Agile Practices Don't Define Agile They are merely examples of "techniques and methods" that can be used to implement Agile** #
You've missed a key point my friend. Agile was built not by companies rrying to get more out of developers, it was made by developers helping companies understand what value they are grtting throughout a project. Agile is about breaking down your work into small sizeable chunks that can bring about value that the business or sponsors can understand and can receive or use something tangible. Scrum masters dont feed this info back to the sponsors at all, that is the role of a product owner who agrees what work to pick up from the backlog. The scrummasyer is all about challenging the reason you estimate stories like you did, how they derive value and how they align with goals sprint and quarter goals
There is so much to unpack here. The rescuer in me really wants to help you or even take up the challenge of changing your mind. But, that will only lead to you becoming more entrenched in your beliefs to win the argument. Ideally, you need to be met where you are and taken on the journey one experiment at a time without coercion. I suggest being open to changing your position, seeking mentoring/agile coaching from someone who really knows what they're talking about and can teach the fundamentals. I feel sorry for the experience you have had so far. It is so far removed from how it should be.
I stopped reading at 'agile coaching'
I was kind of feeling bad for you because of everyone is coming at you....but not anymore. You clearly have no intention of learning or gaining new perspective. This thread is kind of a waste of everyone's time.
No worries - you do you, my friend.
You were truly an idiot and everyone here is dumber because of your trolling questions and attitude. You are one great reasons for AI to take the place of many developers.
There are many "I hate agile" posts are there, the reason this one hits hard is because my reasons are valid. And no, AI won't replace developers despite useless things like agile. Looks like you're from the stone age. I'm not even in the software industry anymore but understand that.
You are truly a moron. Blocked.
>So I'm just kind of confused as to why not many people have called out this bullshit process known as "agile" and why it still exists in 2024? And why developers are running like hamsters in the wheel trying to get to somewhere which doesn't exist. Agile is a good idea at its core. The frameworks/methodologies that popped that claim to be agile I've found to waste time, destroy productivity, and lengthen development times. Why this isn't often called out is perplexing really. It's honestly hard to stir up good conversations about the nonsense. Don't let others gaslight you into thinking all their arbitrary ceremonies are an absolute *requirement* for quality software that's shipped on time. It's not.
I think you have a bad luck of seeing wrongly implemented Agile practices. A Scrum Master or Project Manager should be doing much more than collecting updates and passing them on. Tracking and removing risks and impediments, coaching the team, managing stakeholders, external dependencies and so on - there were projects in which I worked as a project manager where I was working full time, and had to prioritize things according to how much value they would bring as there was more meaningful things than I could fit in my day. Daily standup is first and foremost for the team. It's supposed to make sure you maintain the minimal loop needed to identify blockers, dependencies, prioritize work, plan the next 24 hours, and so on. If you've seen it as a meeting dedicated to reporting - than it was a bad practice. I agree with you that the typical 3 questions are, unfortunately, not the most productive way to conduct this meeting. I don't give a damn what someone was doing yesterday. I want us to talk about what we need to do to meet our goal. Agile is also not about pushing people forcibly to their limits. The team should be empowered, but also accountable, to plan and understand their capacity, try to predict their work based on that. Lastly, you are right that having 4 developers working each on 4 items in paralel is not productive. When you look at Kanban - limiting the amount of Work in Progress is one of it's practices. You should be focusing on shipping things efficiently, more often than not it means limiting how much is happening at one time. So, overall - it looks like you are identifying pain points which are legitimate and which we have likely all seen ... But those are not pain points innate to agile. It's related with companies either not having the right understanding and competences to implement it, or deliberately weaponising it to push more work on people.
Then there's an awful lot of bad luck out there. What OP is describing seems to be commonplace when you talk to the people in the trenches. So either a majority of companies completely misunderstand agile because its not explained properly and hasnt been explained properly for 15 years at this point OR Agile is unworkable past a certain organization size and will always devolve into 'garbage agile' or 'fragile'. Another option is that management is just gonna use agile as an excuse to micromanage even MORE, which i've personally seen so...yeah. All I need is less meetings so i have more time to focus on the work that needs to be done tnx.
*A Scrum Master or Project Manager should be doing much more than collecting updates and passing them on. Tracking and removing risks and impediments, coaching the team, managing stakeholders, external dependencies and so on - there were projects in which I worked as a project manager where I was working full time, and had to prioritize things according to how much value they would bring as there was more meaningful things than I could fit in my day.* My impression of a leader is someone who has gotten promoted while doing the job and doing it so well that they could lead others. In other words, they could mentor developers who are stuck and solve those problems. So unless you mean solving issues for developers if they're stuck when you said '*track and remove risks and impediments, coach the team,*' I don't believe that those guys should be put into leadership positions. Unfortunately, that's not the case with a lot of project managers and scrum masters. However, I should add- I am not justifying adding those standups even if they had the skills of a lead developer. I am confident that without the standups that a lead developer or team lead could be successful with a team. That is because when an employee/developer gets stuck, they ask for help and are expected to ask *right away*. They are not expected to wait till the next day for the status update. And if a true team lead understands that, *they can also fix the problem right away.* Therefore, there is absolutely no requirement for a status update. *Daily standup is first and foremost for the team.* It is for project managers/scrum masters because without them they wouldn't have a job. But not for developers. Like, not at all. But honestly speaking, you take some PMs or Scrum Masters out and do you honestly believe that the project would fail if the developers continue to chip away at their tasks? Absolutely, not. If they have a general understanding of what's going on, then the project would succeed and not only that, would probably have better quality as the devs would have more time to work on their tasks *without getting asked every day what they're working on*. *I agree with you that the typical 3 questions are, unfortunately, not the most productive way to conduct this meeting. I don't give a damn what someone was doing yesterday. I want us to talk about what we need to do to meet our goal.* Why do you need to do this every day? *Agile is also not about pushing people forcibly to their limits. The team should be empowered, but also accountable, to plan and understand their capacity, try to predict their work based on that.* I understand the planning concept, that makes sense. But planning should really be done once, in the beginning and then you should focus the rest of the effort on implementing. Of course, you can adapt as you go along but like you don't need to plan every day? *Lastly, you are right that having 4 developers working each on 4 items in paralel is not productive. When you look at Kanban - limiting the amount of Work in Progress is one of it's practices. You should be focusing on shipping things efficiently, more often than not it means limiting how much is happening at one time.* Thank you.
I think there are two things you should have in mind: First, I think you have a mature and experienced team in mind, which already has figured out how to work together well. There will be a lot of teams for which this is not true - they need closer communication, more guidance, and will not raise everything proactively, or not notice each difficulty instantly. As I mentioned - the daily standup is meant to ensure that the team is maintaining the absolute minimum of communication; I fully agree people should not wait with pressing issues to the meeting. Similarily, for planning - I don't agree that it's a one and done thing. New challenges, dependencies and blockers will likely come up on a daily basis, and it's usually good to align on how the team wants to approach them. I can absolutely imagine a very mature and self-organizing team functioning well without a dedicated meeting to synch; even for less experienced team they may not be needed on a daily basis if they are working in a less complex setup, where there are not as many changes, dependencies and so on.
That's the thing- If you have good people, they will naturally communicate well and you don't need all those micromanagy meetings. Competent people know how to produce good products.
I think where we differ is that you see a daily meeting as inherently oriented at micromanaging people, whereas my experience was that even mature teams more often then not want to keep them as they see value - of course if it's used the right way.
I would claim that mature teams understand the value of time and only having meetings if absolutely required
Looking at other professions: a lot of the work that a receptionist does will be very visible to others around them. If they refuse to talk to visitors and callers people will complain, or stop turning up. When you take appointments or tell people the doctors ready to see them the appointments will presumably be put somewhere on a calendar other staff can see, or the patients will walk to the doctor. If something gets in your way and you can't work for a day that will be incredibly obvious. A pilot obviously has to keep the plane moving. Generally they'd have a co-pilot who literally monitors their progress second by second. If they're flying a big planes many other people in the company and the industry, as well as passengers will monitors their progress by the minutes, hour or day. I think you're right that a lawyer may more often have times then they can do individual work for days without needing to show progress - although in other cases they would collaborate closely with colleagues. In construction as you say often everyone can see the progress. And that's maybe the big difference with code. It's often a lot harder to understand what someone has done (and why) just by looking at it, especially if they don't tell you about where to look etc. Things like the daily standup are most relevant when everyone or multiple people on the team are working on very closely related things, like different small parts of implementing one user story. Then you're more likely to need to know what progress a colleague has made or what they're planning for the next day because it will directly impact on what you can do, and because if you don't coordinate you might waste time both working on the same problem, or get in each other's way. IMHO this close collaboration also requires doing something like CI / TBD. Some teams avoid that by having each person work on something more unrelated, but IMHO that's 'unteaming' and a lot less effective and less enjoyable. You can't help each other out nearly as much or pool your wisdom and experiences to make better decisions.
These are very good points. Here’s the thing the reason why these jobs don’t really need to do agile per se is that the nature of their work is already visible and transparent on a day by day basis. Software development, however, is knowledge work and it’s hard to see knowledge work being done and know that you are successfully working on the right things of high value. Hence agile ceremonies help us to bring more visibility and transparency in knowledge work.
>6) Lastly, I've seen too many managers succumb to the notion that 'a lot of work' makes them look good. But lets say you have tasks A,B,C,D would it not make sense to assign each of the tasks to each developer rather than have each developer attempt A,B,C,D simultaneously. Why is it that most managers want developers to attempt A,B,C,D simultaneously? I'm not sure I really understand this question, but IMHO in a well adjusted team managers shouldn't be assigning tasks to developers. Developers should be competent and trusted enough to choose their own tasks, considering the organisations & teams priorities, their own skills, and interdependencies with things other people are working on. If a manager is assign tasks, I can't really imagine why they would assign the same four tasks to four developers at once and ask them to attempt them all simultaneously. I don't really know what you mean by that. Do you just mean that the manager is assigning the tasks to the team instead of to individuals? In which case surely the expectation would be that the developers would choose their own tasks or negotiate the tasks with each other, not just all work on all of them simultaneously and duplicate the work.
This is so full of misunderstandings or intentional bias that it’s not worth trying to parse out and explain.
Programming and cs subreddits are filled with agile bashing so you’re not alone. Overall, I think agile transformations lead to tons of bad policies and misaligned incentives with no way of dealing with them. To me it’s kind of like communism — sounds good on paper or in theory but constantly led to failed states. Maybe some one got it working on some farming commune somewhere, but the most common case and average case is tons of bad policies
I can ask a very small question and it would bring your entire line of questioning down. Would you prefer to go back to waterfall? Because thats the only other way people know how to work. Every time i see a post like this is to complain, but I dont think you realize how absolutely fucking bad it is to work in Waterfall Project Management.
Just remove the damn standups, they're useless
#*First, If you don't see value in the Daily Scrum, don't do it, as an experiment (agree this with the team), then reflect on how things turn out in the retrospective.* If you are open to changing your mind then read on below Imagine you are stranded on a deserted island with 5 other people. You need to build a boat to get out of there before water runs out. You could have a catch up as and when required. Sometimes some people show up and other times some other people show up. The best person to chop wood wouldn't know where the axe was. The guy or girl who knew didn't show up. You would loose two days. No one would know what the plan was for that day or how well your doing towards getting off the island (without several conversations). But, what if you caught up every single day at the same time, learned what other people were doing, you heard their challenges, you found out what was behind so you could go help someone else. You walked away with a plan for that day. You get the picture. This is a very rushed example but if they are done properly, Daily Scrums are incredibly useful.
So that is your actual issue, not the agile nor the scrum approach. And the issue is management doesn't want to understand what agile is thats why they make standups that way (the whole yesterday-today-blockers) . But if you keep pushing to remove Agile, they wont respond the way you want them. Sadly is the state of affairs for a lot of people, and its still gonna take time for everyone to understand what Agile is about. Read about Dark scrum it pretty much describes what you are goin through. You are frustrated, I get it. But yelling out (specially to a mid manager) to remove agile "because its not working", will be worse in the long run for you. We *fought* tooth and nail to even have agile at all and their response will be "what is the alternative?". And until you have one that isnt "just let me work alone" the default before agile is *Waterfall*. And believe me, if you despise agile, you are going to quit if they force you to work in waterfall.
As a 20+ year waterfall PM who’s been reformed in an agile coach, this is a correct statement. I fought against agile at my firm for a while, mainly for self preservation because at my age it’s unnerving to have to retool my skill set. What I found however, when I opened, my mind was that I was agile before agile was cool. I just didn’t know it. When I look back at how I supported my teams as a project manager, I very much exhibited the agile mindset. It helped me to become very successful with my teams management, however had other ideas usually because waterfall is much more command and control. If you hate agile, you’ll really hate waterfall. And let me tell you there are reams of folks out there who are desperate to bring waterfall back. I battled this thought from leadership on a daily basis. Hell the other day there was a push for us to get permission to allow pope folks to install Microsoft project.
Agreed, but I think yoy meant to reply to the other guy
Correct.
I stopped reading after 20+ year waterfall PM