5 ms·

I feel like people who are opposed to agile and scrum often make out things of it that are in no way prescribed by these methodologies. For example, I see peopl

by mmcnl 7y ago

I feel like people who are opposed to agile and scrum often make out things of it that are in no way prescribed by these methodologies. For example, I see people mentioning the idea that with scrum, you should release working software every sprint. This is not the case. The idea is to deliver a _potentially_ shippable product increment - a.k.a. not building 10 bridges in parallel if there's no need for it. Some might even call this common sense. Most people who are pessimistic about the agile development who I have spoken to are usually pessimistic because of poor implementations they've encountered. Any methodology is awful when misused or when hidden agendas are at play. No methodology will ever solve that. That being said (probably onpopular opinion), I often also see engineers use agile to blame everything that is going wrong onto "management" and use it as way of avoiding responsibility. Complaining and arguing as if there are only absolutes is an immature and unproductive attitude. Calling agile "nonsense" is a prime example of that.

theworld572 7y ago
My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. Software development almost never works out so neatly. What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. You start working on it, maybe you discover that there is a whole area of code that needs updating in order to allow for your feature to be implemented. This adds on another week of work required. In a common-sense based development team, what usually happens is the developer has a quick work with the project manager and maybe other devs who need to be involved and says "Hey, I've found out that we need another week to complete this feature because X needs refactoring, do you still want me to continue with this?" then the PM either says "Yes this feature is important, even if it will take another week" or "No, the feature is not important enough to be worth spending another week on". Its really not rocket science. In SCRUM what usually happens is the SCRUM master will tell you that the rules say that we have already committed to a set amount of work this sprint and that extra week of work falls outside the scope so we should create another card for the extra work and consider this card blocked. The whole idea of having a rule for what to do in that situation just seems absolutely crazy. Just do whatever makes sense! Its really not that difficult.
- taneq 7y ago
  > What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. The thing is, your story cards or whatever are meant to be a live document. You have the big meeting, the next day you realise that what you came up with doesn't work, you grab a coffee with your stakeholder and talk it through, come up with a new plan, and you change the card you're working on. Probably check with the tech lead first, but it's that flexible. > In SCRUM what usually happens is the SCRUM master will tell you that the rules say [...] This SCRUM thing sounds evil. > Just do whatever makes sense! Its really not that difficult. This is probably the best advice ever for any development team. Just do the thing!
  - Tharkun 7y ago
    I think the OP is missing the point of scrum. The scrum master isn't supposed to tell you what the rules are. The rules are whatever the team decides they are. The scrum master is not the boss, they're supposed to be a facilitator...
    - taneq 7y ago
      Exactly. It's meant to be collaborative, not authoritative.
    - theworld572 7y ago
      That sounds like typical scrum-enthusiast double-speak to me! :D https://www.scrum.org/resources/what-is-scrum https://www.scrum.org/resources/what-is-scrum "This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together." Definitions, Rules, Roles, Artifacts etc. Sounds pretty authoritative to me. If it wasn't authoritative, how would you even know what SCRUM "really" is? You cannot say both that SCRUM is not authoritative and lets you do what you want, and then also say "you're not doing scrum correctly".
      - empath75 7y ago
taneq 7y ago
I think Agile has the same strength and weakness of any methodology: The people implementing it. If you have good people running and working on an Agile project it's going to go well. Those same people would do similarly well with waterfall, or just sitting in a dark room with a carton of Coke each. Where your methodology really matters is the how information flows between your dev team, the end users, and any other systems you need to interoperate with. Agile is great for providing development-as-a-service to a client who doesn't know what they want but will know it when they see it (eg. building enterprise software or web apps). Waterfall is great for providing known, fixed functionality (eg. building an ECU for an engine, or a back-end for a web bank).
zamadatix 7y ago
The problem I've seen with agile is it's too easy to turn into "as long as we complete something that was defined as value this sprint the problem isn't what this team is doing" that many places end up having teams avoiding any large or external issues completely while reporting everything is going great. You may say it's not a methodologies fault when it's misused but I'd say it IS a methodologies fault if the feedback cycle on the misuse is easily hidden by the process. In the end I think for many places where agile is put in more value would be had putting that work into the business communication flow. If your biggest problem to solve is you don't know how to work on problems in smaller chunks + communicate when you've done something and that's what you need to reform you're probably doing pretty good and agile will be great. If you're implementing agile for another reason it probably won't fix that problem and agile will be blamed.
- mmcnl 7y ago
  > teams avoiding any large or external issues completely while reporting everything is going great This is what happens all the time in big companies, agile or not.
  - zamadatix 7y ago
    Avoiding sure reporting not really. I mean sure anyone can purposefully not follow a methodology but that's not what I'm talking about here.

