7 ms·

> This is not to say Agile itself is bad - it takes effort and skill to use it effectively but managers seem to be taking the easy way out to create a factory l

> This is not to say Agile itself is bad - it takes effort and skill to use it effectively but managers seem to be taking the easy way out to create a factory line kind of setup where random requirements keep getting thrown and every two weeks you are supposed to roll out _a_ solution. Scrum has outmarketed "Agile", and swallowed it up wholesale. Agile was about putting people before process, Scrum is all process, no-wonder the people feel downtrodden.

blackp1nk 5y ago
Agree to this. Daily standups are the bane of many people's existence.
- vorticalbox 5y ago
  wasting time hearing about peoples work yesterday/today that I am not involved with nor has any impact on my work is a waste of every ones time.
  - jseban 5y ago
    Yeah, and that feeling of someone oversharing something both irrelevant and boring, while you already have an overfull short term memory from your own work, AND being forced to pretend to pay attention, it's just so painful.
- rypskar 5y ago
  I'm in a distributed team where the daily standups are optional. Almost everyone join every day and say it is good to see the others at least for a short while every day
  - odshoifsdhfs 5y ago
    I'm going to be that guy: They say it is good to see others or they say what is expected of them? Is like the conversation yesterday about leaving interviews. You don't say Person was is shit and an asshole but you say a better opportunity came up. Heck, even during job interviews, you don't answer 'why work here' with 'money' but 'looking for a new challenge, or interesting work or whatnot'
    - diatone 5y ago
      As someone who enjoys sharing a similar sense of humour and outlook as the people I work with, I'm personally more than happy to spend 15 minutes goofing around before a day of knuckling down and getting shit done. YMMV
  - SkyPuncher 5y ago
    I despised daily stands in person, but love them on a remote team. We've decide to drop the status updates from standups to focus solely on discussing things of interest to the team - blockers, processes, issues, announcements, icebreakers, etc.
- Consultant32452 5y ago
  My current employer's standup is now an hour long. There's only 6 developers on the team. Technically we have two standups. A thirty minute "tech only" standup and then another thirty minutes that includes the rest of the stakeholders.
  - balefrost 5y ago
    This is almost certainly due to poor facilitation. That is to say, whoever is facilitating this meeting is either afraid to push back or else thinks that this is how it should be. Convince the 6 developers that they don't need more than 30s each during the "tech only" standup. Get the facilitator to aggressively chop long discussions (clarifying questions can be fine; discussions and debates are not). At least, move long discussions to the end of the standup so that people who aren't relevant and who don't care can leave. Initially, my team's standups (I think 4 devs at the time) would be 15-20 minutes; we're now (6 devs) down to 10-15 minutes, probably 10s more than 15s. I can't imagine there being much value from a daily, 30-minute, whole-team meeting with multiple stakeholders. Developers should perhaps talk to specific stakeholders... but those conversations should be focused on specific stories and probably should be done in much smaller groups. Heck, it would be fine to have 30 minutes of scheduled "office hours" time where specific developers can talk to specific stakeholders about specific stories. Bring this up in retrospective. Point out that (nominally) 12.5% of every day (and likely more than that) is being spent on these meetings. Ask about what value people see in these long meetings and if there's a better way to achieve that value. Brainstorm other approaches and get the team to commit to experimentation. Try, you know, actually standing up. On your feet. That's where the name comes from and it's to encourage people to be brief.
    - ethbr0 5y ago
      The central evil is letting anyone control the standup that isn't directly participating in the work output of the team. Because then it's easy for that person to forget that stand-ups have no independent value -- their only value is in making the other work go faster. And should be calibrated to maximize that. Which is why you get the "We standup because we have to standup" shops.
- jseban 5y ago
  Daily standups, weekly retros and weekly 1-on-1:s. Those are the ones that bother me the most, the micromanagement around planning, I can deal with. But the creepiness of these other vague "Hey, I'm your friend, we can just talk" type of meetings are too much for me. And this trap of "giving feedback" and whenever you do, you get punished and marked for no promotion, immediately, it's just loyalty checks masked as something else "this meeting is for you" uhmm, can I just go back to work please?
  - mLuby 5y ago
    Stand-ups can be a drag. My last stand-ups were literally 3-5 minutes, which I attribute to everyone working on long-running project where we all either knew what "Today I'll be fooing the bar" meant or knew it wasn't important to know. And we were very good about mentioning but not discussing problems during that meeting; they'd be dealt with "off-line" (so to speak). Retrospectives can also be good when they're focused on how to improve processes (including Agile's). If it's just a venting session, that can become demoralizing, even caustic. There's also value in not having certain people in the room, so they can't get defensive or cause people to clam up.
