7 ms·

"Productivity ground to a halt for six months" My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperience

by throwaway1979 11y ago

"Productivity ground to a halt for six months" My experience feels the same way. I am beginning to think Agile works for UI dev and small teams of inexperienced folks building relatively simple projects. If you have a large team building something complex, the constant meetings and tool updates destroy productivity. What's worse ... they destroy developer morale if you are actually a good dev IMHO.

UK-AL 11y ago
It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?
- jackmaney 11y ago
  Only 2--4 hours? I wish.
- jjoonathan 11y ago
  No, incentivizing small tasks that look good in standups over larger, less-sexy tasks kills productivity.
- zimpenfish 11y ago
  I've been in standups that lasted an hour a day. That'll destroy your morale pretty damned quick.
  - wilsynet 11y ago
    They are doing it wrong. 8 people should not take an hour to say: What did I do yesterday, what am I doing today, is there anything blocking me? There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch". The standup is 10-15 minutes. If it is longer, it needs to be stopped. Period. Non-negotiable.
    - jackmaney 11y ago
      > There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch". Guess what? Those things are still meetings. They still take up actual time that could be spent on getting shit done.
      - lostcolony 11y ago
        They don't, however, involve everyone. The standup does. That's key. If person A needs to talk to person B about an issue, and it's done in standup, it wastes person C, D, etc's, time, even though they don't need to be involved. Doing it with just the required people is, obviously, required anyway, and the problem a lot of people doing agile have is they end up wasting everyone's time by bringing it up during standup.
        jackmaney 11y ago
        A 45 minute meeting that spawns off of a 15 minute meeting is still a total of 60 minutes of meeting time. And yes, while that 45 minutes involved fewer total people, that doesn't mean that others won't have spin-off meetings of their own.
        lostcolony 11y ago
        But that 45 minute meeting had to happen anyway, apparently. It wasn't scheduled or mandated, it was decided by those two people it needed to happen. Meaning regardless of process, it was necessary. The issue is a lot of people seem to see "standup requires everyone", and "communication should happen", and conflate the two to "every meeting requires every person", which just is not the case, and then as they see all their time is taken up by pointless meetings they didn't need to attend, they blame agile. I've seen the same mistake in waterfall development shops, and people blamed the process there too, even though it's really just cultural. Let me give you a specific example. Persons A-H have a standup. It's 15 minutes. Afterwards, A needs to talk to C about something, which will take 45 minutes. B needs to talk to D about something, which will take 45 minutes. F needs to talk to both A and H about something, for 45 minutes. A talks to C, while B talks to D. Then A talks with F and H. Total time taken (excluding the 15 minute standup) - A - 90 minutes B,C,D,F,H - 45 minutes E,G - 0 minutes. This is exactly what should have happened -regardless- of your process; these are meetings where only the required people are involved, no one's time is wasted. What often ends up happening when you hear about day long status meetings and other such terribleness, is after the 15 minute standup, they go straight into discussions, with the entire team. That is - A talks with C, with everyone still present. Then B talks with D, with everyone still present. Then A talks with F and H, with everyone still present. For a total time of 135 minutes (again, excluding the 15 minute standup). Meaning that -everyone lost 135 minutes-. Now, if you're claiming that A never actually needed to talk to C, and B never actually needed to talk to D, and A never actually needed to talk with F and H, then that's an organizational problem that is, again, unrelated to agile (or waterfall, or anything else). You simply have people who insist on wasting others time, and regardless of your methodology you're going to run into that issue.
  - jackmaney 11y ago
    Let's not forget the daily leadership meetings and weekly all-hands standup. Those are a real hoot...
