.comment-link {margin-left:.6em;}

Tuesday, March 07, 2006

 

Thoughts on Process and Expectations

I wanted to add my commentary to Scott Mark's excellent post about Agile in enterprises. I have participated and managed a few agile projects in the last few years and am sold on the concepts (as I am other methodologies) but retain my agnosticism as I strongly prefer to use different processes and methodologies as the situation dicates, and not dogmatically (which usually invites trouble in most cases).

The overall problems appear to me as attempts to strike a balance between results, process, and the expectations of users & the business. This balance is so tough to strike that few will truly succeed 100% in satisfiying all stakeholders, particularly on large projects.

Here are a few examples of perceptions/statements/mantras we all have been exposed to whether on-the-job or in publications and blogs:

I offer these as examples of statements and aspirations that compete with each other negatively in terms of overall business-technology approach and balance. The conundrum here is if we over-specify, over-document, or over-process (and that depends largely on which perception of 'over-' is being utilized), we take too long and are too spendy for the value received by the business. If we cut out too much, we run the risk of deploying systems marginally supportable that will need to be refactored (or in extreme cases, ditched and redone) because the inevitable changes to the system cost more than anticipated in time and money. This also lowers the value received.

What further muddies the water here is SOA itself. We're finding out that comprehensive SOAs are not built quickly and cheaply, and definitely not quick or inexpensive enough to satisfy urgent business needs. Well-built SOAs will pay back much more than they cost - eventually, and not fast enough to satisfy some parts of the business.

Finally, we get to the question of "value" of any process, activity, or sets of these. The question behind this is 'value to whom?' Business agility is one thing, IT agility is another, and overall costs to develop, deploy, and support are yet another. What kind of balance are we looking for here, and can we achieve some sort of consensus on this with the stakeholders?

I realize I'm asking a few more questions in this post than I'm answering, and much more thought and dialog is required. Scott and Cote' have begun a very interesting topic...much more to follow.



Comments:
Agility can be stimulated by getting folks to pay attention to the right analysts. Scott has had conversations with Cote and so have I. The ability to learn from others is key.
 
Robert - great questions... your thoughts here remind me of James' previous posts on tension. Asking great questions is better than providing mediocre answers. There also are not usually absolute answers - but best answers for a context.
 
Post a Comment



<< Home
Technology Blog Top Sites |

This page is powered by Blogger. Isn't yours?

Weblog Commenting and Trackback by HaloScan.com