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 appendices rather than working out how to apply the amends to the existing ones, thus defeating the whole point.
A couple of years ago I got back in touch with an ex-colleague to find out whether they were still using the ‘valuable body of collective knowledge’ I had worked so hard to create. I think I knew what the answer was going to be before they even told me. Go on, have a guess.
For the next three years I worked, as may people in the UK did, on the National Programme for IT, a huge, multi-billion pound project to deliver a 21st century IT platform for the National Health Service. We were crazy about use cases on that project. The customer wrote Business Use Cases. We wrote System Use Cases which then split down into Sub-System Use Cases. We also wrote System Architecture Documents, Sub-System Architecture Documents, Detailed Design Documents, and so on and so on. We were swimming in documentation. The length of each release was 18 months, with at least the first 6 months producing nothing but words and models.
Whilst all this was going on, I was also keeping abreast of what the various thought leaders were starting to say. In 1998, at the OT98 conference, I listened to Kent Beck describe Extreme Programming (XP). I was sceptical, as were many others, as to whether XP could work in the general case. I read Philippe Kruchten’s book on the Rational Unified Process in around 2000. This appealed more, and introduced me to incremental development within a seemingly more robust package. And of course the Agile Manifesto turned up in 2001, but people weren’t really talking about Agile in the UK mainstream until the latter half of the decade.
Then last year (2009) I had my first exposure to a truly agile project. The project team were using Scrum, having been taught it by those clever folks at ThoughtWorks. I came in as a developer, to bolster the team’s Java skills, not especially as an agile expert (I wasn’t). I’m going to write about this project in more detail in a separate article, but for now let’s just say that it was a bit of a revelation. There were problems for sure, but overall it felt like we were just getting on and doing it, and it did seem to be working. There was focus, and it was fast.
Later on in the year I was hired as a BA on a project to deliver a major upgrade to a UK eGovernment website. On the first day, I asked to meet the IT project manager, only to be told that there wasn’t one. The project sponsor had a particularly good relationship with the lead developer and in the past they had pretty much just got on and done it. “So I can run this project however I want then?” I asked. “Yep,” they said. “Oh goody!” I thought.
And so began my first experiment in being an Agile Business Analyst. Over the next few articles I’m going to tell you how it went. It didn’t go perfectly – some bits went well and other bits went less well, but that’s all part of the learning experience.
Just to whet your appetite I’ll tell you one thing. We delivered pretty much 100% of the project scope and we hit the immoveable go-live date. There is a white lie in that statement, and it sums up what (I think) agile is all about. We didn’t deliver 100% of the original scope, because, as ever, the customer changed their mind as we went along. Rather, we delivered everything they really wanted at the start (around 60% of the original scope) plus an extra 40% of things they didn’t know they wanted until after we got going!