How Agile Helped a Business Analyst Discover Her True Value: An Interview with Diane Zajac-Woodie


Diane Zajac-Woodie: Well, I really like your reference to the cylinders because I frequently compare BAs to the oil in an engine. We keep everything running smoothly and it's simply because of the skills that we bring, usually aren't present on a team. If a project were actually succeeding, I'm going to assume, that the team has all the skills that they need to deliver well. If I wouldn't make sense to add any role, you could say that about should be out of tester, if they're successful, if they have all the skills then you wouldn't need to add another role.

I don't think that situation is very common, especially as far as BAs go. Every role has this primary focus, a developer. A developer can have obviously, they can have excellent facilitation skills, that's not what I'm saying. But if there's some debate about a technical decision, her facilitation skills are going to take a back seat to her concern, about that technical solutions. She's not going to be at the forefront, she's not going to be thinking, "I want to make sure I hear what everyone has to say." She's going to be making a case for whatever it is, that her position might be.

A BA is almost neutral as a good facilitator, you can step back and just your whole focus is on communicating and sharing ideas. That’s where I think the benefit can be on any team, whether you are successful or not.

Cameron Philipp-Edmonds: I really love the quote that you said right there, that the business analyst role is kind of the oil to the Agile engine, that's phenomenal. Thank you for that. You make the argument that BAs can encourage team member to cross role boundaries. Why are they good leaders for this transition and role exploration?

Diane Zajac-Woodie: I think mostly because BAs are naturally curious. We ask all sort of question obviously, we want to know how things work, and why we're doing things. Generally speaking, BAs tend to be extroverts. We find it easy to approach people with questions which can just naturally lead to sitting together, working on a problem together. If we can make this feel safe, and productive to everyone else on the team, then other people can follow our example.

That's been my experience of how I have sort of lead that.

Cameron Philipp-Edmonds: Okay, and now I have some more general questions, obviously about your presentation kind about you as a person. You're a huge proponent, of asking questions. Why is that?

Diane Zajac-Woodie: Mostly because, silence just doesn't get us anywhere. Everyone knows something that I don't know, and the only way to find that out is to ask. I know that we're on more time constraints, and most of our projects are, most of us work under deadline. It's easy to just go with the first viable solution. But taking those few extra minutes to explore options, can really help us to get better solutions in the long run.

This does involve a little bit of courage, because you have to be able to admit that you don't know something, it requires us to be a little vulnerable with our team members which I suppose could even help you to be a better team if you can expose some of that. But it also let people know that you care about what they think. It helps build those relationships as you're asking people what they think about something and of course all of this just assumes that you're actually going to listen to what people say, which is definitely a key component to that.

Cameron Philipp-Edmonds: Okay, a lot of times, there are questions that don't get asked, that really should be ask with every project, or if most projects that often get left unsaid.

Diane Zajac-Woodie: Sure, there's definitely a few we could get better at. Namely how we will know if we're successful. So frequently that is left off, of projects that I've been on. We're getting better at defining a problem that we're trying to solve, which is stepping in the right direction. Knowing one will be successful, and really if you're delivering incrementally, I think it's important to define when should we stop.

What is enough, because if you have already achieved the objective, you need be able to stop and go, "Okay, we've done enough on that. Let's turn our attention elsewhere." On the flip side if we're not achieving the objective, how much time do we want to keep going down that path, before we want to pivot, evaluate our approach. Those questions could really help us, to make sure that we're building the right product, that's the goal of all of this.

Cameron Philipp-Edmonds: Okay, you've spent several years, trying to redefine, the perception of a BA from requirements dictator to a project and transition facilitator. What led you to try and make this movement happen?

Diane Zajac-Woodie: I think the more I spoke with people in the community, I would hear stories about BAs who cared more about preventing changes to their requirement spreadsheets than about adapting so we could really figure out the best solutions. I understand where that resistance is coming from. The sooner that we accept that, we can't possibly know all the performance at the start, and that they're always going to change, the sooner we can move on, to really providing the best value for our business sponsors.

That, I want to go against that stereotype, I want to redefine what people think of as BAs.

Cameron Philipp-Edmonds: Okay, and you also have a blog, and has a great title AgileSquirrel. Can you tell us a little bit about that?

Diane Zajac-Woodie: Sure, when I was on my first team, it was around the time that the movie "Up" was released. In that movie there's a dog who can talk, as he's talking if he sees a squirrel, he stop everything, and yells "squirrel" and he's completely distracted. This first team I was on, that was a common phrase, because we would often get distracted by things, we were learning so much, and it kind of stuck. Now that's my place where I share my random thoughts, and sometimes about sgile, and sometimes not.

Anything goes there.

About the author

Upcoming Events

Apr 29
Jun 03
Jun 03
Jun 03