How to create generic/reusable code with Scrum?

Question

Scrum development is based on listing user stories and implementing them in during sprints. That approach - focusing on actual goals of the end product - definitely has its virtues, but what bugs me is that it doesn't advocate creating any generic/reusable code in the process, and actually I feel like it advocates hacking. For example, if an user story says

Must be able to plot x versus y, and fit a line there.

my first thought is that, "hey, I need to create a generic graphing framework so that I can handle similar cases more efficiently later on". But that's not the goal in the scrum sprint; the goal is simply what the user story says.

So it is more desirable (from Scrum viewpoint) to simply hack something together so that the user story gets implemented, instead of trying to understand the big picture and creating something more generic (which, of course, takes more time initially).

Is this unavoidable? Have I misunderstood something? How do you combine Scrum'ing an actual product with creating something reusable at the same time? Is reusability old-fashioned and overrated?

Answer 1

I think the issues of reusability and code quality lie outside of the team process dimension. Well maybe not entirely, but at least the agile approach does not deal with those. You're free to put in some extra effort to increase the reusability ratio or just quickly hack things together.

You could add some extra fixed time to each sprint to be used explicitly for code review and working on reusability.

Answer 2

I would only spend the time building a generic graphing framework when you need to, for the first sprint write something that plots X versus Y. That might be as far as you go with graphing so there would be no need to write a framework.

If in further sprints you need to do more graphing, then create your framework. Work in time to the sprint to allow you to do this.

Answer 3

As Fermin says, the first time you need something isn't the time to start building a framework. YAGNI: you just build something that plots X vs Y.

Going further, I have found that even the second time you need something, it's still not time to build a framework yet. The problem with frameworks built on one or two use cases is that it's rare they'll actually be useful and generic enough for anything more than those one or two use-cases.

Building general, reusable, code is hard. There is nothing more useless and confusing to another developer coming after you than something that appears to be a framework, but is actually only used by one or two projects and is in fact tightly coupled with those projects.

One of the founding principles of the X Windows System was:

The only thing worse than generalizing from one example is generalizing from no examples at all.

Good advice I'd say!

Answer 4

Generally if you create generic solution without actual need for it you are not following agile approach. You should avoid refactoring in advance. Otherwise it is gold plating where you are adding functionality which is not needed and which is not required by your customer at the moment (priority approach).

But sometimes it can be needed to create reusable component. This usually happens when more than one team plans to use the same component or when custom framework is created separately. In SCRUM you can do this in following approach. The main project which will use the component will become product owner for the component. It will define features which are needed as user stories. Component team will implement those features and provide the component to the main team in the iterative way.

So suppose that you have two projects which expects that they will need component for credit card payments. These two teams collect user stories with priorities and provides them to component team. They will plan together delivery so that component team provides only functionality needed by main teams in current sprint.