- Paperback: 432 pages
- Publisher: Prentice Hall (July 26, 2004)
- Language: English
- ISBN-10: 0131467409
- ISBN-13: 978-0131467408
- Product Dimensions: 6.9 x 1 x 8.9 inches
- Shipping Weight: 1.2 pounds (View shipping rates and policies)
- Average Customer Review: 4.7 out of 5 stars See all reviews (17 customer reviews)
- Amazon Best Sellers Rank: #1,055,627 in Books (See Top 100 in Books)
Enter your mobile number or email address below and we'll send you a link to download the free Kindle App. Then you can start reading Kindle books on your smartphone, tablet, or computer - no Kindle device required.
To get the free app, enter your mobile phone number.
Organizational Patterns of Agile Software Development
Use the Amazon App to scan ISBNs and compare prices.
See the Best Books of the Month
Want to know our Editors' picks for the best books of the month? Browse Best Books of the Month, featuring our favorite new books in more than a dozen categories.
Frequently bought together
Customers who bought this item also bought
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 Fellow
Do 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 Consulting
Author 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
Excerpt. © 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.
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 its possible to implement the pattern WORK FLOWS INWARD (4.1.18). Developers, of course, dont 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 organizations value proposition. Most often, this value is or should be tied to the product you are producing for a paying customer. If it isnt obvious how the process step helps to achieve what you know the customer wants, the do the right thing instead.
Browse award-winning titles. See more
If you are a seller for this product, would you like to suggest updates through seller support?
Top customer reviews
All the patterns are built on the foundational pattern "Community of Trust," which requires dealing honestly and courageously with personal and organizational shortcomings. For too many organizations this is not possible until the crisis of a foreign element.
"Organizations run by professional managers tend to have repeatable business processes but don't seem to reach the same productivity plateaus as organizations run by engineers." Managers are administrators, not producers. Maybe they should be paid less than the producers.
"A thread that runs through all of our patterns (and that is fundamental to the principles of the pattern languages presented here) is the focus on product...the focus explicitly is not on process."
"When I was in fourth grade...we had a spelling test every Friday. Our teacher told us that if everyone got a perfect score...she would bring each of us a candy bar...There was no hope for us with [Jimmy] in the class...we all gave special help and encouragement to Jimmy. On Friday, when everyone got a perfect score, it was hard to tell whether we were more excited about the candy bar or about Jimmy's success." Reward teams, if teams are what you want.
And "strive to tangibly tie financial rewards to the market success that results from the fruits of an individual's labor." You think you have an adequate bonus structure? How about "bonuses that are on the same order of magnitude as annual compensation?"
How serious are you about a high-performing organization? Here are 100 tried and true patterns to jump-start your success.
Most recent customer reviews
As a...Read more