Thursday, April 29, 2010

Being an “Agile” Signatory

Recently, I posted a Status Update on LinkedIn announcing that I had become an “Agile” Signatory.
Those of you who follow me on LinkedIn or Twitter will know that being an “Agile” Signatory aligns with my overall attitude toward information technology. You may recall some recent posts: “
Enterprise architecture is at the nexus of business and technology”; “IT Architects are business professionals who apply architectural skills; just as other business professionals apply their skills”; and, “Architectural Organic Unity: containing all required & nothing unnecessary, all relationships & integrations being essential & inevitable.
I received an excellent reply from Steve Braver, “This would appear to conflict with your previous update on PM Best Practices, unless your position is that SDLC and Agile can both be valid approaches depending on the nature of the organization and project. That's what I believe.” __ Steve Braver, LinkedIn reply, 2010-APR-29
His thoughtful reply is the inspiration for this posting.
Actually, there is no conflict at all. Project Management methods and Solution Development Lifecycle (SDLC) methods are just that -- methods. Agile is, among other things, an approach to how to best tailor and apply a method – it is a mind-frame.
As I've read "The Enterprise Unified Process: Extending the Rational Unified Process" and "A Practical Guide to Enterprise Architecture", I've come to realize that I applied an Agile approach even when I worked with DoD standards. Many people think that DoD standards imply a boxcar load of documentation and process. However, that is not true. I was taught to tailor the DoD standards to just what was needed for the project. I've always taken a business-oriented suitably-tailored approach regardless of the method at hand: DoD, NASA, FIPS, Hoskyns, Method-1, GS-Method, and RUP.
RUP, which is extended to the EUP and AUP, can be performed "Agile" or not. In fact, I recently (a few years back) worked with a client that over-engineered RUP with process and documentation. It became quite unwieldy as well as entirely unnecessary. I observed that the tendency to over-engineer process and documentation was linked to a profound lack of understanding of a subject -- in this case, RUP.
I’ll continue to read these two books until I complete them. I am sure I’ll learn much more, However, at this point from reading and experience, I see no conflict between having methods and being Agile.
__ Joseph Starwood (

No comments:

Post a Comment