What do you think of the idea that providing finished work on an every-day-or-two cadence allows you to collect feedback from your customers in a way that keeps your work focused and relevant to their needs?
You can gather plenty of useful feedback to keep your work focused and relevant on cadences other than one or two days. What kind of customer even wants to provide feedback that often? That sounds awful, not to mention being a poor user experience, where users are treated like beta testers, with half baked features constantly pushed out the door.
This also ignores the fact that there is a huge amount of important work that is effectively invisible to the end user, but is absolutely crucial. The workflow you're suggesting disincentives the team from working on those things, and may even punish them for it (as they are not shipping customer visible features).
There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe.
And before you try to list off work you think fits this category, I urge you to think about how that work could affect a customer's experience.
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.
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]
> 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".
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.
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.
Why not just say "Agile Works Sometimes"? Or "Agile Can Work"? Because when "Agile Works" is touted, and then things go wrong, people get blamed, vs the actual processes and concepts. If "Agile Works", but we're not getting the results, then someone must be doing something wrong - can't be "Agile" that's wrong (for this scenario).
"Agile" software development doesn't work when there's 5 non-technical stakeholders and 1 software developer.
>There is no such thing as work that's absolutely crucial and not customer facing, so it makes perfect sense to disincentivize work that's shaped as you describe
I took a week to refactor some nasty crap a few months ago. No customer noticed it.
I was rather happy to lower the estimated time for a bunch of other tasks from weeks to days/hours after doing it.
Now you can argue that was not "absolutely crucial", but then we'll just disagree on what that means.
We asked our customer to include a small piece of information for every request they made to us to better serve them. It took five years for our customer to make the change. A one-or-two day cadence didn't make sense for us, nor apparently, for our customer.
Oh, our customer? It's the Oligarchic Cell Phone Company. They don't move fast. And as a result, neither do we.
