One thing that development teams constantly struggle with is striking a balance between building features, fixing bugs, paying down tech debt, and embarking on more ambitious activities like replacing core components in their architecture. It’s also something that Agile tries to solve but I’ve never seen it solved to everyone’s satisfaction.
And I think it’s because many Agile Product Owners are focused on the specifics of what features they’d like to see built instead of setting the direction for the dev team and letting them figure out how to get there. They allocate some random percentage of the sprint to tech debt just to keep the team happy but it’s hard to make significant changes with 10% of the sprint capacity.
Let me explain what I mean by that. I’d prefer to see a goal like “reduce login time to 300ms” instead of “switch to Azure AD for authentication”. The former specifies the desired outcome whereas the latter tells the team what to do without any context as to why. There’s no creativity, lattitude or autonomy with the “swith to Azure AD” story - the team will just pick up the story, implementt it and ship it - no questions asked, no responsibility taken if it doesn’t reduce login times.
However, when teams are given a goal they are free to meet that goal in whatever way they see fit. That might mean refactoring that gnarly part of the login module, or caching data, or splitting a service into smaller services. It doesn’t matter how they get there as long as they satisfy the goal. Many of the arguments about features vs tech debt evaporate when Product Owners stop “managing the backlog” and start defining the outcomes.