I can no longer count the times I’ve read or heard the statement, “We don’t need Business Analysts in Agile. Business Analysts don’t really add value, they just parrot what the real stakeholders tell them”.
OK, that may not be verbatim, but it certainly captures the gist of the message. In the vein of Churchill’s “Those who fail to learn from history are condemned to repeat it”, I think it interesting to take a brief look at the history of Information Technology (IT) to test the premise.
The reason I relate well to computers is that they are like me. Born in the ‘40’s, raised in the ‘50’s, came of age in the ‘60’s, became productive in the ‘70’s, found themselves in the ‘80’s, got connected in the ‘90’s, downsized in the ‘00’s, and went viral in the current decade. (OK, maybe I haven’t quite made the viral level, but, hey, I still have a little time left! If I count 2020 to this decade, I still have over a year.)
Lean Business Analysis is Born
Throughout that time, the process of figuring out what we should do with these “thinking” machines called computers has morphed as well. Of course, business needs definition and validation techniques have always lagged behind technology, but that is as it should be. We need to prove that a computer can add 1 and 1 to get 2 reliably before we spend time figuring out why we need that capability.
As always, you must create something before you can improve it. While developers learned HOW to tell the computer what to do, “real people” needed to tell the developers WHAT to tell the computer to do. I think that pretty much sums up the overarching purpose of what we now call lean business analysis.
Technology-Driven Business Analysis
In the beginning, developers hid behind a title called Programmer. That title morphed into Programmer Analyst when they realized that it was not enough to get the computer to do something – it had to do something the business community wanted.
As computers gained increased capabilities, life got more complex. Keeping pace with technological advancements became a full-time job, so we split Programmer Analyst into two roles. Those who “spoke computer” became developers and those who “spoke human” became analysts.
The Analysis role was assigned to people who had more fun working with people than twiddling bits and bytes for a living. However, IT kept its tentacles on the process by calling them System Analysts to make sure they stayed connected to their roots. The theory was, if you didn’t know how to communicate with a computer, you could not possibly know how to communicate with a developer.
Users Take Control of Their Own Destiny
The ‘80’s brought us the PC with the widespread use of GUIs. Those developments helped us recognize that computer experts were not always the best candidates for defining what the business community needed. That was when we spearheaded a movement toward teaching business experts how to define their own needs in their own language. That was the birth of the Business Analysis as a profession. We finally found a home.
For the first half of the ‘90’s, we taught a thundering herd of non-IT personnel how to define business needs and become Business Analysts. Those doing this dirty work were responsible for representing the business community’s interest. Their training consisted of requirements elicitation, writing, estimating, and communication. For the first time, the businesses were somewhat in control of their own IT applications.
The Y2K Hiccup
As everyone alive at the time recalls, the second half of the ’90’s had anyone with even a modest understanding of computers scrambling like the proverbial cat trying to kill the dreaded Y2K bug. For those of you born later, that really was not a scam, but an existential and heroic effort to reduce the risk of catastrophic failures at the fully unexpected turn of the century.
Obviously, none of us guilty of writing code had expected our programs to survive come the year 2000. (OK, that is defamatory and an outright lie, but that has no bearing on my story, so I’ll let it slide.) I maintain that the Y2K bug was DOA only because of the extraordinary engagement and dedication of millions of IT professionals around the world. Great job, gals and guys, great job and thank you.
Enter the Product Owner
Now, back to the timeline. The ‘00’s ushered in a new, Agile era in which the focus for software shifted back to the developers. The Agile philosophy stipulates that the developer’s job was exclusively to deliver working software. Because developers were supposed to maintain direct communications with their customers, many felt that the role of the business analyst was superfluous. We almost became the shortest-lived profession ever.
Agile methodologies created the role of Product Owner to represent the business community’s interests. Putting the Product Owner in charge of the Agile Team (composed of developers and testers) ensured that the business side oversaw the process. IT was rightfully assigned to the supporting role it should have.
Lessons Learned over the Decades
Agile is an extremely valuable and effective method for developing software applications that deliver what the business community needs and wants. Agile delivers small chunks of working software at a time. Each release demonstrates functionality to the Product Owner who ensures that it provides value to the end users and represents what the business truly needs. As ideas go, absolutely brilliant. Top-Notch concept that addresses many issues that have plagued IT since the beginning.
We have learned that successful Agile initiatives depend on the Product Owner doing much of what Business Analysts are trained to do. Yes, the terminology has changed. We now speak User Stories, Epics, and Feature Lists instead of Business, Stakeholder, and Solution Requirements. Yes, the timing of the requirements (Story, Feature, and Example) discovery activities has changed from being a one-time, up-front event to a constant, ongoing effort. The depth of detail captured for each business need has been reduced to what is essential to guide developers only for imminent work.
Titles Change, Needed Outcomes Remain
But let’s not forget that Product Owners are people, too (at least until AI rules the roost). As such, some are great at determining what the business needs, others need help. Based on my brief walk down memory lane, I see a bright future for those of us who have grown to love being Business Analysts. We can change hats and become Product Owners (our skillset is ideal) OR we support our local Product Owner with our extensive elicitation and communication skills. Either way is a path forward for those who like to fiddle in the middle between real people and IT. We just must embrace change instead of hanging on to the job title. The choice is ours.