Process Tailoring

Autonomy for each team in adopting Agile practices within a defined boundary.

Constraints shape and focus problems and provide clear challenges to overcome. Creativity thrives best when constrained. But constraints must be balanced with a healthy disregard for the impossible. Too many curbs can lead to pessimism and despair. Disregarding the bounds of what we know or accept gives rise to ideas that are non-obvious, unconventional, or unexplored. The creativity realized in this balance between constraint and disregard for the impossible is fueled by passion and leads to revolutionary change. For any process, Agile or not, to be really useful and successful in a variety of situations for different teams, we have to understand how to tailor it. Every project team inevitably augments, trims, or otherwise tailors the process they set out to use. The problem is that most of the time we do it blindly. We may have an idea what problem were trying to solve by adding some new practice, or some reason that we dont need a particular artifact. But process elements dont exist in isolation from one another. Typically, each provides input, support, or validation for one or more other process elements, and may in turn depend on other elements for similar reasons. Until we understand how process elements depend upon and reinforce one another, process design and tailoring will continue to be the hit-or-miss black art. The process tailoring model proposed here uses time- and scale-sensitive practices and dependencies, XP is an efficient feedback engine. Its nested feedback loops, each one optimized for the size of decision involved, dont just hasten feedback; they do so in very cost effective ways. Very small decisions, such as those made when writing statements and methods in a program, are very cheap to validate, so we feedback continuously, minuteby-minute, through interactions within programming pairs and through unit testing. Larger decisions, such as the selection of features to help solve a business problem and the best way to spend project budget, are quite costly to validate. Therefore projects needs to validate those decisions somewhat more slowly, through day-to-day interaction with customers, giving the customer control over each iterations feature choice, and by providing a release (for production use, if desired) every few weeks at most.

Software Artifacts /Decisions Solutions

Feedback Loop Length Months Weeks

Practices Short Release, Minimal Marketable feature Planning Game, User Stories, Story Mapping, User Stories, Automated Acceptance Test, Specification by Example Collective ownership

Priorities, Estimation Features

Weeks

Architecture

Days

Design

Hrs

Classes and Interfaces Statements and Methods

Minutes Minutes, Seconds

Emergent Design, TDD, BDD, Refactoring, CI, Mocking, SOLID principles SOLID principles, Clean Code Unit Testing, Clean Code, Pair programming