- wilsynet 11y ago
  If you are doing Scrum, the development team should be doing something like over 2 weeks: Daily standup: 15 mins x 10 days = 150 minutes = 2.5 hours Backlog grooming: 0.5 - 1 hour Sprint planning: 0.5 - 1 hour Retrospective: 1 hour Demo: 1 hour So about 5.5 - 6.5 hours of meetings over 2 weeks. If you're really militant, you can probably take it down to 4 hours, but I don't think you can get much lower than that without dispensing with formal Scrum. It doesn't seem unreasonable to me to have 6.5 hours of meetings over 2 weeks.
  - UK-AL 11y ago
    Your backlog grooming is a bit to long. You should only be grooming 10-20 tasks.
kabdib 11y ago
The classic success cases for Scrum were projects that had (a) been done before, and (b) been done by the same team. So they had lots of experience. If you ask an assembly-line worker "How long is it going to take you to install this transmission?" they'll be able to tell you within a few seconds. But that's not engineering. If you ask someone who's written essentially the same app five or six times before "How long will it take you to finish feature X?" they'll be able to tell you with pretty high confidence. If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. Ask them again, when they've re-implemented it a few times, and they'll have an idea then. Until then you can decompose the problem and do analysis on the pieces and make assumptions, but you still won't know how long it'll take until it's done because the industry has been doing this for like 70 years and the one thing we know is that scheduling unknowns and unknown unknowns is still very, very hard. Scrum works if you've done it before. Apply it to green fields or systems with known wicked behavior, and you're likely to fail in quite a few ways, including pissing off your developers and boiling off the good ones for better work environments.
- madcaptenor 11y ago
  An actual example I've seen: you can ask a field technician "how long will it take to install this piece of equipment in the field?" and get a pretty good answer. You can't ask a data scientist "how long will it take to build a statistical model to predict how long jobs out in the field will take?" and get anything at all useful. And you certainly can't ask "how long will it take to build a statistical model to predict how long it'll take a data scientist to build a statistical model?"...
- couchand 11y ago
  If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. That's technically true but not useful. There are much better questions to ask, namely: - Will gozzlewog or foofaraw take longer to implement? - Is the difference minor or is it an order of magnitude? - Will shipping gozzlewog or foofaraw make a bigger impact on the business? - Is that difference small or large? All of theses are easier to estimate and are more useful, too.

UK-AL 11y ago

It's roughly 2-4 hours worth of meetings in 2 weeks. That "destroys" productivity?

jackmaney 11y ago
Only 2--4 hours? I wish.
jjoonathan 11y ago
No, incentivizing small tasks that look good in standups over larger, less-sexy tasks kills productivity.
zimpenfish 11y ago
I've been in standups that lasted an hour a day. That'll destroy your morale pretty damned quick.
- wilsynet 11y ago
  They are doing it wrong. 8 people should not take an hour to say: What did I do yesterday, what am I doing today, is there anything blocking me? There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch". The standup is 10-15 minutes. If it is longer, it needs to be stopped. Period. Non-negotiable.
  - jackmaney 11y ago
    > There should not be a discussion of every point. The only discussion should be "oh let's talk about that impediment after the meeting with a smaller group of people" or "let me follow up with you after lunch". Guess what? Those things are still meetings. They still take up actual time that could be spent on getting shit done.
    - lostcolony 11y ago
      They don't, however, involve everyone. The standup does. That's key. If person A needs to talk to person B about an issue, and it's done in standup, it wastes person C, D, etc's, time, even though they don't need to be involved. Doing it with just the required people is, obviously, required anyway, and the problem a lot of people doing agile have is they end up wasting everyone's time by bringing it up during standup.
      - jackmaney 11y ago
        A 45 minute meeting that spawns off of a 15 minute meeting is still a total of 60 minutes of meeting time. And yes, while that 45 minutes involved fewer total people, that doesn't mean that others won't have spin-off meetings of their own.
        lostcolony 11y ago
        But that 45 minute meeting had to happen anyway, apparently. It wasn't scheduled or mandated, it was decided by those two people it needed to happen. Meaning regardless of process, it was necessary. The issue is a lot of people seem to see "standup requires everyone", and "communication should happen", and conflate the two to "every meeting requires every person", which just is not the case, and then as they see all their time is taken up by pointless meetings they didn't need to attend, they blame agile. I've seen the same mistake in waterfall development shops, and people blamed the process there too, even though it's really just cultural. Let me give you a specific example. Persons A-H have a standup. It's 15 minutes. Afterwards, A needs to talk to C about something, which will take 45 minutes. B needs to talk to D about something, which will take 45 minutes. F needs to talk to both A and H about something, for 45 minutes. A talks to C, while B talks to D. Then A talks with F and H. Total time taken (excluding the 15 minute standup) - A - 90 minutes B,C,D,F,H - 45 minutes E,G - 0 minutes. This is exactly what should have happened -regardless- of your process; these are meetings where only the required people are involved, no one's time is wasted. What often ends up happening when you hear about day long status meetings and other such terribleness, is after the 15 minute standup, they go straight into discussions, with the entire team. That is - A talks with C, with everyone still present. Then B talks with D, with everyone still present. Then A talks with F and H, with everyone still present. For a total time of 135 minutes (again, excluding the 15 minute standup). Meaning that -everyone lost 135 minutes-. Now, if you're claiming that A never actually needed to talk to C, and B never actually needed to talk to D, and A never actually needed to talk with F and H, then that's an organizational problem that is, again, unrelated to agile (or waterfall, or anything else). You simply have people who insist on wasting others time, and regardless of your methodology you're going to run into that issue.
