5 ms·

I worked at a company with story point estimations, two (or for some, more) daily standups, twice a week planning and ticket estimation, retros, and who knows w

I worked at a company with story point estimations, two (or for some, more) daily standups, twice a week planning and ticket estimation, retros, and who knows what else (e.g occasional scrum of scrums for a feature nobody understands, across teams and domains, with around a 100 people, with breakout rooms and presentations of all the teams' "commitments"). Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed. Once I wrote a script to fetch all the relevant data from Jira to figure out whether or story points give better estimates than simply counting up the stories (because of course Jira makes this as hard as possible for you to find out). I went through the channels, discussed it with different people, at every turn I added more info to the report demonstrating the pointlessness of story points, at each turn the data supported my argument stronger and stronger, across all our teams, for sprints going back years. After weeks of discussing it, we kept the story points, because "upper management wants numbers". Now, I work at a company where we keep things close to the agile manifesto, we adapt as we go, and we aren't forced to play stupid planning poker, and we have twice a week a short sync call (15 minutes). For as long as I have the choice, I'll not work for a company with Scrum and story point estimations.

danwee 3y ago
> Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed. That's because indirectly you're suggesting to get rid of people as well. You see, for any pointless ceremony, there's someone (or more) behind it who get paid for that. If you suddendly suggest that perhaps ceremony A and ceremony B don't actually add value (which is probably true), then what you're suggesting is that the people who brought and who offer those ceremonies (typically scrum masters, sometimes PMs) are doing something pointless. You may expect that they won't hear you at all because who likes to hold the "I'm doing pointless stuff and get paid for it" label? Upper management may know about this, but upper management is too concerned with other topics that they barely listen to the people at the bottom of the ladder.
- serial_dev 3y ago
  > That's because indirectly you're suggesting to get rid of people as well. That could have certainly been the case in some cases (the overpaid British corporate Scrum master consultant). For the product owners, it could have been the "nobody gets fired for buying IBM": nobody gets reprimanded in a traditional, slow moving, German company for sticking to the same ol Scrum ceremonies. For some developers, they might have valued the meetings for the pointlessness of it: just say your internet is poor, turn off the camera, then do the dishes, take out the trash, jump in with a hot take to start another 20 discussion in the call, go on to working out, and preparing dinner. After I failed to make any change in the organization after a year of trying, I switched my modus operandi to the above described developer, and started looking for another job.
- icedchai 3y ago
  This stuff is to keep people employed, 100%. 10+ years ago, engineering teams didn't have as much overhead.
scotty79 3y ago
I worked in (too) large scrum team and frustrated, at some point, I also pulled data from Jira. It turned out that our actual pace of work was a fraction of the velocity we used to determine which task to take up into sprint. There can be a lot of scrum theatre played entirely for the management and divorced from reality. Influence on the work done is completely secondary. But I find it completely natural that in corporations most important function of a lot of things is providing everyone sufficient excuse to get paid.
smcleod 3y ago
Exactly the same reasons - “management wants numbers” with most of the clients I’ve worked with over the past 3 years. It’s such an incredible was of time that most of us have given up and pick a random number between 2 and 5.
JohnFen 3y ago
> I'll not work for a company with Scrum and story point estimations. I take it even further. After years of putting up with various agile things, I made the career decision of no longer accepting positions at agile shops at all, much like I will no longer accept positions at companies that use an open office layout.
- feoren 3y ago
  > I made the career decision of no longer accepting positions at agile shops at all I'm legitimately curious what the alternative is. You refuse to work anywhere that starts programming before they have a complete specification of what they're building? You only work at places where you have a fixed spot in the waterfall model? Where your job is to take high-level specifications, turn them into UML diagrams, and hand those diagrams off to the next person in the chain?
  - JohnFen 3y ago
    In my decades of being in the industry, I've never actually seen anyone use the "waterfall" method as described by the agile crowd anyway. If I did, I'd avoid working there as well. > You only work at places where you have a fixed spot in the waterfall model? Nope. I've never worked at a place that used the "waterfall" model in my entire career. I'm not saying they don't exist, just that I've never seen one. > Where your job is to take high-level specifications, turn them into UML diagrams, and hand those diagrams off to the next person in the chain? What? That sounds like a nightmare. Your impression of what non-agile development looks like bears no resemblance to what I've seen and experienced. The non-agile shops I've worked at operated with project management methodologies that resemble kanban more than waterfall.
    - nucleardog 3y ago
      > The non-agile shops I've worked at operated with project management methodologies that resemble kanban more than waterfall. Maybe I've just got the entirely wrong conceptualization in my head here, but to me you're comparing apples and oranges. Agile is the idea that "we should be doing small pieces of work, collecting new information, communicating with business and customer stakeholders and integrating it, then tackling our next piece of work". Waterfall is the idea that "we should know everything we're doing up front before we start". These are the two extremes of the same spectrum. Scrum, kanban, reams of paper, and everything else are implementations to turn these philosophies (or places in between them on the spectrum) into actionable processes. To my understanding (and from some brief sanity checks around the internet), kanban _is_ "Agile". If it isn't to you, then what is your understanding of "Agile"? Editing to add: Most of this understanding comes from having worked a lot of places that did waterfall-scrum or waterfall-kanban. You can have as many sprint rituals as you want, but if nobody is assigned any tickets or starts working on projects until you've documented every minute detail from beginning through to release of a full product... you're doing waterfall, not agile.
SkyPuncher 3y ago
I'm undecided on scrum and story points. The most productive team I was ever on used them, but they primarily served two purposes: * Are we breaking our work down small enough? Big stories often had too much ambiguity and increased delivery risk. * Are we over extending ourselves? Committing to deliver too much leads to so many problems. All estimation was done entirely async. We only debated/discussed if people had radically different views on size. We did run daily standups, but they served as part social function (a necessary forcing function on a remote team). We did not force updates or discussion. People brought what they thought was necessary to the group and left it out otherwise.
- nucleardog 3y ago
  You've pretty much describe where our process has been iterated to. The story points are less about "how many hours will this take" and more "is this broken down to a manageable level". Our team is small and we're largely working on legacy systems that nobody at the company has any clear picture on so we do still do things collaboratively in a meeting in order to quickly get to the best information we can and iterate on bits and pieces of the puzzle that may not be common knowledge. But from there the points are mainly "Small, Medium, Big" (1-2, 3, 5). If anyone throws something out at 8 points the question is immediately whether or not we have sufficient clarity on the work. Why is this 8 points? Is it because we need to rotely reimplement the same functionality across two dozen nearly identical form fields, or is it because we've glossed over some major area of the scope and are hedging based on our _assumptions_ about how it works? In the latter case, we'll instead see about adjusting the work breakdown and/or throwing in a ticket to actually investigate and document things better before we circle back to the original task. If we see 13 points we know from experience to run for the hills. That's almost always someone saying "we don't have enough information, but it's going to be big". Those points feed into two things: 1. A rough estimation of long term timelines. We know average velocity, and we can look big picture at the number of points involved in some sort of higher level initiative and get a feel for "is this a 3 month project or 12 month project?". 2. Trying not to overcommit on each sprint. We know the average we can deliver, and can use them to raise a flag when someone seems to be getting overly optimistic about their output. Similarly, our daily standup is not focused on being a status meeting. It's to encourage communication. To help kick things off and jog people's memory, we take about 60 seconds to quickly list out tickets that are sitting in a "review" or "deploy" status (if it's nearly done let's get it over the line), "blocked" status (if you're waiting on someone, have you communicated it to them?) as well as any that, based on the points, seem to be taking longer than expected (do you need to ask someone for help or communicate changes in scope?). Then it's just hands up for anyone that needs to say anything, call for any input from the business side, some chat and banter, etc, and we're out. Usually takes about 5 minutes.
