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!
Pingback: Tweets that mention How I became an agile business analyst -- Topsy.com
Tony,
Look forward to hearing the rest of your story.
cheers,
Mark
Tony: thanks for sharing your story; i really appreciate you making the time to write this and in such an engaging style 😉
fyi: here’s the oxymoron original post that chris matts referenced (in your first link):
http://ebgconsulting.com/blog/agile-requirements-not-an-oxymoron/
(and more info on agile analysis in numerous articles on our site i hope you and interested agile analysts (and agile-to-be-analysts) might find useful: http://ebgconsulting.com/articles.php#agile
look forward to the next post!
all the best,
~ ellen
Ellen Gottesdiener
http://www.ebgconsulting.com
Much like the Agile Project Manager, the Agile Business Analyst will rely much more on people facilitation skills than they may have on traditional projects. The BA’s role is to facilitate a discussion between the product owner and the technical team. The BA will typically bring a tremendous amount of system knowledge to the discussion and is
well positioned to draw out functional requirements from the product owner. BAs can also help translate user needs into more technical language for the developers.
In addition to facilitation, coaching, and team building, the agile BA needs to think about the software development process in new ways. Agile encourages us to decouple the breadth of the solution from the depth of the solution in order to continuously deliver smaller increments of production-ready code.
Hi Anurag,
Thanks for your comment.
I completely agree that people facilitation skills are critical to the Agile BA. In fact I think they have always been critical to the BA role, even before the advent of agile – in my experience, 80% of the job is (and has always been) working with stakeholders to elicit a design for a solution to a business problem.
You talk about the Agile BA facilitating between the product owner and the technical team. It depends what you mean by “product owner” – if you mean “stakeholder or stakeholders” then, yes I agree. But if you mean a Product Owner as per the Scrum definition, then I’m not so sure.
However, I’m not convinced that there’s room for a BA as well as a (Scrum-style) Product Owner on an agile project. My own experience recently is that the BA *is* the Product Owner, or at least the Product Owner role is the closest thing to a BA role that there is. I should say that I’m talking here about a Product Owner role as described in Scrum
I know that in theory you’re supposed to draw a Product Owner from the business – so that you have a “real” user calling all the shots. But in my experience, most of what the Product Owner does is analysis work, and in my experience (a) business people aren’t very good at analysis and (b) they don’t really want to do analysis. Otherwise they would be analysts, not business people!
Your articles about the BA in an Agile environment are very useful.
Regarding “BA *is* the Product Owner”, I am in a similar situation right now. The problem is that usually a BA does not have a mandate from a Stakeholder.
So what is your advice for an underpowered ‘proxy Product Owner’ and BA?
Thanks!
@ Madalina –
I suppose the point about empowerment is that it gives you (the BA/Product Owner) the ability to make decisions quickly, which is important in order to keep the developers productive and not waiting on answers.
On the project mentioned above, I handled it like this:
– If the query was a simple or minor matter (and I was confident on what answer the stakeholder would give) I would make the decision myself immediately. I would note down the decision/clarification in the FS and mark it as requiring stakeholder approval. I would go through all the minor clarifications at the next (twice weekly) stakeholder workshop.
– if the query was more complicated and needed discussion with the stakeholder, I would speak to the stakeholder first ASAP (they were generally available for a quick chat at short notice) and then get back to the developer.
My ability to guess the stakeholders’ answers relied very much on the close working relationship I had with them. For example, I was located physically within the stakeholder’s team (not within the dev team). Being close to the stakeholder was probably of more benefit than being close to the dev team in this instance.
Hope that helps.