How Agile Helped Me Survive Being a Business Analyst

Over the last 20+ years, I’ve enjoyed more of my career as a Business Analyst than in any other role I’ve been able to play on a team. The control freak in me loves to practice my Project Management skills, the perfectionist in me always loved getting into Testing roles, the innovator in me loved trying my hand at Product Management. But the perfect balance, for me, is in playing the Business Analyst role.

As the consummate “contractor” for the first 20 years of my career, I was able to play the Business Analyst role in at least 10 different companies with 50 different ways of doing things. For the past 3 years as a consultant and trainer, it’s been my pleasure to work with another dozen or so clients with specific emphasis on Business Analysis skills. I want to share with you how Agile has changed the way I see this role and challenge you to try something new, if needed, to survive in an environment (and industry) undergoing drastic changes in expectations and practices wherever the word “Agile” is uttered.

The Traditional Business Analyst

In the previous century, the typical cadence of a Business Analyst (at least from my vantage point) looked something like this:

• Spend a month or two with the Project Manager and Project Sponsor developing a charter and business case to present to the leadership team for approval and funding

• Spend a few months meeting with stakeholders from across the enterprise to define the Business Requirements of the project and to analyze the impacts that needed to be documented

• Once the 300-page Requirements Package was signed off by 23 people, consult to the design and architecture team as they developed the technical implementation and documented the details – inevitably revising 298 of the original 300 page Requirements Package multiple times and taking it back to 23 people for their review and sign-off

• When the epic novel of details was handed to developers, make sure that time was set aside from the new project that I was moved to in order to answer questions and continue revising the 300-page Requirements Package that I started writing 6 months ago

• As the behemoth of documentation and code was handed off to testers, make sure that I made myself scarce and referred to the 300-page Requirements Package I wrote a year ago as the “source of truth” for what needed to be tested

I’ve never been one to dwell on painful things for long, so this approach just didn’t sit well with how I view life and wrap my mind around how the world works. It’s too slow, drawn-out, full of surprises and rehashing of ideas and details that I would often like to forget. I wasn’t going to survive my career choice given how things were going.

The Agile Business Analyst

When I found Agile, nearly 10 years ago now, that changed to some degree. Life moved at a more acceptable pace. The Agile Business Analyst cadence looked more akin to:

• Spend a day or two with the Product Manager to identify the Vision of an upcoming release or new product

• Spend a week or two defining the Epics and Features necessary to build the MVP necessary to meet the needs that the Product Manager envisioned

• Iterate around the most important and necessary Stories that were important to the release for a week or two with the Product Manager, various stakeholders and even customers to write User Stories in a simple format that were no more than 1-2 pages in length, and make sure that I fully understand the criteria by which the customer, Product Manager and users would be measuring successful implementation of a small, compact story

• Once I had the Acceptance Criteria well-formed and meaningful, work with the delivery team in Backlog Grooming sessions to make sure that the details were clear, understood, estimable, and informed what they needed to do to code and test the small packet of functionality

• During a Sprint in which a Story was being developed and tested, answering the day-to-day questions was much simpler and rarely required the revision of details, certainly not 298-pages of details

• On occasion, I would find that there are small gaps in understanding and the “shuttle diplomacy” of clarifying the details between the delivery team and Product Manager or customers would begin, but the process seemed to be faster and simpler than it ever was revising a 300-page Requirements Package

I wasn’t a fan of the “shuttle diplomacy” and frequent Story Review sessions, but I understood that this was a better way to get input from the delivery teams regularly but still “protect their time to code and test” to deliver requirements I had written for them in the previous weeks. Agile, and the use of Stories vs. 300-page Requirements Packages had made my life more bearable!

The Aha Moment?

Then, something unexpected happened. I started working with clients in Story Workshops and changed the format that I’d been following. Instead of meeting independently with Product Managers, stakeholders and customers to define Stories, then meet with the delivery teams to refine the details, I started to bring some members of the delivery teams with me. In a room, I could have the Product Manager, 3-4 Stakeholders from various parts of the business, an Architect, a Tech Lead, and a QA Lead.  Sometimes I’d even have my UX Designer there.

At first, this was unsettling. I was used to facilitating in a controlled environment with just a handful of people at a time and scribing the Story details as they were being discussed. In the first round of story discussions, I could project the Story and show the Product Manager and stakeholders what I was typing, have them validate and wordsmith/improve as we went. The follow-up with the delivery team was a similar approach – projecting what I had crafted and scribing additional details and documentation as we talked through it. But that was simply not going to work in this new venue – not with up to 10 people in a room; some of whom didn’t even speak the same language (“business” vs. “technical”) and all of whom had differing opinions on how far in the details the discussion should go. I thought I’d made a mistake in trying this out and was tempted to go back to shuttle diplomacy as my form of implementing progressive elaboration of requirements.

What would you do?

Lucky for me, I have a network of wise and experimental mentors who advised me not to give up. The benefit of having the people who need the work in the same room as the people who did the work (to write the software) was too valuable to give up on. They encouraged me to continue this approach and advised me to bring help. I’m a control freak, remember. And a perfectionist. So that wasn’t easy. But, I asked for help.