- jackmaney 11y ago
  Let's not forget the daily leadership meetings and weekly all-hands standup. Those are a real hoot...
wilsynet 11y ago
If you are doing Scrum, the development team should be doing something like over 2 weeks: Daily standup: 15 mins x 10 days = 150 minutes = 2.5 hours Backlog grooming: 0.5 - 1 hour Sprint planning: 0.5 - 1 hour Retrospective: 1 hour Demo: 1 hour So about 5.5 - 6.5 hours of meetings over 2 weeks. If you're really militant, you can probably take it down to 4 hours, but I don't think you can get much lower than that without dispensing with formal Scrum. It doesn't seem unreasonable to me to have 6.5 hours of meetings over 2 weeks.
- UK-AL 11y ago
  Your backlog grooming is a bit to long. You should only be grooming 10-20 tasks.

kabdib 11y ago

The classic success cases for Scrum were projects that had (a) been done before, and (b) been done by the same team. So they had lots of experience. If you ask an assembly-line worker "How long is it going to take you to install this transmission?" they'll be able to tell you within a few seconds. But that's not engineering. If you ask someone who's written essentially the same app five or six times before "How long will it take you to finish feature X?" they'll be able to tell you with pretty high confidence. If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. Ask them again, when they've re-implemented it a few times, and they'll have an idea then. Until then you can decompose the problem and do analysis on the pieces and make assumptions, but you still won't know how long it'll take until it's done because the industry has been doing this for like 70 years and the one thing we know is that scheduling unknowns and unknown unknowns is still very, very hard. Scrum works if you've done it before. Apply it to green fields or systems with known wicked behavior, and you're likely to fail in quite a few ways, including pissing off your developers and boiling off the good ones for better work environments.

madcaptenor 11y ago
An actual example I've seen: you can ask a field technician "how long will it take to install this piece of equipment in the field?" and get a pretty good answer. You can't ask a data scientist "how long will it take to build a statistical model to predict how long jobs out in the field will take?" and get anything at all useful. And you certainly can't ask "how long will it take to build a statistical model to predict how long it'll take a data scientist to build a statistical model?"...
couchand 11y ago
If you ask someone, "How long is it going to take you to finish designing and implementing that gozzlewog?" they won't have the foggiest idea. That's technically true but not useful. There are much better questions to ask, namely: - Will gozzlewog or foofaraw take longer to implement? - Is the difference minor or is it an order of magnitude? - Will shipping gozzlewog or foofaraw make a bigger impact on the business? - Is that difference small or large? All of theses are easier to estimate and are more useful, too.