The process I propose will borrow from my experience with agile methods. I’ll use some of the scrum formalisms that I’ve found useful to get both the business and engineering teams working from the same prioritized list of features. I’ll mix that with some XP practices that I feel are critical to efficiently release software in short iterations.
When I refer to an agile development process, I mean one that favors adaptation to changing business and technical conditions over one that is optimized for any one situation. Some basic principals that guide me are:
- Use incremental delivery to allow learning—I acknowledge the fact that I don’t know everything about the requirements or design associated with a product release at the outset of its development. Incremental checkpoints allow me to reflect on what’s been built, and learn whether we are achieving the results that provide the business the most value.
- Use incremental delivery to reduce risk—I use incremental milestones to evaluate the risk associated with the development trajectory. These checkpoints allow the organization to assess progress against objectives and evaluate technical risks as early as possible. By requiring the quality of each incremental milestone to be at production levels, we never allow the code line to drift into a state of severe instability.
- Use incremental delivery to increase flexibility—the team needs to be able to quickly deliver functionality that the market (e.g. a pending deal) demands. To enable this capability, it is important to order feature development according to the business value of the features and revisit those priorities very frequently.
- Simplicity over “elegance”—resist the temptation to develop a complex architecture in anticipation of future functionality. I believe it is more cost-effective to pay the incremental costs associated with keeping the implementation as simple as possible, along with the cost of extending that implementation when necessary to accommodate new features, than to pay a high up-front cost to build a complex architecture in advance of requirements combined with the cost of maintaining that architecture over time until the new functionality is required. Also, I recognize the likelihood that the future-looking architecture will not be needed, or at least will need to be significantly revised when the future requirements are eventually implemented.
- Proactively refactor to achieve simplicity—keeping the implementation as simple as possible is a process, not an end. Project planning must accommodate time for refactoring, and the organization must be willing to pay these costs.
- Use infrastructure to enable safe refactoring—testing infrastructure and process must be continuously in place to provide immediate feedback when a refactoring effort has inadvertently changed the behavior of the system. The organization must maintain this infrastructure to effectively develop product features using these principles.
- Promote cross-pollination—allow individuals to work in a variety of areas of the product and to become proficient in a variety of technologies. Encourage collaboration and pairing during design, development, and testing—especially between engineering functions. A cross-pollinated development organization is able to adapt to new constraints and opportunities more quickly than a highly-specialized organization.
- Favor existing technologies and implementations over home-grown solutions—resist the temptation to build it yourself when robust, stable, and standard open-source implementations exist.
Next, I’ll talk about the process and practices I’ll propose to the team, and maybe how I go about communicating this vision to them.