11 ms·

This how I feel about most "Agile methods" going around like SCRUM.

sli 9y ago
I often see complaints about Agile and SCRUM met with, "You're just not using it correctly." In some circles, it's almost like a religion that you're not allowed to criticize. After all, it's The Process(TM), I guess. But from where I'm sitting, "correct" SCRUM looks like a whole lot of weird not-overhead-but-totally-overhead that seems difficult to manage across multiple projects. For example, what a "point" represents is constantly in flux. Instead, I actually prefer subsets of the methodology. When the company I work for was young, we all worked from home, and so daily standups were extremely effective at keeping us on task and productive while maintaining good balance (once you're done, you're done -- no creep). The board has been effective as organizing tasks and their progress. What would not have helped, or been in any way productive, would have been spending time trying to figure out how many "points" my tasks for the day are worth. I still don't see how that system is actually different from just using hours beyond philosophical arguments. Basically, I prefer a more focused and leaner version of the approaches.
- virgilp 9y ago
  The basic idea behind points is not bad, the problem with it is humans and the fact that they are numeric/ called "points". Might as well call them "gold coins", since soon enough people all around will start to believe there's genuine value in having/collecting many "points". I like to believe that it'd be much more productive if the tasks were T-shirt size. Since that would prevent people from computing "productivity" or "velocity" or whatever - while still allowing you to do rough estimates, if you recorded this for long-enough. (actually, I think you need some sort of tshirt size for several dimensions - like, "dependencies/ how many people you need to communicate with for this feature"; or "uncertainty - how much is this 'just work'(implementing a known solution) versus 'exploration'/ trying to identify the solution first ")
- User23 9y ago
  "You're just not using it correctly" is absolutely correct, by definition, in all cases where "Agile" is imposed as some kind of top-down corporate policy.
  - amorphid 9y ago
    A mentor once taught me that all actions taken by a company's people should be focused on making money, saving money, and saving time. This is mostly a sniff test for "does this thing we're doing make sense in some obvious way." When sniffing the value of any given team's Agile process, I usually find a notable lack of attempting to make money, save money, or save time. Often I found people are very good at spending money, wasting time, and being completely detached from how they actions contribute to making money in a meaningful way.
    - TheOtherHobbes 9y ago
      This sounds common-sensical, but of course in practice it's almost impossibly hard to tell if any reasonable course of action really will make money, save money, or save time. Will refactoring help? How about a continuous integration system? A better bug tracker? In fact will fixing bugs make/save money/time at all? Customers seem to put up with them, and it's always easier/cheaper not to bother. Will customers leave if our product is shit? Often they won't. Sometimes they will, because a competitor's product eats our lunch. So what's the best course of action? One problem with Agile - and all management fads - is exactly this lack of prescience. Future outcomes are unknowable. They can sometimes be estimated, but given a huge field of possible actions, making optimal choices is incredibly hard, and there's always a trade-off between long-term and short-term rewards. The bigger problem is that corporations and businesses are very rarely primarily dedicated to making money. Internally, the true function of business processes is to highlight and maintain a political hierarchy which supports resource concentration for senior management and shareholders. Senior management and shareholders may know what's best for themselves, and that may well not be what's best for the long-term survival of the company - not even in terms of an apparently simple metric like "Does this make money?" Because you can't answer that question without also asking "For whom?" And it's not that unusual for senior management to choose actions that protect their status over actions that increase income.
- tytytytytytytyt 9y ago
  A lot of people don't do it correctly. They identify 2 things that the company already does and then declare they are completely agile, having changed nothing about the way they do anything.
