It Isn’t “Safe” Being an Agile Business Analyst

I’ve often thought that roles in waterfall processes are somewhat “safe”. There is a rhyme and a reason to waterfall projects with each discipline stepping up to the plate at a different time. They do their work, get it reviewed or achieve a milestone, and then move onto another project or focused effort. Usually the project managers and architects are up first. They envision the project from a planning and a structure perspective, and then leave their artifacts behind for others to execute.

Next up are the BA’s. It’s usually an intense time early on in the projects-gathering stakeholders and eliciting requirements. There’s a whole lot of listening, writing, reviewing, editing and reviewing some more. It’s a lot of hard work to get everything right, but then there’s the final review and customer sign-off-and your work is essentially done.

The development team is up next to implement the functionality. Usually they are incredibly optimistic in the beginning and over commit to work and delivery dates. But that’s what the business wants to see-unbounded aggressiveness. However, reality soon shines it’s light on the team, as does 90% done syndrome, and things take quite a bit longer than expected. The customers become impatient and begin to loose their confidence.

But then something magical happens the developers reach a point of closure and then…pass the code over to QA for testing. Whoo Hoo!

Need I say more? QA will normally test in a defect-rich environment and work oppressive overtime. Every bug that is found is somehow QA’s “fault” for making the project longer. But there comes a day, when the business accepts the resulting code quality proposition, and proudly presents the applications to the customer for UAT.

And what a day it is. You’ve all been there. The customer fires up the application in anticipation. But quickly they’re mumbling to themselves and scratching their chins in consternation. Then you hear that dreaded cry-this isn’t what I expected!

What if something goes wrong?

As a traditional BA you have the stage for a short time. Your job is “safe” in that you rarely stick around for the end of a project. Your efforts are typically front-loaded and intense. There’s also positive energy in the beginning-as all projects start out as naïve, “can do” efforts. Your work is often finished quickly and you usually change your focus towards a new effort. You convince yourself that this is the essence of things and quite natural in the workflow.

A flip-side example of this is the testers. They’re often quite idle in the beginning stages of projects. Yes, they’re “preparing” for testing-but the focus and intensity is quite low. They’re depending on the early phases to do a complete job so that they can immerse in testing at the end.

We all know that this phased approach to delivery doesn’t work that well, but it does create “safe zones” for each of the teams’ functional groups. It means that traditional BA’s can do their job and then “hide” from the reality of success. If the project is successful in the eyes of the customer, then it was the requirements that drove the success. If not, then there was someone else to blame. Either the customer was wrong-in that they didn’t know what they truly wanted or needed. Or those pesky developers simply didn’t fully understand the requirements. Or the testers simply didn’t work hard enough to get things done on time. You get the point-functions and people can “hide” in this model and pass the buck. Not always true, but sad when it happens.

Is it “Safe” being an Agile BA?

The agile BA has no intense periods of activity, nor safe idle periods. They have to always be “on” within the team. They’re incrementally defining requirements, helping them get implemented, perhaps doing a little testing, and continuously collaborating with the customer to elicit valuable feedback.

There’s no “quiet time” while they go off and write a long series of use cases for an application. No, long periods totally focused on requirement writing. And no, they have to share their results with their teams continuously. It’s this change that is quite difficult for many traditional BA’s who are making the transition to agile teams. Some say it might even be an exciting transition.

I’ve often spoken of agile projects as having a nature of “controlled chaos” in that you don’t know exactly where you are going day-to-day. You’re on the edge much of the time, figuring out your path as you go. Never knowing what’s directly around the next corner. It’s this capacity to go with the flow, as you sort through technical hurdles and customer needs and expectations, that is inherent to agile.

And what if you’re serving in the role of Product Owner?

Another common transition for agile BA’s is adopting the role of product owner within a team. The decision is usually driven by the notion that product owners write most of the user stories in their product backlogs, so who better than a BA to assumes that role. However, the PO role is even more chaotic and driven than the agile BA. And yet, it’s another role that increases your exposure and ability to drive your teams towards even more success.

In this role you adopt more visible traits, making your priority-based decisions transparent across the organization. You’ll be defining the “now & later” states for the project while defining a stream of features that will incrementally define the product. It’s a just-in-time view that loads high-value features first and constantly engages the customer in progress.

In fact, you’re role will also focus on acceptance criteria, so work will be reviewed and accepted within each iteration. This role is a powerful extension for most BA’s in that it extends into product management, project management, and leadership activities. Nonetheless, it’s a wonderful extension for the agile BA.

Wrapping Up

If you’re a traditional BA who likes it slow and steady. Who likes to work for periods, undeterred and uninterrupted on requirements. If you would prefer to become detached from your project after your job is essentially done. If you like throwing requirements over the wall for implementation, then becoming an agile BA might not be for you. It may be too much for you…or too “chaotic”. So stay in your safety zone and happily fulfill your traditional project responsibilities. It’s ok!

However, if you like being in the thick of things in setting the functional direction for a project. If you like collaborating with customers and stakeholders during the entire software lifecycle.  If you’ve come to understand that software projects are tricky beasts full of uncertainty that resists planning outcomes. If you enjoy being the “glue” that continuously connects the customer to the team. Then perhaps you have what it takes to become an Agile BA. Trust me though, wear a helmet and be ready for a bumpy ride. Also be ready for success as well…and enjoy the ride!

Don’t forget to leave your comments below.