The BA’s Role on the Agile Team

Scot Witt, Wednesday, November 14, 2007 @ 6:11 pm

Wow!

We just changed the model for our current big project, and it's no wonder I thought the BA Role was undefined.

I had been acting as an assistant-deputy-associate project manager, technical writer and QA Manager. Whatever the project needed, by gosh, was OK by me, and still is.

The side benefit is it makes it seem like I'm multi-talented, a very good thing come review time.

But now (drum roll please) there's a defined role for the BA.

Go figure.

In order to get the the base functionality up and working, the pragmatic approach worked very well.

But now, the client needs and wants control of the features, enhancements and repairs for the system to meet the business needs. Right up our alley.

We're moving from month-long sprints into two week sprints.

Sooooo, the first week into the current sprint, the IA and I discuss the requirements with the client for those items likely to be included in the next Sprint. We write 'em up and we frame the wires and get verbal client sign off that first week.

If it's a biggie, I'll slap a functional spec together with the IA's wire frames and work flow requirements.

If it's small, I set it in the issue tracker as an improvement with th details in the description field (I always wondered what that field was used for).

If the developers need more detail or discussions with users, I act as a liaison to get that happening without the client getting barraged by hundreds of IMs and e-mails.

I think I'm going to wish I was issued a stick.

But I gotta make that happen for the DevTeam, otherwise we can't produce what the customer wants.

The second week, I run the requirements by the DevTeam Lead for a sanity test. I'll probably flunk, but better to revise and have items really ready for the Planning Session on the second Friday.

I post the client's wish list in the wiki (can't get away from that dang tool, can I?) by Wednesday of the week before the sprint start.

It says here in The Handy Dandy Agile Methodology Handbook for the Perplexed that the developers have to read them!

In the SPrint Planning/Negotiating/Teeth-Gnashing Meeting on the Friday before the next sprint starts, the Customer ranks the items s/he wants in the sprint.

The DevTeam then huddles, makes interesting noises and then sets team estimates  (kinda like liar's poker when you watch it) and commits to a list it can handle.

Me and the PM then negotiate with the Customer to come up with a final list.

We break for coffee and a smoke and then go through a Post Mortum of the sprint just ended.

Here, everyone has to talk and discuss process (not people or finger pointing- as much fun as that might be)- including the customer and his/her team. Fair's fair, right?

If an item's actionable, the PM and I will meet with the appropriate lead and figure out some mitigation strategies or process change.

Then we're off to the races for the next round.

So, the BA's role in an Agile Project isn't all that different from other methodologies.

While 'control' of the project is now in the customer's hands, defining requirements and disseminating them differs only in that we're doing 'just enough' rather than 'kill hundreds of acres of trees with Word.'

Since the developers and the customers aren't running everything through the BA or IA (typical waterfall), we loose the 'translator effect' that intrudes every time technicalese is translated to rich bidness language and vice versa.

Even so, the BA is there to help both sides meet and mesh an understanding both sides can live with and understand.

The complexity is increased with an IA on board, but that complexity is more than offset by the IA handling project foundation work like 'task flow' (work flow to us BA-types) and they can whip up wire frames faster and prettier than I can. Those benefits combined with actual design to make the end user's job easier and more intuitive is well worth the the minor complexity issue.

With that big stick, I think I want a regulation Referee's Shirt as well.

<ding> <ding>

Next Round

Powered by ScribeFire.

tech development

Comments

• Leave a comment
• Comment feed for this post
• TrackBack URL

None so far.

Leave a comment