Programming Books C Java PHP Python Learn more Browse Programming Books
  • List Price: $67.00
  • Save: $17.79 (27%)
Only 8 left in stock (more on the way).
Ships from and sold by
Gift-wrap available.
Organizational Patterns o... has been added to your Cart
Condition: Used: Like New
Comment: Clean Pages, Tight Binding. We inspect every item and grade conservatively. Fulfillment by Amazon: Ships FAST from Amazon's warehouse, with same return policy.
Access codes and supplements are not guaranteed with used items.
Sell yours for a Gift Card
We'll buy it for $14.03
Learn More
Trade in now
Have one to sell? Sell on Amazon
Flip to back Flip to front
Listen Playing... Paused   You're listening to a sample of the Audible audio edition.
Learn more
See this image

Organizational Patterns of Agile Software Development Paperback – July 26, 2004

ISBN-13: 978-0131467408 ISBN-10: 0131467409

Buy New
Price: $49.21
28 New from $26.52 26 Used from $26.31
Amazon Price New from Used from
"Please retry"
$26.52 $26.31
Free Two-Day Shipping for College Students with Amazon Student Free%20Two-Day%20Shipping%20for%20College%20Students%20with%20Amazon%20Student

Frequently Bought Together

Organizational Patterns of Agile Software Development + Scrum: The Art of Doing Twice the Work in Half the Time
Price for both: $64.66

Buy the selected items together

Hero Quick Promo
Save up to 90% on Textbooks
Rent textbooks, buy textbooks, or get up to 80% back when you sell us your books. Shop Now

Product Details

  • Paperback: 432 pages
  • Publisher: Prentice Hall (July 26, 2004)
  • Language: English
  • ISBN-10: 0131467409
  • ISBN-13: 978-0131467408
  • Product Dimensions: 6.9 x 0.9 x 9.1 inches
  • Shipping Weight: 1.2 pounds (View shipping rates and policies)
  • Average Customer Review: 4.9 out of 5 stars  See all reviews (16 customer reviews)
  • Amazon Best Sellers Rank: #800,356 in Books (See Top 100 in Books)

Editorial Reviews

From the Back Cover

See what reviewers at 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,

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 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.

Customer Reviews

4.9 out of 5 stars
5 star
4 star
3 star
2 star
1 star
See all 16 customer reviews
Keep the book handy.
Luke Hohmann
This book has to be The Grand Unifying Theory of Software with respect to managing the people and processes involved in software production.
Dr. Alex Farkas
And the pattern language figures are a good help.
Lise B. Hvatum

Most Helpful Customer Reviews

15 of 15 people found the following review helpful By Liping Zhao on September 1, 2004
Format: Paperback
This is the best book on patterns since the publication of Alexander's A Pattern Language. The book offers four pattern languages containing over 100 patterns that show you how to design, grow, shape and improve an organisation. The patterns are dense, full of insights, wisdom and knowledge; they are based on the authors' more than a decade of research and experience. Many of the patterns are timeless, such as CommunityOfTrust, ConwaysLaw and NamedStableBases. Some patterns are really beautiful, such as WorkFlowsInward, ArchitectAlsoImplements and FormFollowsFunction. Although the book is about organisational patterns, I have found it valuable for anyone who is interested in patterns or wishes to learn about patterns.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
8 of 8 people found the following review helpful By Dave Koo on April 10, 2005
Format: Paperback
OK, I have to admit, this is the first book review I've ever written on Amazon and having read a lot of good books I should probably get off my a** and write more :-)
As a former developer and now a software development manager, I have come to realise that the "soft side" or sociology of software projects (communication with clients, communication with teammates, project management, team dynamics, cultural issues, morale, division of work, remote collaboration, etc) is considerably more complicated than the programming work itself.
Over time, you start to see patterns emerge such as "start a large project with a small experienced group and gradually phase people into a project as time goes on". This book does by far the best job of cataloguing and explaining dozens of these patterns related to (1) software project management (2) structuring, building and nurturing software project teams and (3) organization and division of development tasks to maximize the effectiveness of the team as a whole.
Highly recommended to anyone involved with software development at both the management level and in the trenches. Have fun!
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
10 of 11 people found the following review helpful By Michael A. Beedle on September 18, 2004
Format: Paperback
This rare jewel is a practical guide to the deeper secrets and relationships of software development.