by mmcnl 7y ago

theworld572 7y ago

My biggest criticism of Agile and Scrum is that it assumes that you can just plan out how a feature will work by sitting in a meeting and talking about it. Then spend the next two weeks implementing that plan. Software development almost never works out so neatly. What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. You start working on it, maybe you discover that there is a whole area of code that needs updating in order to allow for your feature to be implemented. This adds on another week of work required. In a common-sense based development team, what usually happens is the developer has a quick work with the project manager and maybe other devs who need to be involved and says "Hey, I've found out that we need another week to complete this feature because X needs refactoring, do you still want me to continue with this?" then the PM either says "Yes this feature is important, even if it will take another week" or "No, the feature is not important enough to be worth spending another week on". Its really not rocket science. In SCRUM what usually happens is the SCRUM master will tell you that the rules say that we have already committed to a set amount of work this sprint and that extra week of work falls outside the scope so we should create another card for the extra work and consider this card blocked. The whole idea of having a rule for what to do in that situation just seems absolutely crazy. Just do whatever makes sense! Its really not that difficult.

taneq 7y ago
> What really happens is that you have a set of requirements and an idea of how you are going to implement the feature. The thing is, your story cards or whatever are meant to be a live document. You have the big meeting, the next day you realise that what you came up with doesn't work, you grab a coffee with your stakeholder and talk it through, come up with a new plan, and you change the card you're working on. Probably check with the tech lead first, but it's that flexible. > In SCRUM what usually happens is the SCRUM master will tell you that the rules say [...] This SCRUM thing sounds evil. > Just do whatever makes sense! Its really not that difficult. This is probably the best advice ever for any development team. Just do the thing!
- Tharkun 7y ago
  I think the OP is missing the point of scrum. The scrum master isn't supposed to tell you what the rules are. The rules are whatever the team decides they are. The scrum master is not the boss, they're supposed to be a facilitator...
  - taneq 7y ago
    Exactly. It's meant to be collaborative, not authoritative.
  - theworld572 7y ago
    That sounds like typical scrum-enthusiast double-speak to me! :D https://www.scrum.org/resources/what-is-scrum https://www.scrum.org/resources/what-is-scrum "This Guide contains the definition of Scrum. This definition consists of Scrum’s roles, events, artifacts, and the rules that bind them together." Definitions, Rules, Roles, Artifacts etc. Sounds pretty authoritative to me. If it wasn't authoritative, how would you even know what SCRUM "really" is? You cannot say both that SCRUM is not authoritative and lets you do what you want, and then also say "you're not doing scrum correctly".
    - empath75 7y ago

taneq 7y ago

I think Agile has the same strength and weakness of any methodology: The people implementing it. If you have good people running and working on an Agile project it's going to go well. Those same people would do similarly well with waterfall, or just sitting in a dark room with a carton of Coke each. Where your methodology really matters is the how information flows between your dev team, the end users, and any other systems you need to interoperate with. Agile is great for providing development-as-a-service to a client who doesn't know what they want but will know it when they see it (eg. building enterprise software or web apps). Waterfall is great for providing known, fixed functionality (eg. building an ECU for an engine, or a back-end for a web bank).

zamadatix 7y ago

The problem I've seen with agile is it's too easy to turn into "as long as we complete something that was defined as value this sprint the problem isn't what this team is doing" that many places end up having teams avoiding any large or external issues completely while reporting everything is going great. You may say it's not a methodologies fault when it's misused but I'd say it IS a methodologies fault if the feedback cycle on the misuse is easily hidden by the process. In the end I think for many places where agile is put in more value would be had putting that work into the business communication flow. If your biggest problem to solve is you don't know how to work on problems in smaller chunks + communicate when you've done something and that's what you need to reform you're probably doing pretty good and agile will be great. If you're implementing agile for another reason it probably won't fix that problem and agile will be blamed.

mmcnl 7y ago
> teams avoiding any large or external issues completely while reporting everything is going great This is what happens all the time in big companies, agile or not.
- zamadatix 7y ago
  Avoiding sure reporting not really. I mean sure anyone can purposefully not follow a methodology but that's not what I'm talking about here.