Business Analyst to Agile Team Member – the beginning

I’m rocking this BA gig!

Some time in the past: So I’ve been a BA for a couple of years now, I’ve got my head around all the different types of specifications we write for different types of features. We’re talking documents where the basic template (with no information filled in) runs to 15-20 pages. I’ve learnt to add every piece of information possibly relevant into the document, because otherwise, the developers and testers will tear it apart at the walk-through. So in other words, I’m doing a stellar job as a BA and I have been encouraged and rewarded for this at suitable moments by the company I work for.

Side note: Yeah I can say with hindsight (20/20, yo!) that what was adjudged a stellar job for a BA in that workplace is so far away to the standard I have in mind today. And it makes me weep when I see BAs doing all those things I used to, when I didn’t know any better.

We’re going to be adopting “Agile”

Picture this: The room is full of staff that have ‘gathered around’ on the development floor. An announcement is imminent if not highly anticipated – we’re going to be restructuring development (yes, again). And yes, the anticipated restructure is indeed happening, but this time, there is a new flavour in the mix, and it’s called AGILE.

Everyone rushes back to their desks and starts searching. I’d say googling, but this was a while ago, we could have been Yahoo!ing for all I recall. The overwhelming result seems to be one exemplified by the classic Dilbert strip.

Dilbert Agile

Obviously, management had decided that we were no longer panicking enough when restructures were announced, and they had to really up their game.

Actually, you don’t fit in

Okay, confession time: I love change. I embrace change heartily, and even my self-involved narcissist had realised that restructure after restructure meant that management was trying to fix a problem, even if I didn’t know what the problem was. So of course I was jumping up and down in glee, and delighting in the information that we’d be learning lots of new stuff and trying new processes. Then I made the mistake of trying to figure out how I could be a kick-ass BA in the Agile world. Boy, was I in for a shock.

Apparently, there was no such thing as a BA in Agile or SCRUM.

There was article after article in the Agile realm that made it clear that the BA role was overrated, and would be shared by Product Owners and developers in the new Agile world. No documentation was needed, the team shared all the analysis tasks and no detailed upfront analysis was even required before starting stories.

You need to do analysis, but that doesn’t imply that you need analysts.

Well, I guess I was stuffed! I was the youngest and most inexperienced BA in the team – no where near PO material. And as for being developer material…. (unending chorus of laughter).

Suffice to say, a couple of days of reading over the weekend left me neither enthused about the change, nor particularly clear about what the changes would actually mean, and suddenly I was wondering if change was always something to be excited about.

Update:

It all worked out in the end. I made the transition, and I am LOVING the Agile/ SCRUM frameworks. I wrote a bit about the difference in the roles here: http://agileaustraliablog.com/2015/07/10/what-an-agile-ba-must-do-differently-to-succeed-with-guest-blogger-tasneem-gould/

 

What does a BA do?

Definition

If you look for the definition of a Business Analyst, you’ll come away with lots of words in your head. If you come away with a clear understanding of what a BA does, you’re far cleverer than I am – reading some of these definitions left (the non-BA) me none the wiser. The established authority in this field, the IIBA, describes the role as “a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.”

It’s ironic that for a profession that is supposed to be the beacon for clear and concise communication finds it so hard to explain in simple language what it does. And let’s face it, I’m not going to tread where loads of experts have gone before. Let’s face it, once you have a few years under your belt, you’ll not only understand these definitions, you’ll probably think they’re pretty good.

But what I could do is lay out what I do as a BA and that could be a starting point if the context makes sense to you.

Context:

I’ve only ever worked as a BA in companies that develop and implement software. I can tell you what I did as a typical BA in a development or implementation team does in these companies. However, not all companies are the same, not all teams do the same things, and no two BAs work exactly alike – so you’ll need to find your own flavour of BA for your own special set of circumstances.

What I do as a BA

If you’re reading about BA stuff, you’ve probably encountered the ‘five Ws‘ and ‘five whys‘ already. If you’re doing BA type work in any capacity, you’ll know that people always tell you WHAT first, not WHY – even though the latter is what you actually need to know first. So lets do the BA thing and start with the WHY, not the WHAT or HOW.

Why: My team needs to build the right thing, so that we can maximize our value to our business, and minimize the work not done.

The company that you work for has a product or solution that needs to satisfy a business need of current and future customers. Your team is employed to build or implement something that increases the business value of the product or solution, usually within a set of time constraints. According to the iron triangle, you have budgeted resources (your team), you have a schedule (the next release date, or project completion date), and you have the scope of the work for the project.

Because your budget and schedule are (generally) inflexible, the only variable is scope. It is absolutely essential to the success of the product or project that this scope is well managed.

– If you try to do too much with the allocated time and resources, you won’t finish in time.

– If you don’t do enough to satisfy the business value of the product, or the business needs of customers, your work is wasted.