Falkon1313 3y ago
Oof. I had to do the double daily standup thing once. In addition to the retros, calls with subject matter experts, company meetings, etc. By the time we could actually get started on sprint work, and do a couple hours work here and there between meetings, it was almost sprint deadline already. I didn't even bother with pulling data from Jira and trying to make a point that way. It wasn't necessary. I just quite honestly gave my update in my second standup "No progress since the last meeting because I've been in meetings since then." Some people were a little rankled by that honesty. But eventually they got the point and scrapped that second hour of standup and some of the other meetings. That helped significantly.

danwee 3y ago

> Every time I fought the double daily standups, the pointless plannings (where we plan when we know nothing, and by the time we get to work on the tasks, everybody forgets what they agreed on), I failed. That's because indirectly you're suggesting to get rid of people as well. You see, for any pointless ceremony, there's someone (or more) behind it who get paid for that. If you suddendly suggest that perhaps ceremony A and ceremony B don't actually add value (which is probably true), then what you're suggesting is that the people who brought and who offer those ceremonies (typically scrum masters, sometimes PMs) are doing something pointless. You may expect that they won't hear you at all because who likes to hold the "I'm doing pointless stuff and get paid for it" label? Upper management may know about this, but upper management is too concerned with other topics that they barely listen to the people at the bottom of the ladder.

