The end game is the part of the development cycle between functional completion and shipment. It’s the easiest part of the cycle to manage. QA identifies must fix defects. Development performs surgical repairs without disturbing the rest of the system. Eventually an equilibrium between defect discovery and repair is obtained. One more regression test and we ship.
The end game is the easiest part of the development cycle to manage because it’s algorithmic. Only edit code to address something that prevents shipment. Team review every change. Manager review every check in. Team and manager review each change with QA: what’s the functional change, what’s the regression risk. All you managers out there, speak with an authoritative voice tone, enjoy the feeling of competent change management!
The end game is the easy part. What about the rest of the development cycle? How do you get the changes you want:
- New features with agreed on market value
- Refactoring that supports work breakdowns, be they development, test etc.
- Refactoring that eliminates redundant code and otherwise enhances support
This is the change control that makes a difference over the life of a product. This change control is very different from the grumpy no more scope voice in the end game.
Getting the Valuable Features
I’m assuming you’ve a high-level list of features for a given release. The feature challenge lies inin picking the sub-features that haven’t been thought through at requirements time. Developers run into these non-spec’d areas all the time and have to decide what to do. Beware sub-features chosen in a vacuum! Foster a team culture where non-spec’d areas are a topic of discussion, ideally cross functionally. Frequent demo’s, walk throughs by developers of their code either in review or not, and a norm of discussion avoids surprises. The idea here isn’t that you, the manager, make all the choices. The idea is that the sub-feature decisions are known. Then the team can make intelligent decisions.
Re-factoring that Works
Before the Agile guys convinced us otherwise, re-factoring code was bad. Diffs no longer show functional change, making it hard to integrate branched back into a main tree. QA , who probably doesn’t trust you anyway, gets snooty and starts talking about all the testing that’s now been invalidated and will have to be re-run. And those are legitimate beefs about large amounts of code change.
But, in order to scale your development efforts, you have to be able to build parts of the system in parallel. You’ll need well defined and defended module and component boundaries or your developers will spend all their time getting in each other’s way. Your team will build better and better component boundaries over time if you create a climate conducive to smart re-factoring. Take a tip from Feature Driven Development and define work breakdowns at the object level, with interfaces between objects as the primary developer to developer contract. Hold regular reviews focusing on interfaces between the top level objects in the system design, and focus your code reviews on the implementation of the interfaces themselves. You might even want to have your team reviews focus on the unit tests for the interfaces, not the interface implementations. These are all formalisms to focus engineering attention on component boundaries. Over time, you’ll end up with a system where components can be significantly re-factored without throwing the whole product in the ditch.
The moral of the story is that the end game is the only time managers have much of a chance to directly manage change. By then, it’s too late to have an impact on the important stuff. The important stuff, spending time on valuable features, growing re-factorable code, happens when you’re in a meeting. But by creating a set of team cadences and practices that focus on communication and team interaction you’ll help your team do it’s own change control.
0 Responses to “Change Control”