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, and to be honest, I don’t miss them. Agile espoused iterative, rapid development and quick delivery of functionality, whether it be big or small, allowing a project team to…well…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 project (I know “Agile” comes in many flavors. Scrum, Kanban, Lean, SAFe…I’m talking about Scrum. Don’t get all worked up about it.), the customer (aka the “business”) is a part of the team. They speak directly to the developers and describe what they want the solution to do. The business and the developers go back and forth discussing, defining and refining, until the developer has a pretty good idea what to build. The developer runs off and writes code, tests it and demonstrates it to the business at the end of the Sprint. The team (including the customer) review what was built and demonstrated, and accept or redirect the next round of work…lather, rinse, repeat.
I have spent a good bit of my career 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 need 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. There is often a lot of pushback and justification…a lot of wailing and gnashing of teeth.
Enter the Agile Product Owner. 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 customers and overly-helpful developers. An Agile Product Owner has an understanding of 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 the deliverables are) 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 those need in a form the developers understand and prioritizes them, we just need a PO who understands what the business needs, can write those needs in a form the developers understand and prioritizes them…hmmmm. BA? PO? I’ll have to ask HR which one pays better.
Mike is a Principal Consultant and the Business Strategy Technology Lead at Moser Consulting. With a degree in Ceramic Engineering from Rutgers University, Mike’s career has been focused almost exclusively on process design and improvement. He started with process and materials design for aerospace coatings in the late ‘80s, and made the switch to IT after saving the company from the sure destruction of Y2K. Over his 30+ year career Mike has had the pleasure of digging into processes in regulated pharma, manufacturing, field service, government, insurance, airlines, marketing, and utilities, among others, and would love to experience more. Drop him a line on LinkedIn (www.linkedin.com/in/Michael-Boris-MoserIT) or at [email protected]