blinkingled 5y ago
Spot on - In my mind I use Agile and Scrum interchangeably because Scrum is what I see being used everywhere and it sure has swallowed Agile up it up like you said! It's too easy to throw scrum in - who doesn't like ready made processes that take minimal effort to overlay instead of integrate? Agile without scrum would require a deeper level of effort as it would first and foremost involve people. Much harder to think from people first standpoint than process first standpoint.
nallerooth 5y ago
> Scrum has outmarketed "Agile", and swallowed it up wholesale. Agile was about putting people before process, Scrum is all process, no-wonder the people feel downtrodden. This. I understand that some managers want graphs, points, velocity, etc. Those things makes it easy to point at something and tell the team to improve. A good (imo) manager on the other hand, would just ask the team how the sprint went and what problems needs solving.
- wayoutthere 5y ago
  I usually come back to my “products vs projects” division. Projects are discrete work efforts with a specific business objective and an end date. They’re effectively waterfall, and managing a whole program with multiple work streams is at least possible via scrum (if you have the right feedback loops into the product team and execs). I suspect this is the kind of work people really hate. This is the kind of work consulting companies generally do. Product development should be much more free form. The product manager should own P&L for the product (or at least some proxy) because it aligns incentives. The dev team need not be 100% utilized all the time as their ability to quickly and effectively develop functionality is valued above cost efficiency (because again, product owns P&L so no business case has to be made). You can then use the “extra” time to deal with tech debt or take on special projects. The companies that really suck to work for are the ones that confuse the two. They are two different mindsets — one requires a developer who thrives on tight deadlines and can turn around functioning code and toss it over the fence, the other requires a more deliberate approach where doing things right preserves the ability to do things quickly. Put a project developer on a product they’ll be lost without the structure; put a product developer on a project team and they’ll quit within 6 months because they hate being micromanaged.
  - bennysomething 5y ago
    Yes I tell everyone who ll listen this distinction too. I've arrived in a project based financial institution. It boggles my mind the software mind set: get project "done" toss / handover to some poor bastard to struggle with. Repeat. I actually think handovers should be banned. They don't work.
danjac 5y ago
Scrum in of itself is not so much a deal, if it just provides a light framework/training wheels for companies transitioning to Agile. Start with 15 minute daily standups and 2 week sprints, for example, but if you work better with a twice-weekly standup and a 6 week sprint, fine. Where it becomes a problem is where it's used to enforce underlying pathologies like micromanagement. But if your shop has a micromanagement problem, you'll be miserable, Scrum or no Scrum.
- mk89 5y ago
  in my team we don't micromanage, however I agree that some scrum events can be adjusted a bit. For example the sprint reviews don't make much sense if you can deliver any time you want, and we do. It's probably just a way to wrap a bunch of work we did and show it to keep everyone on the same page about what's happening. Daily also don't make sense, because the team has several major tracks in parallel and I can't really contribute to what others are doing, unless I decide to put my work aside and/or overwork. Why this? My guess is that it's more convenient for a manager to have a more consistent view of what's happening. On the other hands there are team members that like to hear what's happening besides their own work, and such meetings give them that opportunity. The luck we have are the retrospective meetings: one of the most efficient ways to actually make actionable things. This meetung I would never cancel, because it has nothing to do with the sprint but with the teamwork, workload, etc. The issue with all "things" is the ability of people to be able to adapt it to the own workflow. It takes balls and experience.
- cogman10 5y ago
  The reason people are hating scrum isn't because the simple scrum statement is simple, it's because a whole industry has been formed around advocating "true scrum" with consultants that fly in and give big meetings about how you can turn scrum into a tool for micromanagement. Corporate suits eat that shit up. The value add of scrum, to them, is everything devs hate. They love the burn down charts, the timelines for features, the resource allocation, the ability to fly in and say "You are working on polish? WTH value add does that bring to the company? Dump it and do feature 123 instead!" And, unfortunately, corporate suits tend to pay the bills. I'm sure there are companies out there that don't fall into micromanagement shit, but I'm convinced it's an inevitability that any successful company will eventually turn into a feature factory hell hole.
