Welcome to Mastering Business Analysis Episode 47, The DNA of a Great Agile Business Analyst.

Here we go.

Welcome to Mastering Business Analysis, where we bring you the tips, tools, and techniques to succeed
in your career as a business analyst.

Now here's your host, Dave Sabo.

In today's episode, I'm going to share with you an excerpt from a presentation I did a week ago at
Business Analyst World Chicago.

The presentation was entitled, The DNA of a Great Agile Business Analyst.

Agile is more than a way of delivering a product to customers faster. It's a mindset, a philosophy based on
a set of values and principles. The best business analysts in agile environments have several key
characteristics in common that allow them to bring value to their teams and organizations.

In today's episode, we'll explore the elements that make up the DNA of a great agile business analyst,
help you to understand the impact of having or not having those traits, and find out what you can do if you
or other team members don't have these traits as part of your DNA.

My original presentation had a lot of interactive elements, which unfortunately I can't do on this podcast,
so I'm only including a portion of the presentation.

I've also included a video so you can see the slides that I used in the presentation, so I highly recommend
you go to masteringbusinessanalysis.com slash episode 47 to watch the video.

And now here we go.

The DNA of a Great Agile Business Analyst.

Today we're going to talk about the mindset and key traits you need to become a great agile business
analyst.

We'll talk about how combinations of the traits allow you to bring more value to your team and your
organization, and find out what you can do if you don't have these characteristics as part of your DNA.

Let's start by taking a look at the DNA of a traditional waterfall business analyst.

We see how key characteristics come together to form behaviors that drive great business analysis.
Things like being a great communicator, and being detail oriented.

Systems thinking and curiosity.

Someone who values output, and sees requirements as something to be discovered.

Not gathering requirements, but discovering requirements and then someone who has a lot of confidence.

They create trust with their stakeholders and subject matter experts and they even have a little bit of
perfectionism in them.

Now while these traits create someone who's great at business analysis and a waterfall

environment, some of these traits are also at odds with the agile principles.

Let's take a look at the Agile Manifesto.

We're uncovering better ways of developing software by doing it and helping others to

do it.

Through this work, we've come to value individuals and interactions over processes and tools.

Well waterfall business analysts are all about processes and tools.

Working software over comprehensive documentation.

Comprehensive documentation is what we do.

Software collaboration over contract negotiation.

We need to know the details of the contract and negotiate it, because we have a big design

up front.

Responding to change over following a plan.

We spent all this time creating a plan and trying to control change, we shouldn't have

to respond to change.

Why don't we look at some of the principles of the Agile Manifesto.

We welcome changing requirements, even late in development.

We don't welcome changing requirements in waterfall.

Change is something to be controlled and managed.

Deliver working software frequently, from a couple of weeks to a couple of months, with

a preference to the shorter time scale.

It takes me a couple of months just to create the requirements, how can we deliver working

software in that time frame?

Business people and developers must work together daily throughout the project.

Have you ever seen business people and developers try and work together?

They don't speak the same language.

Working software is the primary measure of progress.

I think that 100 page requirements document I created is a good measure of progress.

The best architectures, requirements and designs emerge from self-organizing teams.

How could they emerge if they don't have a business analyst on them?

But a funny thing happens.

For those individuals who truly embrace Agile, something happens in their minds and bodies.

A metamorphosis takes place.

A mindset shift.

A mutation.

Something that allows them to really embrace those Agile principles.

Let's look at the mindset shift.

If we peer inside the mind of a waterfall business analyst, we see that they value documentation.

They view change as something to be managed and controlled.

At the top of their mind, they focus on customer needs.

They're able to separate needs from wants and really deliver those needs.

Through that, they create a big design up front so that we see the big picture and know

everything that needs to change.

And of course, I do my job and I do it well.

And at my core, I analyze everything.

I understand what the impacts are.

I understand the why behind everything.

And that's great in waterfall.

But as we move to Agile, there's a shift that needs to take place.

If we peer inside the mind of an Agile business analyst, we see something a little bit different.

Instead of focusing on documentation, we know that conversations matter.

In Agile, we focus on lightweight documentation.

So conversations and collaboration become much more important.

We don't view change as something to be managed.

We expect change and even embrace change.

At the top of our minds is customer value.

Instead of focusing on needs and wants, we focus on what's valuable to our customers.

And that might change.

And because of that, we do just enough, just in time.

Because we have lightweight documentation, have conversations, and expect change, we

do just enough, just in time.

If we did a big design up front, a lot of that would go to waste because it would change

over time.

We also focus on fungibility.

And fungibility is mutually exchangeable.

So we can develop our skills so that we can go and help out the tester.

We can help out the developer.

We can help out the product owner.

We might not be able to test as well as a tester, but we've adapted our skills so that

we can jump into that role and help out when needed.

And of course, at our core, instead of focusing on analysis, we focus on action.

We do just enough so that we can get something out in the market, get feedback, analyze the

results, and again, take action.

We always have a bias towards action.

Now let's peer inside the DNA of an Agile business analyst.

We see that different base pairs come together.

We have visionary combined with collaborative, value-driven combined with emergence, teamwork

