Software development looks like manufacturing if the unit of inventory is the unvalidated decision. —Alistair Cockburn

What do you do when you finish your work early in an iteration, and have a few days left in the sprint? Do you just pull in another story from the backlog? After all, there's plenty of work to do, why not get a jump on it?

No, that's not what you do. First, you remember that you are part of a team, so you see if anyone on the team needs your help to finish their work, which will help the team deliver on its commitments for the iteration.

OK, so you did that. Now can you pull in another story from the backlog? No!

In his post, 10 Things You Could Do When You’re Done Writing Code, John Krewson of VersionOne talks about the perils of pulling in more work from the backlog mid-iteration:

When you add additional work into the iteration, you’re increasing the batch size. This causes additional complication due to increased changes in the code base. It usually results in carryover, which has a demoralizing effect on the team. And it eliminates an opportunity to get feedback on the emergent product before additional work is embarked on.

Remember, the iteration was planned so that all members of the team can function at optimum efficiency, not so that the developers can program at optimum efficiency.

A lot of agile development ideas come from lean manufacturing, so it is informative to compare the two. In A Study of the Toyota Production System: From an Industrial Engineering Viewpoint, industrial engineer Shigeo Shingo says:

Workers can be kept busy with the following types of tasks during low-demand periods:

• Repairing small leaks throughout the plant that have been neglected. (This saved one company close to $5,000 in water charges.)
• Maintaining and repairing machines that have been negleced during the regular production cycle.
• Practicing tool and die changes.
• Fabricating jigs and fixtures for planned improvements.

Compare that with this list of things agile development team members should do, again from John Krewson's post:

1. Refactor something you recently wrote.
2. Add unit tests to an uncovered area of code.
3. Find a technical tutorial on the Internet.
4. Offer to pair with a developer on another team.
5. Estimate open items in the backlog.
6. Create some automated functional tests.
7. Clean your desk.
8. Ask your product owner about the next release.
9. Help your product owner create acceptance criteria for items in the backlog.
10. Implement a prioritized improvement suggestion from the last retrospective.

In both cases, the key thing is that you should not be doing work that you do not know you need. In manufacturing, you should not be making more parts than you need right now, because:

• You don't know when you will need them.
• If you make up a whole bunch of them in advance, there may be a design change before you need them, rendering them useless.
• They take up space that could be used for manufacturing.

Similarly, when you bring in new stories from the backlog, you do not know if you are going to need them. When you do the end-of-sprint review, the customer feedback may send you off in another direction, and what you have coded will be wasted.

A parallel to what John Krewson said about improving the overall team efficiency, not just that of the developers, is the way manufacturing used to be done. Back in the day, the goal was to get 100% utilization out of the machines, since they were expensive. So, even if parts were not needed, they were manufactured and warehoused for later use, just to increase the machine utilization. And they were produced in large quantities, to reduce the effect that setup time had on utilization. And they were scrapped out when a design change occurred.

This is like what we used to do in software development, producing a lot of infrastructure programs because we thought we would need them someday. I have done this many times over the course of my career, and invariably, when I actually do need the code, I have to rework it. This is the genesis of the Extreme Programming rallying cry You Aren't Gonna Need It (YAGNI).

There are plenty of things to do with leftover time in an iteration that are better than producing new code that my may have to discard or rework.

I would like to thank John Krewson and Andrea Keeble of VersionOne, John for his excellent post that expressed some of these ideas more eloquently than I could, and Andrea for permission to quote much of the post here.

In the spirit of both disclosure and self-promotion, I would like to mention that my company, CA Technologies, has a joint venture with VersionOne to provide seamless integration with our own CA PPM (Project and Portfolio Management) product: http://www.versionone.com/ca/