jes 5y ago
In the late 90’s, one of my clients was an ultrasound company in Seattle. I was on a small software team of five or six competent engineers. We gelled as a team, embraced Kent Beck’s Extreme Programming (XP) philosophy, and really kicked ass. We were also writing code in C++ to run on an ARM 7TDMI core embedded in a custom ASIC. We used the Metaware C++ compiler and JTAG based debug hardware from a German company whose name I’ve forgotten. Good times. The client company was successful and was sold to Fujifilm about 20 years later for $950M. Edit: The JTAG ICE was Trace32 from Lauterbach.
the_other 5y ago
In my team, we have a fairly strict process, it's been refined over time by the team. We change little things every sprint. We have checklists/agendas for what to discuss and we go through them fast. We update the agendas when we need to. We don't tolerate diversions from the meeting topic for more than a couple of exchanges and anyone can ask to move the meeting on/back on-topic at any time with a funny "safe word". Our stand-ups focus on "what needs to be organised, who needs to talk to whom, what work/bugs have come in from other teams?" not "what has everyone done". Our planning is split into two or three (so it's more meetings, but they're shorter - one focuses just on bugs and is only for a subset of the team). Our sprint review is open to the entire product and engineering teams and we go to theirs. They're actual demos; the last one we did was interactive. In my opinion, Scrum can work. It takes time to find the combination of people, agenda items and venues to get the best work done in each "ritual". If you didn't have Scrum, you'd still have to create _some_ proces to follow; you'd do most if not all the meeting functions, but perhaps at a different rhythm. The scrum system is pretty minimal and under-describe exactly because you can mould its it to fit your team. If your Scrum implementation isn't working for your team, make your Scrum master change it or take on that role. Any other mindset will cause the process to fail. It's probably not the right process for systems which include hardware or other long-lifecycle subsystems. It's best when the whole team can focus on specific goals, and a small number of goals. If you have multiple concurrent work streams (e.g. "epics", and you try to give chunks of work from each epic to individual developers, you'll fall into the trap of "feature farming". It's much more effective and interesting when the team is focused on a single feature and works together on it. The backlog needs to be about the _product_ not "work to be done by the team". If you have multiple work streams/epics consider making specific, short-lived, smaller teams and splitting their stand-ups and retros out. Keep changing it to suit your product needs and fit the teams around that.
- bennysomething 5y ago
  Great idea on safe word!

blackp1nk 5y ago

Agree to this. Daily standups are the bane of many people's existence.

vorticalbox 5y ago
wasting time hearing about peoples work yesterday/today that I am not involved with nor has any impact on my work is a waste of every ones time.
- jseban 5y ago
  Yeah, and that feeling of someone oversharing something both irrelevant and boring, while you already have an overfull short term memory from your own work, AND being forced to pretend to pay attention, it's just so painful.
rypskar 5y ago
I'm in a distributed team where the daily standups are optional. Almost everyone join every day and say it is good to see the others at least for a short while every day
- odshoifsdhfs 5y ago
  I'm going to be that guy: They say it is good to see others or they say what is expected of them? Is like the conversation yesterday about leaving interviews. You don't say Person was is shit and an asshole but you say a better opportunity came up. Heck, even during job interviews, you don't answer 'why work here' with 'money' but 'looking for a new challenge, or interesting work or whatnot'
  - diatone 5y ago
    As someone who enjoys sharing a similar sense of humour and outlook as the people I work with, I'm personally more than happy to spend 15 minutes goofing around before a day of knuckling down and getting shit done. YMMV
- SkyPuncher 5y ago
  I despised daily stands in person, but love them on a remote team. We've decide to drop the status updates from standups to focus solely on discussing things of interest to the team - blockers, processes, issues, announcements, icebreakers, etc.