combines with learner, and openness combines with vulnerability.

Now when these base pairs combine, we see different behaviors emerge.
When visionary combines with collaborative, we get someone who's a storyteller, someone

who can create a compelling vision and then collaborate with the team to develop an appropriate

solution.

When value-driven combines with emergence, we get someone who's adaptive.

We understand the customer value, and we also understand that details will emerge as we

take action and get feedback.

So we become adaptive, someone who can easily adapt to change.

When teamwork combines with learner, we get someone who's fungible.

As I mentioned before, someone who develops their skills so that they can help the specific

roles on their team.

And when openness combines with vulnerability, we get someone who's transparent.

And transparency is a key to understanding what's going on within your team and constantly

improving.

So again, an Agile business analyst who's someone who communicates as a storyteller.

They're able to create and share a compelling vision.

In their mind, they're adaptable.

They're comfortable with ambiguity, and they know that things will change.

They behave as someone who is fungible.

They develop their skills and help out the team wherever they're needed.

And at their heart, they're transparent.

So let's look at some of the headaches or pain points that might occur if you don't
have some of these traits as part of your DNA.

If we look at the behaviors of storyteller, adaptive, fungible, and transparent, all are

critical to a successful Agile team.

Let's look at each one.

For storyteller, that's a combination of visionary and collaborative.

If we have someone who has a visionary trait, without the collaborative trait, we have someone

who's command and control.

We tell the team to build X, and the team will build X.

Problem is, X might not be the right solution.

If we have someone who's collaborative without the visionary piece, the team collaborates,

but they might never achieve that specific vision.

You need both to become a storyteller.

If we look at adaptive, we see that's a combination of value-driven and emergence.

If we have the value-driven trait without the emergence trait, we get big design up

front.

If we have emergence without value-driven, we have a lot of ambiguity.

The team will be busy producing things, but it might not be the right things.

You need both to be adaptive and work on the right things at the right time.

If we look at being fungible, that's a combination of teamwork and learner.

Now a lot of Waterfall BAs have the trait of teamwork, but without the learner piece,

they're limited in how they can benefit the team.

If you have someone with a learner trait without teamwork, they're developing their own skills,

but they're not applying what they've learned to help out the team.

You can't be fungible with that.

And finally, transparency.

Transparent is a combination of openness and vulnerability.

If you're open without the vulnerability piece, you get someone who's defensive.

They get feedback, and because that perfectionism creeps in, they get defensive.

If you have vulnerability without the openness piece, you get fear.

Someone who is vulnerable without embracing openness becomes very fearful, fearful of

what other people will think.

You need both openness and vulnerability to become transparent and continuously inspect,

adapt, and improve.

So what can we do if we don't have some of these key traits as part of our DNA?

If we're missing the visionary or value piece, we can pair with the product owner.

Understand what the vision is.

What's the roadmap look like?

What are we working towards?

And what's valuable to the customer?

If the product owner doesn't have those traits, you can work with other leaders or even get

as close as you can to the customers to understand what's their vision?

What do they hold valuable?

What about learner, openness, teamwork, collaboration, those types of things?

Pair with the team.

Be open to learning new things.

Work with your team members.

Help them to understand why you want to pair with them, why you want to learn their roles,

and develop your skills so that you can help them going forward.

Now what about vulnerability and emergence?

This is probably the hardest pill to swallow.

If you're light on vulnerability and emergence, you have to learn to let go.

Lose some of that perfectionism.

Create a safe zone, a safe environment where you're able to be vulnerable and you get comfortable

with some of that ambiguity.

So again, if we look at an agile business analyst, we see someone who communicates as

a storyteller so that they can communicate a compelling vision and collaborate with the

team to find an appropriate solution.

Someone who's adaptable, open to feedback, knows that details will emerge and we can

inspect and adapt and change going forward.

Someone who's fungible, someone who learns new things and applies those new learnings

to help out the team.

And at their heart, there's someone who's transparent because the only way to inspect

and adapt and continuously improve on the team is through transparency.

So again, we've looked at the mindset shift that needs to take place and the key traits

to become a great business analyst.

We looked at how we have to move away from documentation to conversations, from big design

up front to just enough just in time, from analysis to action.

We've also seen how combinations of those traits allow you to bring more value to your

team, become a storyteller, be more adaptive, become transparent and fungible so that you

can help your team.

And we've also talked about some approaches that you can take if you don't have some of

those characteristics as part of your DNA, pairing with the right people and learning

to let go of some of that perfectionist that made you successful in a waterfall environment.

Thanks for listening.

I hope you enjoyed that episode.

As I mentioned earlier, you can see a video that goes along with this presentation by

going to MasteringBusinessAnalysis.com slash episode 47.

Finally today, I'll leave you with a quote and this quote is from James Cameron.

Luck is not a factor.

Hope is not a strategy.

Fear is not an option.

As always, if you have a guest suggestion or topic you'd like to hear on a future episode,

you can send me an email and you can send that to podcast at MasteringBusinessAnalysis.com.

I'd love to hear from you.

I want to make sure each episode includes information that's important to you and helps

you along your journey towards Mastering Business Analysis.