Organisational Patterns
One of the most enlightening and practical books I have read recently is Organisational Patterns of Agile Software Development by Coplien (http://www.amazon.com/exec/obidos/tg/detail/-/0131467409/002-3524002-2666431?v=glance)
Alexander's original pattern theory applied to architecture of towns and buildings.
http://www.amazon.com/exec/obidos/tg/detail/-/0195019199/qid=1130880069/sr=1-1/ref=sr_1_1/002-3524002-2666431?v=glance&s=books
Design Patterns for Reusable Object-Oriented Software introduced the IT industry to pattern theory. http://www.amazon.com/exec/obidos/tg/detail/-/0201633612/qid=1130880169/sr=1-1/ref=sr_1_1/002-3524002-2666431?v=glance&s=books
Coplien's book is the result of 10 years of research into successful software development companies. I'd argue that the use of the Agile word in the title is related to profit rather than a tre depiction of agile patterns. Coplien's book uses pattern theory to describe organisational architectures that can be used to solve particular problems within a specific context.
The value of pattern theory is that the patterns identified aren't theories created out of thin air, or a methodology created by a process engineer; patterns illustrate empirical evidence of successful implementations of a solution to a particular context.
Too verbose? OK, wouldn't it be great if when you came to a problem at work, you could know how hundreds of people have solved the same problem in the past?
Coplien has identified and describes how certain organisational problems in software development can be solved through the application of patterns within a specific context.
Some of these patterns are fundamental to both agile teams and agile organisations such as:
One of the patterns I have relied on recently is the Architect also Implements pattern which I have discussed with Technical Architects within the team. This pattern suggests "A software project must broaden the scope of leadership without sacrificing depth and attention to pragmatics" and "Beyond advising and communicating with Developers, Architects should also participate in implementation."
For me the lesson is to always keep in mind is that Technical Architects should not be Isengard Tower wizards out of touch with teams, rather they should be Master craftsmen of their trade. Still creating elegant, efficient software but also designing with, coaching and mentoring others.
If you're looking into structuring teams and organisations for agile development, this book needs to be on your research list.
Alexander's original pattern theory applied to architecture of towns and buildings.
http://www.amazon.com/exec/obidos/tg/detail/-/0195019199/qid=1130880069/sr=1-1/ref=sr_1_1/002-3524002-2666431?v=glance&s=books
Design Patterns for Reusable Object-Oriented Software introduced the IT industry to pattern theory. http://www.amazon.com/exec/obidos/tg/detail/-/0201633612/qid=1130880169/sr=1-1/ref=sr_1_1/002-3524002-2666431?v=glance&s=books
Coplien's book is the result of 10 years of research into successful software development companies. I'd argue that the use of the Agile word in the title is related to profit rather than a tre depiction of agile patterns. Coplien's book uses pattern theory to describe organisational architectures that can be used to solve particular problems within a specific context.
The value of pattern theory is that the patterns identified aren't theories created out of thin air, or a methodology created by a process engineer; patterns illustrate empirical evidence of successful implementations of a solution to a particular context.
Too verbose? OK, wouldn't it be great if when you came to a problem at work, you could know how hundreds of people have solved the same problem in the past?
Coplien has identified and describes how certain organisational problems in software development can be solved through the application of patterns within a specific context.
Some of these patterns are fundamental to both agile teams and agile organisations such as:
- Community of Trust
- Get on with it
- Development Episode
- Engage Customers
- Unity of Purpose
- Developing in Pairs
- Conway's Law
One of the patterns I have relied on recently is the Architect also Implements pattern which I have discussed with Technical Architects within the team. This pattern suggests "A software project must broaden the scope of leadership without sacrificing depth and attention to pragmatics" and "Beyond advising and communicating with Developers, Architects should also participate in implementation."
For me the lesson is to always keep in mind is that Technical Architects should not be Isengard Tower wizards out of touch with teams, rather they should be Master craftsmen of their trade. Still creating elegant, efficient software but also designing with, coaching and mentoring others.
If you're looking into structuring teams and organisations for agile development, this book needs to be on your research list.
Comments