It was Saturday, August 1, 1981. My family huddled in front of our console TV to watch MTV’s first video debut: ‘Video Killed the Radio Star’ by the Buggles . MTV changed the music industry. Successful artists in the 80’s rose to stardom by taking full advantage of this new visual medium. It became less about the music and their ability to sing and more about the performance and art direction. Sales were based on video popularity.
In the Waterfall era, we didn’t start development until the business analysts had vetted and documented all the project requirements. Then a shift happened with Agile. We broke down a project into smaller units of work (user stories). We only needed detailed requirements for the user stories that were about to be pulled into the sprint. The advantage here was that we got timely requirements. It allowed us to also alter course more nimbly. Agile was less about needing to know the overall project and more about smaller business value we could deliver quickly. Agile created new roles and new processes and just like MTV, changed the development culture.
Conversing with peers lately, I’ve started noticing a theme popping up about requirements. I am hearing people complain that they “don’t have requirements” or “don’t have the right requirements”, “we missed some crucial requirements”, “we forgot about the impact to this system/group”, etc. The business analysts that used to be crucial in gathering requirements were nowhere to be found.
With the introduction of Agile, it hasn’t been clear where the business analyst role fits on the team. Since we aren’t needing to create these Waterfall artifacts (e.g., functional requirements), teams started to question the need for business analysts. Most teams eventually overloaded the product owner and developer roles by having them do the analysis and gather requirements in addition to their existing duties.
I have observed several product owners tend to be more focused on the road map and project milestones. Often, they aren’t into the nitty gritty details that are needed by the developers. Product owners are juggling several projects. They also might not be looking at the impact to other systems. And when the product owner is part of IT rather than the business, there’s an even bigger disconnect with analysis and requirements. The IT product owner tends to be a mouthpiece for what they heard and may not have a full understanding of the specific business workflow.
The developer, acting in the role of a business analyst, is hit or miss. I’ve worked with some developers that are great analysts. But analysis takes them away from their core developer function. They end up being spread thin and lack focused time for actual development. Without a business analyst, many developers jump toward a solution while not fully comprehending the business need. For example, the end user may propose an initial request and many developers start coding instead of asking why the user is making that request. A business analyst, on the other hand, can see that the initial request doesn’t actually solve the underlying issue and will steer the user towards a solution that meets their needs.
So back to the MTV analogy. MTV changed their programming over time. People turned to streaming services like Spotify and rediscovered listening to music without the bias of the performance. What if we are at that Spotify era in Agile where we need to focus how we acquire and define our requirements again? A business analyst can focus on gathering the right requirements at the right time to align with the product owner’s road map and vision. A business analyst can efficiently translate the user requirements for a developer and be more readily available to respond to developer questions. If we could emphasize and create a formal business analyst role on an Agile team, we might be able to address the frustrations teams are experiencing with the gap in their requirements.
Just like I wanted my MTV back in the day, today I want my business analyst star!
BI Over Beers 
Leave a comment