- IronKettle 9y ago
  > I often see complaints about Agile and SCRUM met with, "You're just not using it correctly." To be fair, this is true a lot. Agile has quickly become "whatever you were doing before Agile but now with stand-ups and kanban boards." The real problem with Agile is that it's kinda stupid to assume that companies will radically change their development process and that they won't just do "whatever we were doing before but with a couple bits and pieces from this other thing." It's way easier to keep doing whatever you were doing before and just say that it's "Agile." See, for example, the number of teams that have long-winded standups even though that's pretty explicitly discouraged. > What would not have helped, or been in any way productive, would have been spending time trying to figure out how many "points" my tasks for the day are worth. I still don't see how that system is actually different from just using hours beyond philosophical arguments. Totally my take on the whole point system, but: They're definitely related (hours and points), but basically the whole idea is vagueness. Figuring out if something will take 3 hours or 5 hours is kinda meaningless, because you really have no idea until you get into it. Saying it's worth "5 story points" might suffice as a rough representation of that 3-7 hour chunk. If it ends up taking 20 hours, oh well - good to know for next time! The idea is not to bicker over whether something will take 3 hours or 5 hours or 7 hours, but to just slap a vague label on it as "low-to-moderate difficulty." It's supposed to save time in that regard. > Basically, I prefer a more focused and leaner version of the approaches. I think any reasonable Agile advocate would tell you to discover what's working for your team and what isn't, and to adjust accordingly. The point is mostly to move away from that extremely long-winded waterfall process and move towards rapid iteration. Story points and stand-ups are just tools for accomplishing that (by estimating velocity and having regular check-ins).
  - LoSboccacc 9y ago
    Agile requires flexible features since the deadlines are fixed. The point system is there to give an idea of how much you can cram before the deadline and negotiate with the client about what to axe from the release Easy bullshit scrum test: go to a manager and ask what feature will be in the release and what will be axed. If nothing is going to be cut from the requirement docs, all the castle about poibts priority and speed just falls down (or you have a ridicolously lax deadline, of the likes I’ve never seen in practice)
- jayd16 9y ago
  Everyone has a different definition of "agile." Its always going to be different and one of the key points of _agile_ is that you bend it to fit your own needs. That said, there are certainly pitfalls to taking some aspects of one methodology without understanding why those methods are the way they are and perhaps whether they rely on some other aspect of the methodology that is skimmed over. For example, story points. The reason they're made up is because people fixate on man-hours being a literal hour worth of work no matter the man. Instead you use a fuzzy point system that at first is impossible to use as a prediction but is supposed to become more accurate over time. Everyone estimates points differently? Fine. that's why its points and not hours. You make burn down charts and measure your velocity in points as well so as long as the point estimation doesn't fluctuate wildly you can start to get something. Plus, it doesn't even matter if you can predict things. Points are are also just an abstract concept to get people talking about task difficulty in general. "300 points?! Why do you say that? What don't I understand about this task." The main goal is to get relative values, not absolute hours. That said, a lot of these methods are taken as religion and used as a cudgel every two weeks.
- ebiester 9y ago
  10 minutes a day, an hour every other week for retro, a half hour every other week for showing the work to the stakeholders and whatever time it takes for the team to understand and clarify the work? (Grooming) I mean, I don't love SCRUM, but I don't understand everyone talking about how much overhead it is. That said, learning the process can take time - early grooming sessions can be terrible. However, on an experienced (in SCRUM) team in a functional organization, it doesn't take much time at all.
  - jtolmar 9y ago
    An hour a day for standup, five hours a week for retro. Grooming sessions never made a dent in the backlog. 30 person team, VP in the room during some standups. Obviously that monster was not what anyone intended by agile, yet the trappings of scrum slot neatly into what the organization actually wanted. Interchangeable workers, a progress chart to show the SVP, enough hipness to sound like the management isn't to blame.
    - XorNot 9y ago
      There's a reason Atlassian products have the graphs front and center, and the actual data entry you have to drill down a lot to find.
    - TheCoelacanth 9y ago
      An hour long meeting is not a standup. The whole reason it is called a standup is that it is short enough that no one gets uncomfortable standing through the whole meeting.
    - ebiester 9y ago
      Unicorn help you...
  - ntuocntr054 9y ago
    > 10 minutes a day Except it's not 10 minutes a day. It's like a half-hour a day because, "Oh, it's 10 minutes to scrum. I can't finish this task in 10 minutes. I'm going to go get a drink of water and talk to John by the water cooler until scrum." + the one person at scrum who explains everything they're doing in detail because they never learned to summarize so it takes longer than 10 minutes + 10 minutes afterwards because, oh look, it's almost lunch time and I can't finish anything up in 10 minutes. > an hour every other week for retro Plus the after-talk that people do with each other about things like, "I don't think they really understood my point about our dev tools being a problem," or whatever things didn't or couldn't be said in the actual retro. > a half hour every other week for showing the work to the stakeholders Except that the stakeholders never show up on time so you end up waiting around for them, and they want to ask inane questions for the next few hours... it never ends.
empath75 9y ago
Try doing it in government.
- logfromblammo 9y ago
  Which is to say iterated waterfall with stand-up meetings tacked on.
