The IT Director would work with the sales team and choose a set of new features, functionality, and prioritized bug fixes to include in the next release of the software the company made.
Individual developers would then choose an individual item to work on from the list. When they'd done that one they'd pick another. When they were all done the release was ready.
Then I came along.
And they did.
The result:
All because an individual developer could get a better understanding of the area of the codebase they were working in. This allowed them to see the wider implications of an individual change more clearly so there were fewer unintended consequences of changes (bugs). Working in one area of the code base for longer meant fewer context switches so developers were more productive. And because only one person would be working in the same area at one time, issues (bugs) of merging multiple changes by different developers to the same files were avoided.
This also avoided all the hard changes being left to the end. Hard changes are more likely to take longer than anticipated and so leaving them until the end increased the likelihood of delays towards the end of a release cycle when delays had more serious consequences. Getting them done early as was necessary as part of a group of changes avoided surprises near the end.
Individual developers would then choose an individual item to work on from the list. When they'd done that one they'd pick another. When they were all done the release was ready.
Then I came along.
"Rather than picking individual work items one at a time (cherry-picking), why not group items that are in related parts of the system and have a single developer do all the work in that area at the same time?"
And they did.
The result:
- Faster delivery
- Less rework
- Fewer integration issues
All because an individual developer could get a better understanding of the area of the codebase they were working in. This allowed them to see the wider implications of an individual change more clearly so there were fewer unintended consequences of changes (bugs). Working in one area of the code base for longer meant fewer context switches so developers were more productive. And because only one person would be working in the same area at one time, issues (bugs) of merging multiple changes by different developers to the same files were avoided.
This also avoided all the hard changes being left to the end. Hard changes are more likely to take longer than anticipated and so leaving them until the end increased the likelihood of delays towards the end of a release cycle when delays had more serious consequences. Getting them done early as was necessary as part of a group of changes avoided surprises near the end.