Consultant32452 5y ago
My current employer's standup is now an hour long. There's only 6 developers on the team. Technically we have two standups. A thirty minute "tech only" standup and then another thirty minutes that includes the rest of the stakeholders.
- balefrost 5y ago
  This is almost certainly due to poor facilitation. That is to say, whoever is facilitating this meeting is either afraid to push back or else thinks that this is how it should be. Convince the 6 developers that they don't need more than 30s each during the "tech only" standup. Get the facilitator to aggressively chop long discussions (clarifying questions can be fine; discussions and debates are not). At least, move long discussions to the end of the standup so that people who aren't relevant and who don't care can leave. Initially, my team's standups (I think 4 devs at the time) would be 15-20 minutes; we're now (6 devs) down to 10-15 minutes, probably 10s more than 15s. I can't imagine there being much value from a daily, 30-minute, whole-team meeting with multiple stakeholders. Developers should perhaps talk to specific stakeholders... but those conversations should be focused on specific stories and probably should be done in much smaller groups. Heck, it would be fine to have 30 minutes of scheduled "office hours" time where specific developers can talk to specific stakeholders about specific stories. Bring this up in retrospective. Point out that (nominally) 12.5% of every day (and likely more than that) is being spent on these meetings. Ask about what value people see in these long meetings and if there's a better way to achieve that value. Brainstorm other approaches and get the team to commit to experimentation. Try, you know, actually standing up. On your feet. That's where the name comes from and it's to encourage people to be brief.
  - ethbr0 5y ago
    The central evil is letting anyone control the standup that isn't directly participating in the work output of the team. Because then it's easy for that person to forget that stand-ups have no independent value -- their only value is in making the other work go faster. And should be calibrated to maximize that. Which is why you get the "We standup because we have to standup" shops.
jseban 5y ago
Daily standups, weekly retros and weekly 1-on-1:s. Those are the ones that bother me the most, the micromanagement around planning, I can deal with. But the creepiness of these other vague "Hey, I'm your friend, we can just talk" type of meetings are too much for me. And this trap of "giving feedback" and whenever you do, you get punished and marked for no promotion, immediately, it's just loyalty checks masked as something else "this meeting is for you" uhmm, can I just go back to work please?
- mLuby 5y ago
  Stand-ups can be a drag. My last stand-ups were literally 3-5 minutes, which I attribute to everyone working on long-running project where we all either knew what "Today I'll be fooing the bar" meant or knew it wasn't important to know. And we were very good about mentioning but not discussing problems during that meeting; they'd be dealt with "off-line" (so to speak). Retrospectives can also be good when they're focused on how to improve processes (including Agile's). If it's just a venting session, that can become demoralizing, even caustic. There's also value in not having certain people in the room, so they can't get defensive or cause people to clam up.

blinkingled 5y ago

Spot on - In my mind I use Agile and Scrum interchangeably because Scrum is what I see being used everywhere and it sure has swallowed Agile up it up like you said! It's too easy to throw scrum in - who doesn't like ready made processes that take minimal effort to overlay instead of integrate? Agile without scrum would require a deeper level of effort as it would first and foremost involve people. Much harder to think from people first standpoint than process first standpoint.

nallerooth 5y ago

> Scrum has outmarketed "Agile", and swallowed it up wholesale. Agile was about putting people before process, Scrum is all process, no-wonder the people feel downtrodden. This. I understand that some managers want graphs, points, velocity, etc. Those things makes it easy to point at something and tell the team to improve. A good (imo) manager on the other hand, would just ask the team how the sprint went and what problems needs solving.

wayoutthere 5y ago
I usually come back to my “products vs projects” division. Projects are discrete work efforts with a specific business objective and an end date. They’re effectively waterfall, and managing a whole program with multiple work streams is at least possible via scrum (if you have the right feedback loops into the product team and execs). I suspect this is the kind of work people really hate. This is the kind of work consulting companies generally do. Product development should be much more free form. The product manager should own P&L for the product (or at least some proxy) because it aligns incentives. The dev team need not be 100% utilized all the time as their ability to quickly and effectively develop functionality is valued above cost efficiency (because again, product owns P&L so no business case has to be made). You can then use the “extra” time to deal with tech debt or take on special projects. The companies that really suck to work for are the ones that confuse the two. They are two different mindsets — one requires a developer who thrives on tight deadlines and can turn around functioning code and toss it over the fence, the other requires a more deliberate approach where doing things right preserves the ability to do things quickly. Put a project developer on a product they’ll be lost without the structure; put a product developer on a project team and they’ll quit within 6 months because they hate being micromanaged.
- bennysomething 5y ago
  Yes I tell everyone who ll listen this distinction too. I've arrived in a project based financial institution. It boggles my mind the software mind set: get project "done" toss / handover to some poor bastard to struggle with. Repeat. I actually think handovers should be banned. They don't work.

