In your book, under the chapter "4 What is agile software architecture?" read the very interesting analogy of a fighter pilot (the John Boyd's notes) following 'OODA' loop and software development being Agile.
However having seen Agile process across a few firms I've worked with have noted significant variations in its implementation.
In your book you have written exactly what my concern is but is specific to being 'Agile' -
"If you think about any problem that you’ve needed to solve, there are probably a hundred and one ways in which you could have solved it."
What is the best way to achieve this agility (standardize it so that it works every time like a design pattern that is proven to work for a situation?) and how to integrate this with software architecture?
Hi Rommel. The significant variations that you've seen in agile implementations are common, and this is basically because the purpose of agile approaches is to not prescribe a strict methodology that the team should follow. It's about moving fast and embracing change, but also about adapting the approach to best satisfy the goals given the context of the environment. I'm not sure that you can (and should) standardise an agile approach, but there's certainly scope for creating some guidelines or a starting point. This is essentially what something like DSDM Atern does -> http://www.dsdm.org/dig-deeper/book/dsdm-atern-handbook
As for the integration of software architecture, that's really what my book is about ... introducing a minimal set of lightweight software architecture practices that are applicable to any software project, regardless of approach. This includes "just enough" up front design, communicating software architecture using a collection of simple sketches and ensuring that any important risks are dealt with early on.
Simon Brown wrote:I'm not sure that you can (and should) standardise an agile approach
I agree, attempts to "standardize" an Agile approach usually becomes an exercise in futility. Patterns themselves are not "pre-packaged" solutions that you can just slap onto a problem either. Sure, a specific implementation of a pattern is great when you have one that you can apply wholesale or with slight modifications but the implementation is not the pattern itself. The beauty of a pattern lies in its generality and applicability to a number of different problems that belong to a certain class of problems. For me Agile is the pattern and there are many different ways you can implement it, so why limit yourself by trying to "standardize"? IMO, the best you can do is, as Simon said, create some guidelines and a starting point. For all the other stuff you just have to be, well, Agile.