4 ms·

I didn't say "not costumer facing", I said "invisible". A lot of important work is something a customer will have no idea exists until it goes wrong. If you've

I didn't say "not costumer facing", I said "invisible". A lot of important work is something a customer will have no idea exists until it goes wrong. If you've done your job right, it will remain invisible forever. Because it's invisible, what's the point of arbitrarily shipping it in one-to-two day chunks to "gather user feedback"? Be willing to take the time to do hard things right. I'm not proposing you spin your wheels for ages on something, and I'm generally in favor of shipping early and often, it's just trying to fit every different shaped problem into the same process that doesn't work for me.

TameAntelope 5y ago
If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me. I can think of plenty of ways to show a customer how we fail gracefully or not at all despite certain negative events. Some customers may even value that very highly, depending on the use case. And I get that this idea may not work for you, but it works for a lot of very successful people, the luminaries of our field. You're arguing against Ward Cunningham, Robert C. Martin, James Shore, Martin Fowler, Joel Spolsky, Jeff Atwood, Bill Wake, Andrew Hunt, Dave Thomas, et. al. Customer collaboration over contract negotiation. [0] Who should I listen to; you, or them? [0] https://agilemanifesto.org/ https://agilemanifesto.org/
- Trasmatta 5y ago
  > If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me. Solve the problem at hand in the way that suits that particular problem best. Don't be a slave to a rigid process. Don't burn out your developers with a dysfunctional system. Not every problem is well suited to being broken up into single day chunks of work. Not every developer can maintain a healthy relationship to their work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer burnout, or modern day scrum and agile. You mention the Agile Manifesto, but seem to forget that one of the primary points is "individuals and interactions over processes and tools".
  - TameAntelope 5y ago
    What do you think an "interaction" is? I'm literally saying you need to have more user interactions, and you're saying you need to have fewer. Delivering software to your customer is an interaction. You need more of those, not less of those. "Stories are "just right" when the whole team can finish four to ten per week, or about six on average." [0] "For stories that are too big, work with your customers to split them into smaller stories." [0] If you think it's just "Everything gets shipped every day or two and no other changes get made to how the team functions." then I have not been clear. It's a massive mindset shift, and it comes with a number of other important changes, all of which are best read from the experts themselves, rather than interpreted through me in an HN comment. Suffice it to say, it's all been accounted for. Agile works. [0] https://www.amazon.com/Art-Agile-Development-Pragmatic-Software/dp/0596527675 https://www.amazon.com/Art-Agile-Development-Pragmatic-Softw...
    - Trasmatta 5y ago
      I'll just reiterate what I said above, because I feel there's more to the problem at hand than "number of customer interactions": > Not every problem is well suited to being broken up into single day chunks of work. Not every developer can maintain a healthy relationship to their work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer burnout, or modern day scrum and agile. You mention the Agile Manifesto, but seem to forget that one of the primary points is "individuals and interactions over processes and tools". I don't plan to continue the conversation at this point, because it's not productive.
      - TameAntelope 5y ago
        You began this conversation saying that interactions are bad, and end with saying they're good, so I will take that win as I can get it! :D
    - jacobyoder 5y ago
      > Suffice it to say, it's all been accounted for. Agile works. And if you are doing "Agile" but it's not working... then you're Doing It Wrong(tm). Right?

TameAntelope 5y ago

If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me. I can think of plenty of ways to show a customer how we fail gracefully or not at all despite certain negative events. Some customers may even value that very highly, depending on the use case. And I get that this idea may not work for you, but it works for a lot of very successful people, the luminaries of our field. You're arguing against Ward Cunningham, Robert C. Martin, James Shore, Martin Fowler, Joel Spolsky, Jeff Atwood, Bill Wake, Andrew Hunt, Dave Thomas, et. al. Customer collaboration over contract negotiation. [0] Who should I listen to; you, or them? [0] https://agilemanifesto.org/ https://agilemanifesto.org/

Trasmatta 5y ago
> If it impacts a user negatively if it's done wrong, that sounds pretty damn visible to me. Solve the problem at hand in the way that suits that particular problem best. Don't be a slave to a rigid process. Don't burn out your developers with a dysfunctional system. Not every problem is well suited to being broken up into single day chunks of work. Not every developer can maintain a healthy relationship to their work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer burnout, or modern day scrum and agile. You mention the Agile Manifesto, but seem to forget that one of the primary points is "individuals and interactions over processes and tools".
- TameAntelope 5y ago
  What do you think an "interaction" is? I'm literally saying you need to have more user interactions, and you're saying you need to have fewer. Delivering software to your customer is an interaction. You need more of those, not less of those. "Stories are "just right" when the whole team can finish four to ten per week, or about six on average." [0] "For stories that are too big, work with your customers to split them into smaller stories." [0] If you think it's just "Everything gets shipped every day or two and no other changes get made to how the team functions." then I have not been clear. It's a massive mindset shift, and it comes with a number of other important changes, all of which are best read from the experts themselves, rather than interpreted through me in an HN comment. Suffice it to say, it's all been accounted for. Agile works. [0] https://www.amazon.com/Art-Agile-Development-Pragmatic-Software/dp/0596527675 https://www.amazon.com/Art-Agile-Development-Pragmatic-Softw...
  - Trasmatta 5y ago
    I'll just reiterate what I said above, because I feel there's more to the problem at hand than "number of customer interactions": > Not every problem is well suited to being broken up into single day chunks of work. Not every developer can maintain a healthy relationship to their work with that level of micromanagement. There is a huge amount of anecdotal evidence about this if you read any thread about developer burnout, or modern day scrum and agile. You mention the Agile Manifesto, but seem to forget that one of the primary points is "individuals and interactions over processes and tools". I don't plan to continue the conversation at this point, because it's not productive.
    - TameAntelope 5y ago
      You began this conversation saying that interactions are bad, and end with saying they're good, so I will take that win as I can get it! :D
  - jacobyoder 5y ago
    > Suffice it to say, it's all been accounted for. Agile works. And if you are doing "Agile" but it's not working... then you're Doing It Wrong(tm). Right?