Attended Agile session

Today, I attended excellent Agile session conducted by NCR Agile User Group (NAUG). It was well received and lot of good discussion happened around Scrum & XP.

There were people from different companies. They are using different processes and methodologies in their respective projects. It was nice experince to listen different views.

Few discussion points were
Pair programming - It was hard to convince about Pair Programming productivity. Pair programming creates impression of more effort in comparison to traditional way of software development. It is true if one consider only a single sprint. But it would not hold true for complete project lifecycle. It reduces effort due to better quality output of pair programming.

Duration of Sprint - Good discussion happened on duration of Sprint. Scrum recommends almost fixed 4 weeks sprints with daily scrum meeting.

Rework or Refactor - A new name to rework in Agile is refactor. Is it possible to avoid this in traditional methodology? Refactor is going to survive and will promote Test Driven Development along with it.

One of major practice of Agile methodology is continuous feedback from Customer. It may be difficult to find customer who wants to work in such close collaboration mode as required by Agile.

Who makes more MONEY in IT - Manager OR Architect ?

Architect dont talk about Money ;) They are saints who dont care about it.

Let's discuss about the common IT employee. He works for multiple reasons like fun, interest, satisfaction, no other choice, family, company, status, habbit, money etc. Now he has a choice to select management or technical ladder. One ladder takes to Manager role and other to Architect role. Both need management and leadership qualities. Out of multiple reasons, Money was one. Now question before IT employee is - Who makes more Money ?

I would love to know what we feel/experience across IT world.

Embracing Agilism

My view on How come Enterprise Architects don't embrace agilism?

Two ways to adopt the change in corporate world, bottom up or top down. Bottom up approach means someone unknown in enterprise adopt a new tactics to improve the conventional procedure. It is adopted by small project and benefits are published at enterprise level. In this case, change is accepted slowly or sometimes never.

Secondly, in top down approach, management decide to change the things for better and publish new guidelines to be followed by corporate. Change is easily accepted in this approach. But no one in top wants to take risk which comes packaged with change.

In both the approach one needs a leadership quality to spread the benefits of change. Take a case of Agile methodology, its like a change.

Agile is gaining momentum. Corporate are trying its best practices like Test Driven Development etc. Mostly, its happening through bottom up approach. A slow approach. It is not easy to change the whole process in one go. Big Enterprises are embracing agilism in bits and pieces to find the benefits.

First impression of SOA on Business user

Is Business user ready to accept delay in response? Is it matter to Business user whether the services consumed runs on old legacy architecture or hyped SOA architecture? What all matters to Business user is usability? Any upgradation in technology should improve the functionality and quality attributes. First step towards SOA impacts performance. Decoupling of components/services with help of XML creates overhead in terms of XML processing, transformation and routing of messages. All these steps eats up significant processing time of request.

First step towards SOA doesn't create positive impression on business user. It becomes difficult to sell SOA to business stakeholders. Short term hurdles stops adoption of long term benefits of SOA.

SOA looks quite similar to Remote Entity bean concept in EJB 1.0. Conceptually, both are suitable for ideal scenarios. They attract purist who wants to follow the architect principles without business value. One may say Entity beans were fine grained domain objects and SOA are business services. Session beans orchestrate entity beans, similarly BPM orchestrate business services. Does any thing like local interfaces concept will emerge in SOA world?

SOA makes sense in case of B2B and services which are exposed to external clients. But within scope of Enterprise, do we want to consume slow business services. Its a call between performance vs flexibility. Lets see who wins or we are able to find the win win situation in time.

Long term vision vs Short term goal

Sometimes, there exists a conflict between Long term vision and short term goal. To achieve short term goal, project team compromises with Long term vision of product/program. It looks most practical to divert from the correct path and take short cut to deliver.

Occasionally, project team wants to ignore the long term vision in order to mitigate the impact on short term goal. Project Management and Business requires solutions as early as possible. Over here, it becomes responsibility of architecture team to explain , convince, mentor, motivate, communicate, enforce and sell the correct path and produce standards & guidelines for the benefits of project in long term. It helps stakeholders to take informed decision.

A mature and motivated IT team keeps moving on correct path to achieve the Long term vision. IT team always needs support from the management and business stakeholders. Does this holds true for Enterprise SOA ?