Which brings us to:

What: The BA needs to find that delicate balance between what will satisfy the business needs of the customers whilst being careful to ensure that time or budget isn’t wasted building ‘extras’ that aren’t essential to the success of the product.

It’s that easy. Sounds simple, doesn’t it? It actually is. You’ll just need to figure out exactly what you are building… and why.

Starting out

A complete shock

10 years ago, something ridiculous happened to me. I found out I was pregnant.

At this point, I’d been with my partner for 2 years, we were planning a wedding, but essentially living the party lifestyle. We both had jobs, a wide circle of friends and an active an varied life that just happened to involve lots of parties and catch-ups and barbecues. We were certainly not planning to have a baby, especially RIGHT NOW, and were a bit traumatized at the situation.

A changed life

To cut a long story short, having our son was the best thing we could have ever done. Having a baby forced us to do things wayyyy differently than we had planned.

Zain born

– We decided to get married right away rather than wait the year we had originally planned. We brought the date forward 6 months, booked the first venue we found (in the city that his parents lived in) and had a amazing, no-time-to-stress wedding.

– We decided to move to the city we got married in because we wanted to buy a house and have a family orientated lifestyle, which was a LOT harder in the huge city we were living in at the time

– David had to retrain in a different field because there was NO WORK AT ALL in his industry. His years of experience at being an awesome sound engineer in the best studio in the country didn’t count at all.

– I gave up my awesome job and prepared to be an at-home mom for the first year or 2 of our son’s life. That only lasted 6 months – when he turned 8 months, I went to work in yet another role in software support – something I had done for the last 7 years in various capacities.

Some of this was good, and some of it was not so good, but the sum total of all these changes meant that we went mentally from being good-time party animals to responsible parents in just over a year. And THAT was an amazing thing to happen.

IMG_0891

Learning to be a responsible adult

When I started work again, I resolved to focus on my work and career rather than treat it as a necessary evil that paid for my social life. I started actively figuring out how I could be a better employee, and what I needed if wanted to move to the next rung of the ladder. I researched tools and techniques and courses, and read stuff online. And incredibly, I struck lucky. Within a few months, I moved from my entry level position to a team leadish role.

But I wanted more. Now that I was reading stuff and learning new concepts and ideas, I wanted to do more. I put a little bit of thought into what someone with my skills and interests (and technical limitations!) could do. And at some point I decided – I’d make a kick-ass BA.

What I thought makes a good BA

– Knowing a little about the domain

– Knowing a little more about how our customers use the product

– Knowing a lot about the product

I’ll talk about how that  worked out for me in a future post. Right now, I want to talk a bit more about what I did next.

How I got into the BA role

I was lucky to work in a company where there were loads of opportunities for staff to mingle, like end of month drinks or staff starting & leaving morning teas. I used this time to chat to people who were BAs to figure out what each of them did, what they liked about their role and what they thought would be useful skills for a new BA to have. I talked to the BA and development managers to understand what they would expect a BA to do and what they would look for if they were hiring someone for the role.

I went online and looked at similar jobs, and found books at the library that might help. This was a while ago and there weren’t quite as many resources online as there are today, and to be honest I didn’t have enough context or knowledge to fully understand a lot of what I was reading.

Once I was confident enough that I was a decent match for some of this stuff, I made sure I expressed my interest in learning to be a BA to people in the area. I got a few tips on what to do next, and made sure I followed up on these.

– I started reading legislation and policy documents relevant to our domain which was a key component of the role.

– I learned how to do BPMN and workflow diagrams.

– As our BAs started working on requirements for new features, I volunteered to be the customer / support liaison to help them figure out which customers were stakeholders and what current processes looked like.

– I offered to review requirements documents from a support perspective – which helped me learn heaps about how to write requirements. I was extra lucky because there were four BAs in the team with different styles, so I had different styles and perspectives  to learn from.

TL;DR – I learned what people wanted from the BA role, tried to learn those skills and made it visible that I was trying.

IT PAID OFF!

I’d done a decent amount of groundwork, and I was lucky that a BA role came up internally. I applied so fast for the role, I probably broke the sound barrier. But another essential part of the process was buy-in from my manager and the heads of the 2 different areas, because internal moves mean figuring out back-filling roles. I was so lucky to have enormous support from everyone involved, including being able to start the BA role part time for the first couple of months.

Another thing to consider was salary. A junior BA role didn’t pay much more than a senior support role, and perhaps even less once you included performance bonuses. This one took a little negotiation and long term thinking, but it was sooo worth it for me. I do wonder what the situation would have been like if I’d been a developer moving sideways though – probably a lot harder.

Finally, I was super, super lucky to work for a company that believed in retaining and promoting staff internally. This is probably the single most important factor that allowed me to make the role change. So if this is a change you are intending to make, this is probably the first thing you want to think about when you are starting out!

Zain at Xmas