Hi there. My name is Tony. I live in Leeds, England and I’m an Agile Business Analyst.Oh dear, that sounds more like a confession at an Alcoholics Anonymous meeting than my first ever online article. It’s also not true and, so some people say, an oxymoron.

Actually, what I really am is a regular Business Analyst who has recently been experimenting with some agile practices and has a few experiences to share.

To put the story in context it’s worth giving you a bit of history.

I started my professional IT career in 1997. I started out as a developer and then moved on to architecture. At that time, of course, object orientation was all the rage and UML had just arrived on the scene, so we all spent a lot of time arguing about which were the best CASE tools to use, whether the various classes on our diagrams were aggregated or associated, and how on earth to use ‘extends’ in a use case model.

In around 2003 I took a contract as an architect at a UK utility company. The project stalled and I filled in my spare time helping out on another project where they needed a Functional Specification writing. I hadn’t really done any business analysis before and it turned out to be trickier than I expected. That is, until I stumbled across a copy of ‘Writing Effective Use Cases’ by Alistair Cockburn. This is, in my opinion, the best book ever on the subject – the man is a god, a saint, whatever, albeit with occasionally strange hair .

I spent the next couple of years perfecting my technique. By the end of it I had a standard template for a Functional Specification, based on use cases, which was rolled out across the organisation. I was especially pleased with the way I had got everyone updating the existing document suite in each new project, with changes clearly marked up, and thus building up a cumulative picture of the functionality of each application, and a really valuable body of collective knowledge for the organisation.

I was pretty sure I had got this BA lark nailed.

But I did have some nagging doubts:

Doubt Number One: the business didn’t read them. Well, they did, when I insisted on a sign-off, but they clearly didn’t want to. If they really wanted to know how something worked, they would come and ask me or one of the developers.

Doubt Number Two: the developers didn’t read them. Well, they did, during the project when they really needed to know what to code, but if they wanted to know how the system worked at some later date – you guessed it – they looked at the code.

Doubt Number Three: the whole cumulative document idea was really clever, but it was actually quite tricky to get right. Sometimes, fellow BAs would write separate use cases or ... Lire la suite de l'article