Thoughts on OpenUP?


I have been reading up on the The Eclipse Process Framework (EPF).  In particular the OpenUP Agile Methodology.

I found it funny that when I looked at the process documentation is resembled closely Scott Amblers Agile Unified Process that I had used as source of inspiration for outlining some of the concepts in our department.  Then to find out that Scott was a principle contributor to this process didn’t surprise me at all.

Some of you who read my blog on a regular basis know that I have been struggling with setting guidance and direction for an agile enterprise adoption strategy. My dilemma has been focused on the contextual nature of our business model.  For some lines of businesses it does fit and for others it doesn’t.  When dealing with enterprise entities, the enormity of the situation comes into view very quickly.  It’s really easy to inspire 50 people to the beat of one drum, it’s another to inspire 10,000. 

I hate to say this but when you are dealing with that hundreds or thousands of developers more structure must exist, then simply perceived philosophical propaganda.  Some of you are going to read that last statement and overlook the fact that I placed “perceived” in there.  Telling a group of this magnitude that working software is the measurement of business incentive does not necessarily motivate executive leadership to adopt these Agile processes.  Development Groups and PMO’s quickly want to see process flows, control points, sign offs etc.  So how do you balance the best of both world.

I am going to share with you how I am approaching it. 

OpenUP, AUP etc. all try to introduce bureaucracy around the Agile principles and values.  This is a direct reaction to what the industry has been clamoring for over the last couple of years.  “We need more structure around Agile before we adopt it corporately.”  My issues with these attempts at introducing structure around Agile are in that they have introduced process that promote structure at the cost of collaboration and interaction.  The fact that the word “Change controls” appear in the documentation scares the hell out of me!

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

The interaction of all stakeholders around a common goal of delivering quality working software quickly is the strength of Agile.  Anything that starts to interfere with these collaboration channels slowly degrades the Agile values.  Caution and care must be take in insuring that these values are nurtured and constantly asserted on every step through any proclaimed Agile process.

Big Bang Agile processes provide a template that is intended to guide the team through the communication channels and facilitate workflow through the release.  BUT they can easily be turned into a traditional water fall process quickly by individuals that do not understand the Manifesto and simply look at Agile as just another process ladder.

From a high level I want to propose a toolbox of Agile practices.  The toolbox will outline various processes

 

So my question is what are your thoughts on OpenUP and AUP?

RE: BDD and Requirements Traceability – Oh No, Not Again