danjac 5y ago

Scrum in of itself is not so much a deal, if it just provides a light framework/training wheels for companies transitioning to Agile. Start with 15 minute daily standups and 2 week sprints, for example, but if you work better with a twice-weekly standup and a 6 week sprint, fine. Where it becomes a problem is where it's used to enforce underlying pathologies like micromanagement. But if your shop has a micromanagement problem, you'll be miserable, Scrum or no Scrum.

mk89 5y ago
in my team we don't micromanage, however I agree that some scrum events can be adjusted a bit. For example the sprint reviews don't make much sense if you can deliver any time you want, and we do. It's probably just a way to wrap a bunch of work we did and show it to keep everyone on the same page about what's happening. Daily also don't make sense, because the team has several major tracks in parallel and I can't really contribute to what others are doing, unless I decide to put my work aside and/or overwork. Why this? My guess is that it's more convenient for a manager to have a more consistent view of what's happening. On the other hands there are team members that like to hear what's happening besides their own work, and such meetings give them that opportunity. The luck we have are the retrospective meetings: one of the most efficient ways to actually make actionable things. This meetung I would never cancel, because it has nothing to do with the sprint but with the teamwork, workload, etc. The issue with all "things" is the ability of people to be able to adapt it to the own workflow. It takes balls and experience.
cogman10 5y ago
The reason people are hating scrum isn't because the simple scrum statement is simple, it's because a whole industry has been formed around advocating "true scrum" with consultants that fly in and give big meetings about how you can turn scrum into a tool for micromanagement. Corporate suits eat that shit up. The value add of scrum, to them, is everything devs hate. They love the burn down charts, the timelines for features, the resource allocation, the ability to fly in and say "You are working on polish? WTH value add does that bring to the company? Dump it and do feature 123 instead!" And, unfortunately, corporate suits tend to pay the bills. I'm sure there are companies out there that don't fall into micromanagement shit, but I'm convinced it's an inevitability that any successful company will eventually turn into a feature factory hell hole.

jes 5y ago

In the late 90’s, one of my clients was an ultrasound company in Seattle. I was on a small software team of five or six competent engineers. We gelled as a team, embraced Kent Beck’s Extreme Programming (XP) philosophy, and really kicked ass. We were also writing code in C++ to run on an ARM 7TDMI core embedded in a custom ASIC. We used the Metaware C++ compiler and JTAG based debug hardware from a German company whose name I’ve forgotten. Good times. The client company was successful and was sold to Fujifilm about 20 years later for $950M. Edit: The JTAG ICE was Trace32 from Lauterbach.

the_other 5y ago

In my team, we have a fairly strict process, it's been refined over time by the team. We change little things every sprint. We have checklists/agendas for what to discuss and we go through them fast. We update the agendas when we need to. We don't tolerate diversions from the meeting topic for more than a couple of exchanges and anyone can ask to move the meeting on/back on-topic at any time with a funny "safe word". Our stand-ups focus on "what needs to be organised, who needs to talk to whom, what work/bugs have come in from other teams?" not "what has everyone done". Our planning is split into two or three (so it's more meetings, but they're shorter - one focuses just on bugs and is only for a subset of the team). Our sprint review is open to the entire product and engineering teams and we go to theirs. They're actual demos; the last one we did was interactive. In my opinion, Scrum can work. It takes time to find the combination of people, agenda items and venues to get the best work done in each "ritual". If you didn't have Scrum, you'd still have to create _some_ proces to follow; you'd do most if not all the meeting functions, but perhaps at a different rhythm. The scrum system is pretty minimal and under-describe exactly because you can mould its it to fit your team. If your Scrum implementation isn't working for your team, make your Scrum master change it or take on that role. Any other mindset will cause the process to fail. It's probably not the right process for systems which include hardware or other long-lifecycle subsystems. It's best when the whole team can focus on specific goals, and a small number of goals. If you have multiple concurrent work streams (e.g. "epics", and you try to give chunks of work from each epic to individual developers, you'll fall into the trap of "feature farming". It's much more effective and interesting when the team is focused on a single feature and works together on it. The backlog needs to be about the _product_ not "work to be done by the team". If you have multiple work streams/epics consider making specific, short-lived, smaller teams and splitting their stand-ups and retros out. Keep changing it to suit your product needs and fit the teams around that.

bennysomething 5y ago
Great idea on safe word!