serial_dev 3y ago
> That's because indirectly you're suggesting to get rid of people as well. That could have certainly been the case in some cases (the overpaid British corporate Scrum master consultant). For the product owners, it could have been the "nobody gets fired for buying IBM": nobody gets reprimanded in a traditional, slow moving, German company for sticking to the same ol Scrum ceremonies. For some developers, they might have valued the meetings for the pointlessness of it: just say your internet is poor, turn off the camera, then do the dishes, take out the trash, jump in with a hot take to start another 20 discussion in the call, go on to working out, and preparing dinner. After I failed to make any change in the organization after a year of trying, I switched my modus operandi to the above described developer, and started looking for another job.
icedchai 3y ago
This stuff is to keep people employed, 100%. 10+ years ago, engineering teams didn't have as much overhead.

scotty79 3y ago

I worked in (too) large scrum team and frustrated, at some point, I also pulled data from Jira. It turned out that our actual pace of work was a fraction of the velocity we used to determine which task to take up into sprint. There can be a lot of scrum theatre played entirely for the management and divorced from reality. Influence on the work done is completely secondary. But I find it completely natural that in corporations most important function of a lot of things is providing everyone sufficient excuse to get paid.

smcleod 3y ago

Exactly the same reasons - “management wants numbers” with most of the clients I’ve worked with over the past 3 years. It’s such an incredible was of time that most of us have given up and pick a random number between 2 and 5.

JohnFen 3y ago

> I'll not work for a company with Scrum and story point estimations. I take it even further. After years of putting up with various agile things, I made the career decision of no longer accepting positions at agile shops at all, much like I will no longer accept positions at companies that use an open office layout.

feoren 3y ago
> I made the career decision of no longer accepting positions at agile shops at all I'm legitimately curious what the alternative is. You refuse to work anywhere that starts programming before they have a complete specification of what they're building? You only work at places where you have a fixed spot in the waterfall model? Where your job is to take high-level specifications, turn them into UML diagrams, and hand those diagrams off to the next person in the chain?
- JohnFen 3y ago
  In my decades of being in the industry, I've never actually seen anyone use the "waterfall" method as described by the agile crowd anyway. If I did, I'd avoid working there as well. > You only work at places where you have a fixed spot in the waterfall model? Nope. I've never worked at a place that used the "waterfall" model in my entire career. I'm not saying they don't exist, just that I've never seen one. > Where your job is to take high-level specifications, turn them into UML diagrams, and hand those diagrams off to the next person in the chain? What? That sounds like a nightmare. Your impression of what non-agile development looks like bears no resemblance to what I've seen and experienced. The non-agile shops I've worked at operated with project management methodologies that resemble kanban more than waterfall.
  - nucleardog 3y ago
    > The non-agile shops I've worked at operated with project management methodologies that resemble kanban more than waterfall. Maybe I've just got the entirely wrong conceptualization in my head here, but to me you're comparing apples and oranges. Agile is the idea that "we should be doing small pieces of work, collecting new information, communicating with business and customer stakeholders and integrating it, then tackling our next piece of work". Waterfall is the idea that "we should know everything we're doing up front before we start". These are the two extremes of the same spectrum. Scrum, kanban, reams of paper, and everything else are implementations to turn these philosophies (or places in between them on the spectrum) into actionable processes. To my understanding (and from some brief sanity checks around the internet), kanban _is_ "Agile". If it isn't to you, then what is your understanding of "Agile"? Editing to add: Most of this understanding comes from having worked a lot of places that did waterfall-scrum or waterfall-kanban. You can have as many sprint rituals as you want, but if nobody is assigned any tickets or starts working on projects until you've documented every minute detail from beginning through to release of a full product... you're doing waterfall, not agile.

