teamwork in toronto

I've been reading and thinking on the changing role of the Business Analyst (BA), in relation to the structure of Agile teams. I've come across a number of teams reflecting on this very thing. This article reflects my own experience and also the recent discussions with and blogs by various Agile colleages.

When the customer and the team are in sync, the BA could only play a supporting role, I believe. For example, with XP, this is the situation where the Customer is happily on site and contributing. Within this model, the BA is least necessary. If all projects were like this, a BA would have to be flexible enough to play various supporting roles on the team, and let the team lead (or the team as a whole, depending on team structure) organize their interactions with the client.

However, where this ideal arrangement doesn't/can't happen, it seems there are two poles, and shades of grey in between, those two poles being:

A) the customer is very interested in the Agile approach, but not sure how to work with the team. Agile can mean big changes in their approach to requirements, design, testing. In this case, the BA acts as a coach to the customer, helping them make the transition and pitching in as a part of the customer team. This may include helping them transition existing processes into more Agile forms. The BA is essentially outside the development team, is part of the customer team as an assistant. When the BA acts as a customer (writing stories, testing, etc), they are simply providing manpower to the customer team.

Z) the customer has heard good things about Agile, believes we can bring them better value/quality for their money, but they are not interested (or allowed) to play by Agile rules. In this case, the BA probably has a dual role - as a translator, and potentially as a change agent. The translator role (called "the blocker" by Scott Ambler) runs interference between the style of the customer and the style of the team. This may mean re-creating deliverables (ex: rewriting Stories to meet some external requirements format), or proxying the client on-site. The change agent role is a more subtle one, and is simply a matter of making the virtues of Agile visible to the client, slowly over time - the objective being to reduce alienation and improve flow between the teams, not to convert the client! However, we know that the Agile approaches are seductive to those jaded by waterfall, bad RUP implementations, etc. ... so the BA, while proxying the client, should not be hiding the team's process but explaining it, showing the sense of it, in areas appropriate to the interests of the client. This is where we sometimes play the "don't tell them it's XP" game - using familiar terms to explain what we do, why we do it. The BA might need to be more prominent in communications between the team and customer - could even be the "face" of the development team, if that's what the customer requires. Whether you call the BA part of the development team or the customer team probably is a matter of semantics, and will vary depending on the customer. Scenarion Z seems the least Agile (most costly) approach, and more costly.

I'd assume that the majority of Agile projects fall somewhere between these two extremes right now. I do hear stories from across this spectrum within the Agile communities I frequent.

These variations in the customer-developer relationship seem to explain why an Agile BA needs so many hats! As a result, I've been reading on Org Patterns this year, particularly "Fearless Change" by Linda Rising. Across this spectrum, from A to Z, customer and developer teams will need to adapt, one way or the other, to work together. I figure we all benefit from learning to make change as painless as possible!

It's interesting that currently a number of shops are thinking about this subject. It comes up in discussions about testing, requirements, metrics, or politics. I've been invited to a two-day workshop in Toronto looking at "the role of testing on the Agile team" - once again, addressing these very questions. This year, I look forward to deepening my understanding of Agile requirements/testing on my path toward becoming an Agile process coach.

I would be interested to see what shape your BA solution has taken... we all need to learn from one another, in the Agile community! Please leave me a comment, so we can swap ideas!