- sailfast 9y ago
  You're not doing it right :) I kid because I love, but I will say it depends on where you're attempting to do it, how much control you have over the process, whether you are a contractor or government employee, and how much your can convince your leadership of the good parts (these typically require actual risk-taking / change)
- jacques_chester 9y ago
  It can be done. Not for everything. But for a lot of things. Disclosure: I work for Pivotal. Through Pivotal Labs we have various consulting engagements with the US government, including the DoD.
dandersh 9y ago
While this is a valid point, I've found the biggest issue with "Agile" to be that business thinks that this is the primary (or only) input that needs to be heard from the tech side. They think that because they're tossing us the "Agile" carrot they have carte blanche elsewhere and it is a "get out of jail free" card for their absolutely terrible decisions...like demanding the use of a CMS like AEM when building a dynamic RIA because they may feel the need to change the text of a button down the road. By being "Agile" the team can make up for the ignorant and time wasting technical decisions foisted upon by business.
ozmbie 9y ago
Read up on “cargo cults” and “cargo cult agile” and it makes a lot more sense. There are some genuinely good ideas in SCRUM and other development methodologies. But trying to codify those ideas into a set of rules for newcomers always leads to some degree of misinterpretation. I don’t know what the solution is, other than to ensure each team has constant input and support from somebody with authority and deep understanding of software development practices...and how often do you find people like that!
- arwhatever 9y ago
  Keep the code in a buildable state. Demo early and frequently to get feedback. Skip the rest.
clairity 9y ago
it's not the terms "agile" and "SCRUM" that are bs, it's the application of them. agile just doesn't work in most top-down organizations, where bs tends to be highest, because at it's core, agile is about providing a thin layer of self-accountability to self-organizing teams that are fairly autonomous. most (bad) managers want to believe they know better than the underlings and won't give up that much control.
lowbloodsugar 9y ago
I feel the same way about "Representative Democracy". Sounds like a great idea, and if it worked as advertised, it'd be great way to run a country. Unfortunately, its far easier to say "We have a representative democracy" than to actually implement one, and its in the interest of everybody "in the system" to just take bribes and do whatever the fuck they like. Scrum (its not an acronym) is the same. If you can get a bunch of people together who know what the fuck they are doing and want to write software that works for the customer, then its a great process. But 90% of "Scrum" I've seen is wankword bingo.

sli 9y ago

I often see complaints about Agile and SCRUM met with, "You're just not using it correctly." In some circles, it's almost like a religion that you're not allowed to criticize. After all, it's The Process(TM), I guess. But from where I'm sitting, "correct" SCRUM looks like a whole lot of weird not-overhead-but-totally-overhead that seems difficult to manage across multiple projects. For example, what a "point" represents is constantly in flux. Instead, I actually prefer subsets of the methodology. When the company I work for was young, we all worked from home, and so daily standups were extremely effective at keeping us on task and productive while maintaining good balance (once you're done, you're done -- no creep). The board has been effective as organizing tasks and their progress. What would not have helped, or been in any way productive, would have been spending time trying to figure out how many "points" my tasks for the day are worth. I still don't see how that system is actually different from just using hours beyond philosophical arguments. Basically, I prefer a more focused and leaner version of the approaches.

virgilp 9y ago
The basic idea behind points is not bad, the problem with it is humans and the fact that they are numeric/ called "points". Might as well call them "gold coins", since soon enough people all around will start to believe there's genuine value in having/collecting many "points". I like to believe that it'd be much more productive if the tasks were T-shirt size. Since that would prevent people from computing "productivity" or "velocity" or whatever - while still allowing you to do rough estimates, if you recorded this for long-enough. (actually, I think you need some sort of tshirt size for several dimensions - like, "dependencies/ how many people you need to communicate with for this feature"; or "uncertainty - how much is this 'just work'(implementing a known solution) versus 'exploration'/ trying to identify the solution first ")
User23 9y ago
"You're just not using it correctly" is absolutely correct, by definition, in all cases where "Agile" is imposed as some kind of top-down corporate policy.
- amorphid 9y ago
  A mentor once taught me that all actions taken by a company's people should be focused on making money, saving money, and saving time. This is mostly a sniff test for "does this thing we're doing make sense in some obvious way." When sniffing the value of any given team's Agile process, I usually find a notable lack of attempting to make money, save money, or save time. Often I found people are very good at spending money, wasting time, and being completely detached from how they actions contribute to making money in a meaningful way.
  - TheOtherHobbes 9y ago
    This sounds common-sensical, but of course in practice it's almost impossibly hard to tell if any reasonable course of action really will make money, save money, or save time. Will refactoring help? How about a continuous integration system? A better bug tracker? In fact will fixing bugs make/save money/time at all? Customers seem to put up with them, and it's always easier/cheaper not to bother. Will customers leave if our product is shit? Often they won't. Sometimes they will, because a competitor's product eats our lunch. So what's the best course of action? One problem with Agile - and all management fads - is exactly this lack of prescience. Future outcomes are unknowable. They can sometimes be estimated, but given a huge field of possible actions, making optimal choices is incredibly hard, and there's always a trade-off between long-term and short-term rewards. The bigger problem is that corporations and businesses are very rarely primarily dedicated to making money. Internally, the true function of business processes is to highlight and maintain a political hierarchy which supports resource concentration for senior management and shareholders. Senior management and shareholders may know what's best for themselves, and that may well not be what's best for the long-term survival of the company - not even in terms of an apparently simple metric like "Does this make money?" Because you can't answer that question without also asking "For whom?" And it's not that unusual for senior management to choose actions that protect their status over actions that increase income.