SkyPuncher 3y ago

I'm undecided on scrum and story points. The most productive team I was ever on used them, but they primarily served two purposes: * Are we breaking our work down small enough? Big stories often had too much ambiguity and increased delivery risk. * Are we over extending ourselves? Committing to deliver too much leads to so many problems. All estimation was done entirely async. We only debated/discussed if people had radically different views on size. We did run daily standups, but they served as part social function (a necessary forcing function on a remote team). We did not force updates or discussion. People brought what they thought was necessary to the group and left it out otherwise.

nucleardog 3y ago
You've pretty much describe where our process has been iterated to. The story points are less about "how many hours will this take" and more "is this broken down to a manageable level". Our team is small and we're largely working on legacy systems that nobody at the company has any clear picture on so we do still do things collaboratively in a meeting in order to quickly get to the best information we can and iterate on bits and pieces of the puzzle that may not be common knowledge. But from there the points are mainly "Small, Medium, Big" (1-2, 3, 5). If anyone throws something out at 8 points the question is immediately whether or not we have sufficient clarity on the work. Why is this 8 points? Is it because we need to rotely reimplement the same functionality across two dozen nearly identical form fields, or is it because we've glossed over some major area of the scope and are hedging based on our _assumptions_ about how it works? In the latter case, we'll instead see about adjusting the work breakdown and/or throwing in a ticket to actually investigate and document things better before we circle back to the original task. If we see 13 points we know from experience to run for the hills. That's almost always someone saying "we don't have enough information, but it's going to be big". Those points feed into two things: 1. A rough estimation of long term timelines. We know average velocity, and we can look big picture at the number of points involved in some sort of higher level initiative and get a feel for "is this a 3 month project or 12 month project?". 2. Trying not to overcommit on each sprint. We know the average we can deliver, and can use them to raise a flag when someone seems to be getting overly optimistic about their output. Similarly, our daily standup is not focused on being a status meeting. It's to encourage communication. To help kick things off and jog people's memory, we take about 60 seconds to quickly list out tickets that are sitting in a "review" or "deploy" status (if it's nearly done let's get it over the line), "blocked" status (if you're waiting on someone, have you communicated it to them?) as well as any that, based on the points, seem to be taking longer than expected (do you need to ask someone for help or communicate changes in scope?). Then it's just hands up for anyone that needs to say anything, call for any input from the business side, some chat and banter, etc, and we're out. Usually takes about 5 minutes.

Falkon1313 3y ago

Oof. I had to do the double daily standup thing once. In addition to the retros, calls with subject matter experts, company meetings, etc. By the time we could actually get started on sprint work, and do a couple hours work here and there between meetings, it was almost sprint deadline already. I didn't even bother with pulling data from Jira and trying to make a point that way. It wasn't necessary. I just quite honestly gave my update in my second standup "No progress since the last meeting because I've been in meetings since then." Some people were a little rankled by that honesty. But eventually they got the point and scrapped that second hour of standup and some of the other meetings. That helped significantly.