At work, every now and then, there would be an email that goes round asking what the definition of a particular role entails, in our company. Here at ThoughtWorks, this question extends to what this role also means on projects. It’s all very well understood and defined for developers, architects, project managers alike, but what about analysts? Recently we were asked to give a definition on such a role, when someone wants to join TW as a business analyst. What do we say in answer to the question “What does an analyst do in ThoughtWorks?”
How do I describe what it is that I do? I know I could spot one when I interview one, but how to tell others what definitions or criteria you have been using? There is no obvious, prescribed way to distinguish what a TW BA “is”. There’s no rule or precise formula. Every one is different. It’s more of an art than the result of a pseudo-scientific definition… but these are the cues:
Listening skills. There are many, many roles and personalities in a typical TW team who would offer advice / opinion / comments at the drop of a hat, so an analyst sometimes needs to take a complete reverse approach, step back, and listen to what the clients are saying. This, as well as being a good note-taker (itself a major understatement) would help capture the vast amount of information throughout the project, from inception phases, to delivery, and handover. People laugh when they hear the comment “BAs need to be good note takers”, and thought that well this is a common sense thing that every one can do well in; actually, it isn’t as simple as that. Ask any team member what difference it would make if they are at the receiving end of a good set of notes vs. badly written scribbles. Then ask a team member in a distributed project what difference this would make for them.
Understanding and appreciation of technology, without having the technical know-how as a pre-requisite. BAs are here to help find ways to solve a problem, here to suggest and give educated judgement based on their previous experience and what their analytical minds tell them. We need them to take part in discovering with clients what they could achieve, and help map the road for them. BAs in principle are not there to tell you how easy or difficult it is to implement this feature this way or another. We have our brilliant developers and technical leads for that.
Ask Why, and ask again. Are they naturally inquisitive people? Do they just take information at their face value, without questioning why things are done the way it is now? We want BAs to not be order takers. IMHO it’s a soul-destroying road to nowhere and diminishes your entire existence in the project.
Last, but not least, having the raw skills of naturally being comfortable working in any domain. We do not want to hire analysts who can only flourish in one area, and wish to stick to one sector only. Particularly in TW projects, for practical reasons, we ask analysts to be as adaptable in as many domains as possible. From investment banks to trading floors, and media publishing companies to fashion houses, it should pose as no barrier that threatens a BA’s effectiveness.
Stop reading now if you think the role of Agile business analyst starts and ends at writing stories.
In a nutshell, Agile business analyst is not the same as Systems Analyst, Systems Development Analyst, Technical Analyst, and is still different to the Business Analyst you find in traditional software development thinking. But of course there is so much more than just a name and a title. As with this post in this blog, it is just the beginning. In the meantime, what do you think an Agile business analyst does?