tytytytytytytyt 9y ago
A lot of people don't do it correctly. They identify 2 things that the company already does and then declare they are completely agile, having changed nothing about the way they do anything.
IronKettle 9y ago
> I often see complaints about Agile and SCRUM met with, "You're just not using it correctly." To be fair, this is true a lot. Agile has quickly become "whatever you were doing before Agile but now with stand-ups and kanban boards." The real problem with Agile is that it's kinda stupid to assume that companies will radically change their development process and that they won't just do "whatever we were doing before but with a couple bits and pieces from this other thing." It's way easier to keep doing whatever you were doing before and just say that it's "Agile." See, for example, the number of teams that have long-winded standups even though that's pretty explicitly discouraged. > What would not have helped, or been in any way productive, would have been spending time trying to figure out how many "points" my tasks for the day are worth. I still don't see how that system is actually different from just using hours beyond philosophical arguments. Totally my take on the whole point system, but: They're definitely related (hours and points), but basically the whole idea is vagueness. Figuring out if something will take 3 hours or 5 hours is kinda meaningless, because you really have no idea until you get into it. Saying it's worth "5 story points" might suffice as a rough representation of that 3-7 hour chunk. If it ends up taking 20 hours, oh well - good to know for next time! The idea is not to bicker over whether something will take 3 hours or 5 hours or 7 hours, but to just slap a vague label on it as "low-to-moderate difficulty." It's supposed to save time in that regard. > Basically, I prefer a more focused and leaner version of the approaches. I think any reasonable Agile advocate would tell you to discover what's working for your team and what isn't, and to adjust accordingly. The point is mostly to move away from that extremely long-winded waterfall process and move towards rapid iteration. Story points and stand-ups are just tools for accomplishing that (by estimating velocity and having regular check-ins).
- LoSboccacc 9y ago
  Agile requires flexible features since the deadlines are fixed. The point system is there to give an idea of how much you can cram before the deadline and negotiate with the client about what to axe from the release Easy bullshit scrum test: go to a manager and ask what feature will be in the release and what will be axed. If nothing is going to be cut from the requirement docs, all the castle about poibts priority and speed just falls down (or you have a ridicolously lax deadline, of the likes I’ve never seen in practice)
