Scope

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.

Software should do one thing, and do it well. Each piece of software should have a clearly-stated goal that is used to determine whether a particular feature should be implemented or not. When a proposed feature does not fit with the software’s stated goal then don’t implemented it. Just don’t.

Like adding source control to your product. We already have several perfectly good source control systems. Building your own custom source control system into your product is never a good idea. Your implementation is unlikely to be as good as the standalone products like Git, Mercurial or Subversion, and it’ll probably make it difficult for me to use my source control system of choice.