If this approach results in you taking limited and short term views of development, or low quality software with unhappy developers, you're doing it wrong.
Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).
Not all development fits nicely into day-or-two chunks. Forcing all your work to fit nicely into this type of mold is an arbitrary restriction that serves no real purpose except to check all the necessary scrum boxes, give the illusion of extra productivity, and allow for micro-management. It ends up being completely antithetical to thinking deeply and long term about the the code you're writing.
I've worked on teams that run the full gamut here. Those that did scrum and enforced "an every task should be one or two days" did not ship more or higher quality software than those that didn't, and the development teams were consistently more stressed and less satisfied with their work.
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.
let's have a meeting about how to break down our investigation of the unexplained segfaults in nginx that occasionally happen in our cdn into chunks that deliver value daily!
And then let's have daily progress meetings to report on the status of each chunk of the investigation! Please update Jira at least once a day!
This is a great example of the perverse incentives built into the "everything should be done in one day chunks that you report on daily". The team is incentivized to ignore highly important but challenging / hidden work, and instead only focus on things that are highly visible to management.
I think the point is that the only work that matters is work that will improve the customer experience in some way. That could be infrastructure/stability work, or that could be visible front-end work. Not sure how you're using the word "hidden", but that's my reading from this discussion. Either of those things are important/valued by management probably. But none of that should imply or require micromanagement in a high-trust engineering org.
This is really not that hard: "Yesterday I looked for correlations between segfaults and hardware vendors. I did not find a correlation, and my deliverable for the day is narrowing the search space. Today I will set up a micro cluster of random traffic to try to reproduce the crash. Tomorrow I will look for patterns in request bodies and stack traces."
Seriously, I feel you should write a blog post about this types of reporting strategies that describe the work that are both accurate and palatable to management (and perhaps most importantly avoid despise from other developers).
Breaking down work into small, day-or-two chunks is a team effort that the developers are doing together, alongside the customer (representative, usually).