jayd16 9y ago
Everyone has a different definition of "agile." Its always going to be different and one of the key points of _agile_ is that you bend it to fit your own needs. That said, there are certainly pitfalls to taking some aspects of one methodology without understanding why those methods are the way they are and perhaps whether they rely on some other aspect of the methodology that is skimmed over. For example, story points. The reason they're made up is because people fixate on man-hours being a literal hour worth of work no matter the man. Instead you use a fuzzy point system that at first is impossible to use as a prediction but is supposed to become more accurate over time. Everyone estimates points differently? Fine. that's why its points and not hours. You make burn down charts and measure your velocity in points as well so as long as the point estimation doesn't fluctuate wildly you can start to get something. Plus, it doesn't even matter if you can predict things. Points are are also just an abstract concept to get people talking about task difficulty in general. "300 points?! Why do you say that? What don't I understand about this task." The main goal is to get relative values, not absolute hours. That said, a lot of these methods are taken as religion and used as a cudgel every two weeks.
ebiester 9y ago
10 minutes a day, an hour every other week for retro, a half hour every other week for showing the work to the stakeholders and whatever time it takes for the team to understand and clarify the work? (Grooming) I mean, I don't love SCRUM, but I don't understand everyone talking about how much overhead it is. That said, learning the process can take time - early grooming sessions can be terrible. However, on an experienced (in SCRUM) team in a functional organization, it doesn't take much time at all.
- jtolmar 9y ago
  An hour a day for standup, five hours a week for retro. Grooming sessions never made a dent in the backlog. 30 person team, VP in the room during some standups. Obviously that monster was not what anyone intended by agile, yet the trappings of scrum slot neatly into what the organization actually wanted. Interchangeable workers, a progress chart to show the SVP, enough hipness to sound like the management isn't to blame.
  - XorNot 9y ago
    There's a reason Atlassian products have the graphs front and center, and the actual data entry you have to drill down a lot to find.
  - TheCoelacanth 9y ago
    An hour long meeting is not a standup. The whole reason it is called a standup is that it is short enough that no one gets uncomfortable standing through the whole meeting.
  - ebiester 9y ago
    Unicorn help you...
- ntuocntr054 9y ago
  > 10 minutes a day Except it's not 10 minutes a day. It's like a half-hour a day because, "Oh, it's 10 minutes to scrum. I can't finish this task in 10 minutes. I'm going to go get a drink of water and talk to John by the water cooler until scrum." + the one person at scrum who explains everything they're doing in detail because they never learned to summarize so it takes longer than 10 minutes + 10 minutes afterwards because, oh look, it's almost lunch time and I can't finish anything up in 10 minutes. > an hour every other week for retro Plus the after-talk that people do with each other about things like, "I don't think they really understood my point about our dev tools being a problem," or whatever things didn't or couldn't be said in the actual retro. > a half hour every other week for showing the work to the stakeholders Except that the stakeholders never show up on time so you end up waiting around for them, and they want to ask inane questions for the next few hours... it never ends.

empath75 9y ago

Try doing it in government.

logfromblammo 9y ago
Which is to say iterated waterfall with stand-up meetings tacked on.
sailfast 9y ago
You're not doing it right :) I kid because I love, but I will say it depends on where you're attempting to do it, how much control you have over the process, whether you are a contractor or government employee, and how much your can convince your leadership of the good parts (these typically require actual risk-taking / change)
jacques_chester 9y ago
It can be done. Not for everything. But for a lot of things. Disclosure: I work for Pivotal. Through Pivotal Labs we have various consulting engagements with the US government, including the DoD.

dandersh 9y ago

While this is a valid point, I've found the biggest issue with "Agile" to be that business thinks that this is the primary (or only) input that needs to be heard from the tech side. They think that because they're tossing us the "Agile" carrot they have carte blanche elsewhere and it is a "get out of jail free" card for their absolutely terrible decisions...like demanding the use of a CMS like AEM when building a dynamic RIA because they may feel the need to change the text of a button down the road. By being "Agile" the team can make up for the ignorant and time wasting technical decisions foisted upon by business.

ozmbie 9y ago

Read up on “cargo cults” and “cargo cult agile” and it makes a lot more sense. There are some genuinely good ideas in SCRUM and other development methodologies. But trying to codify those ideas into a set of rules for newcomers always leads to some degree of misinterpretation. I don’t know what the solution is, other than to ensure each team has constant input and support from somebody with authority and deep understanding of software development practices...and how often do you find people like that!

arwhatever 9y ago
Keep the code in a buildable state. Demo early and frequently to get feedback. Skip the rest.

clairity 9y ago

it's not the terms "agile" and "SCRUM" that are bs, it's the application of them. agile just doesn't work in most top-down organizations, where bs tends to be highest, because at it's core, agile is about providing a thin layer of self-accountability to self-organizing teams that are fairly autonomous. most (bad) managers want to believe they know better than the underlings and won't give up that much control.

lowbloodsugar 9y ago

I feel the same way about "Representative Democracy". Sounds like a great idea, and if it worked as advertised, it'd be great way to run a country. Unfortunately, its far easier to say "We have a representative democracy" than to actually implement one, and its in the interest of everybody "in the system" to just take bribes and do whatever the fuck they like. Scrum (its not an acronym) is the same. If you can get a bunch of people together who know what the fuck they are doing and want to write software that works for the customer, then its a great process. But 90% of "Scrum" I've seen is wankword bingo.