From the Back Cover
See what reviewers at Slashdot.org originally had to say about James and Neil's book! "This is a remarkably wise book, full of pragmatic advice drawn from real projects. Ultimately, software development is a human experience, and Jim and Neil have captured the essence of that experience in this work. The tapestry of patterns they have woven is postively brillant, and each thread therein is a delight to read."--Grady Booch, IBM FellowDo you want to really improve your software development organization instead of complying with an arbitrary standard, or trying the latest fad? This book presents the fundamentals of creating sustainable organizations, based on in-depth studies of over 100 real software development organizations. The authors present nearly 100 organizational patterns to help you create a highly effective organization. Case studies and vignettes illustrate how these patterns work. This practical guide shows you how to reshape critical parts of your organization. Regardless of your role, you will find patterns that you can use to make your organization more effective."This carefully researched, artfully described, and extraordinarily useful handbook of deep wisdom on creating teams that generate terrific software should be on every software development manager's bookshelf."--Luke Hohmann, Hohmann ConsultingAuthor of Beyond Software Architecture"As soon as I had worked through these patterns, I realized that several of my clients engaged in process definition projects could make use of them."--Ian Graham, Technical Director, trireme.com

Excerpted from Organizational Patterns of Agile Software Development by James O. Coplien, Neil B. Harrison. Copyright © 2004. Reprinted by permission. All rights reserved.
Developer Controls Process ... an organization has come together to build software for a new market in an immature domain or in a domain that is unfamiliar to the development team. Progress will be marked by an INFORMAL LABOR PLAN (4.1.14). The necessary roles have been defined and initially staffed. A development culture, like any culture, can benefit from recognizing a focal point of project direction and communication. Successful organizations work in an organic way with a minimum of centralized control. Yet important points of focus, embodied in roles, tie together ideas, requirements, and constraints into an artifact ready for testing, packaging, marketing, and delivery. Strict control is viewed by most development teams as a draconian measure. The right information must flow through the right roles. You need to support information flow across analysis, design, and implementation. Because developers contribute directly to the end-user-visible artifact, they are in the best position to take accountability for the product. Of all roles, they have the largest stake in the control. The manager has some accountability as well, to the extent that he or she indirectly supports delivery of the user-visible artifacts. These are process issues. Therefore: Make the Developer the focal point of process information. In the spirit of ORGANIZATION FOLLOWS MARKET (5.1.9) place the developer role at a hub of the process for a given feature. A feature is a unit of system functionality (implemented largely in software) that can be separately marketed, and for which customers are willing to pay. Responsibilities of developers include understanding requirements, reviewing the solution structure and algorithm with peers, building the implementation, and performing unit testing. Note that other hubs, such as a manager role, may exist as well, though they are less central than the Developer role. The Developer who is at the hub of a particular feature may be accorded that position according to FEATURE ASSIGNMENT (5.2.14), but, more generally developers should be at the communication hub of whatever process engages them in writing code for the customer. This pattern moved toward the center of the process using the patterns WORK FLOWS INWARD (4.1.18) and MOVE RESPONSIBILITIES (5.1.18). Though Developer should be a key role, care must be taken not to overburden that role. This pattern should be balanced with MERCENARY ANALYST (4.1.24), FIREWALLS (4.2.9), GATEKEEPER (4.2.10), and more general load-balancing patterns like RESPONSIBILITIES ENGAGE (5.1.14), HALLWAY CHATTER (5.1.15), and MOVE RESPONSIBILITIES(5.1.18). The Developer should enjoy particularly strong support from the PATRON ROLE (4.2.15), and conflicts can be escalated to the PATRON ROLE when consensus breaks down. If the Developer controls the process, then it’s possible to implement the pattern WORK FLOWS INWARD (4.1.18). Developers, of course, don’t control the process unilaterally, but as a collective group, starting with DEVELOPING IN PAIRS (4.2.28). We have no role called Designer because design is really the whole task. Managers fill a supporting role; empirically, they are rarely seen to control a process except during crises. While the Developer controls the process, the Architect controls the product. [In the figure, the Architect role is split across Framework Owner and ARCHITECTURE TEAM (5.2.4). This communication is particularly important in domains that are not well understood, so that iteration can take place to explore the domain with the customer. In a mature domain, consider HUB SPOKE AND RIM (5.1.17) as an alternative. You can still write down your process as part of a process improvement program. But keep the documentation light; many organizations have found that one page per process is good enough. And make sure each process step meets a need that you can tie to your organization’s value proposition. Most often, this value is or should be tied to the product you are producing for a paying customer. If it isn’t obvious how the process step helps to achieve what you know the customer wants, the do the right thing instead.