The End is Near for Business Analysts in Agile!
I’ve heard “The End is Near!” for Business Analysts for almost 20 years. Waterfall project management, with its need for formal requirements, is dead…a dinosaur…so 1990’s.
To be honest, that’s mostly true. With the publishing of the Agile Manifesto in 2001 there was no need for a 2-inch-thick formal requirements document. I’ve written them I don’t miss them (well, maybe a little). Agile espoused iterative, rapid development and quick delivery of functionality, whether it be big or small, allowing a project team to…you know…be agile. Direction, goals, deliverables and requirements could be adjusted, redirected or scrapped altogether every few weeks. “Wait a minute Mike, I just heard you say the ‘R’ word, as in… ‘Requirements’”. Yes, I did…and it wasn’t a mistake. With very few exceptions, every project needs requirements. You need to know what the project is supposed to deliver, why there is a team and a budget…and why the project has some catchy name (typically in the form of a questionable acronym).
Here how it’s supposed to work (feel free to skip ahead if this isn’t your first Agile rodeo): In a fully adopted Agile Scrum1 project, the customer (aka the “Business”) is a part of the team. They describe what they want the solution to do and, under the guidance and protection of the Scrum Master, the Business, Developers and Testers go back and forth discussing, defining and refining, until the entire team has a good idea what’s to be built. The developers run off and write code, the testers test it and the output is demonstrated for the business at the end of the Sprint2. The entire team (including the customer) review what was built and demonstrated, and accept, correct or redirect the next round of work…lather, rinse, repeat.
I have spent a good bit of my career as a BA keeping the business away from the developers. Developers are great people. They have fantastic skills, deep understanding of their trade and they really, really want to help. In fact a developer will deliver exactly what the customer says they want….GAAAA! I don’t want to speak ill of the customer, but what they want and what they should get are not always the same thing. As a BA it’s my job to understand what the business does, needs and should or shouldn’t have…and to translate that into something the developer understands. Often, there is a lot of pushback and justification by the business…a lot of wailing and gnashing of teeth.
Enter the Agile Product Owner (PO). While a BA, in the classic sense, is not on the list of Agile Team Members, there is still a need to bridge the gap between overly-confident customers and overly-helpful developers. An Agile Product Owner understands what the final deliverable product should be (remember, it’s not the job of the BA, customer or Product Owner to define HOW functionality should be delivered, just WHAT is to be delivered) and prioritizes the work accordingly.
So, no, we don’t need a BA on our Agile Team. Instead of a BA going out to define current state and understand the future state business needs, writing and prioritizing requirements, we just need a PO who understands what the business needs, can write those needs in a form the developers understand and prioritizes the work to be done. BA? PO? I’ll have to ask HR which pays better.
- “Agile” comes in many flavors. Scrum, Kanban, Lean, SAFe…we’re just going to talk about Scrum. Don’t lose sleep over it.
- A Sprint is the length of time for each iterative “Define – Build – Demo” cycle. A Sprint is typically 2 -4 weeks, but can be any length the team defines.