New Beginnings

Yesterday was my last day with Manhattan Associates after over a decade.  It’s definitely weird waking up this morning and not be reading e-mails sent through the night from my Bangalore-based colleagues.

However, this change also forced me to trade in my Windows work laptop (that had evolved into a machine for personal usage) but that is a good thing.  I’m now forced to be productive on my HP laptop running Ubuntu and I’m going to use this opportunity to try and become conversant with Ubuntu and rekindle my love for Linux.  I’m looking forward to using apps like Skype and Chromium. Also, now that my personal laptop is my primary machine, I don’t plan to make my new work laptop anything else but a work laptop.  Wish me luck!


Business Analysts and Agile Development

Glenn Gillen has a quickstart on how to get Agile Development done right.  It’s a pretty good read and something I’d recommend to those who are trying to get “agile” going in there development organizations.  However, there is one quote that I really can’t agree with.  In the section, “Customers don’t write the stories” he states:

And neither do business analysts, development managers, or project managers. I’d go so far to say that if you want to be “agile” and you’ve got a team of BAs then you should fire them all. Anybody getting between the developer(s) and the customer is stopping the developer from becoming the customer.

I couldn’t disagree more with such a generalized statement.  While I concede that there are situations where the “business analyst” as a position is overkill, there are many cases where it would be flat out silly to put the developer in front of the customer for a variety of reasons such as logistics.  There have been quite a few posts on the subject and performing a search on “business analyst agile” turns up quite a bit.  However, I’d refer everyone to a Scott Ambler essay as it provides perspective on this matter that is important.

What’s important to keep in focus is that “roles” are only as valuable as that they ensure that certain activities are undertaken.  These roles are really “hats” that should be worn during the software development lifecycle.  There are instances where one individual can wear all hats but as projects increase in size and scope, there comes a point where roles need to federated.  Business Analysts eventually become responsible for making sure that new requirements are aligned with the existing business and can become the mediator between the stakeholders (including the customer) and the development team.

Agile teams need to identify who on a team performs each activities and ensure that these activities are performed correctly.  In certain cases, this may call for distinct roles such as BAs and in other cases it may not.  Just don’t rule anything out before starting.