It is however based on "true Science", since it was originally based on extensions to Moreno's sociometric techniques, although it reads like literature -- it is art.

To the lucky ones that read it, understand it, and practice it, it will provide, undoubtedly, the passage to a higher level of understanding of how people work, and work best, when doing software devleopment.

Although "agile development" pehaps was first practiced by LISP programmers in the 1960's, Organizational Patterns is perhaps the first documentation that ever existed on true Agile development. No one, to my knowledge, had done so before. (Not Scrum, which started in 1993, nor XP which started much later. etc.)

To the interested readers I only have one simple advice: read every single page -- twice!!, and practice the patterns, many times!!!
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
7 of 7 people found the following review helpful By S. M. Lauer on November 24, 2004
Format: Paperback Verified Purchase
This is an outstanding book that distills years of experience into a system, a pattern language, that names, organizes, and relates together, many of the experiences and realities that those of us in the world of development have to deal with all of the time. As one who has functioned at many levels in development, I was able to recognize and appreciate most of the patterns. The only cavil I might have is that section 6.2 and on really pulls together what the book is about, and it seemed that it, or some version of it, really belonged in chapter 1.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
6 of 6 people found the following review helpful By Gerhard Ackermann on August 30, 2004
Format: Paperback
Patterns are good - good patterns are better - too many patterns are bad, if not presented well!

Jim Coplien and Neil Harrison definitely mined good org patterns and present them in way one can digest.

Many of them we had the chance of watching getting refined over years in the org pattern community so with the book you get definitely much more than what two persons could collect or research!

One can get out very practical hints if one is willing to spend at least several hours with the book to grasp the ideas and underlying concepts first. Once beyond that hurdle one can harvest details and insights for years.

Based on my own experiences and those of my faciltator group with several hundreds of IT-project retrospectives at Siemens Austria, regarding the concrete findings, the nice thing is, that it seems to be universal and not too culturally different what is summarized. I agree with most pattern core insights.
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again
6 of 6 people found the following review helpful By Linda Rising on August 26, 2004
Format: Paperback
It's true. There are a lot of patterns here, but most of them are just a page or two and you will remember them, not only because the patterns are well-written and the names are compelling, but because each is tellingly illustrated with a great photo! Some of these may seem like "common sense" -- especially to those of you who are great managers and team builders. Unfortunately, we know how well common sense appears at staff meetings these days :-)! Even the experts, can learn from the research that supports these patterns and some of it is surprising. The pattern "Size the Organization" recommends that teams have no more than 10 members and is one of my personal favorites. As a consultant who facilitates retrospectives across companies I can say that the penalty for not knowing these patterns can be severe. Pick up a copy and let the pictures and the prose draw you in!
Comment Was this review helpful to you? Yes No Sending feedback...
Thank you for your feedback. If this review is inappropriate, please let us know.
Sorry, we failed to record your vote. Please try again

Most Recent Customer Reviews

More About the Author

Jim ("Cope") Coplien is a speaker and author whose works range from programming and architecture to ethnography and organizational design. He is a founder of the Software Pattern discipline and of organizational patterns, which in turn were one of the foundations of Scrum. Though he writes for a technical audience, his works focus on the human element of product development. His latest work, "Lean Architecture" is as much about how architecture helps make software usable, as it is about software maintainability on the technical side.

Cope lives near Helsingør, Denmark, with his wife and son.

What Other Items Do Customers Buy After Viewing This Item?