If you are a current or recovering Business Analyst, you may remember Scott Ambler's assertion in his essay "Rethinking the Role of Business Analyst:"
I have friends who switched to Curad for their fabric bandage needs, they were so annoyed by Ambler's witticism, even though Curad never had the mysterious tiny round bandages that don't do anything, but you feel incomplete without them.
In the past, business analysts were always first to go, when a company decided to institute an "agile" policy where everyone on all teams would get called a "developer," supposedly because everyone on the team could do everything needed, but generally because everyone on the team was, in fact, a developer.
Often times, the next step would be that real world businesses would discover that they couldn't afford to colocate their stakeholders in a single room with the developers, because the stakeholders had other things to do. Meanwhile, the teams of T-shaped equals would discover that none of them had the skill set, time, and especially not the inclination:
In the old days, a person or two might eventually be added to the all-developer team to handle these types of work, often on an "experimental" basis to see if the individual "added value." Many times, it turns out, the person would add value. Many times, that person was called a business analyst.
Most of us have come to terms with this dance. The Pragmatic BA has the confidence to wait until a team realizes they need help to allow everyone else on the team to perform their roles optimally.
It probably won't come as news to you, if you're a BA waiting to be called into action by an agile team. It turns out that the cool business-interfacing people on agile teams are not called business analysts any more. They are called "product managers." They are also called "experience designers," "data modelers," and a host of other names, but more often than not, the person who helps keep the team focused on doing the right thing for a business is called a "product manager." And sadly for you, the product manager totally outranks you, if you are a mere business analyst.
Mark Silver explains in SpecTECHular:
The pragmatic BA wants to howl at Mark and Brian that this is a distinction without a difference. Surely you are simply describing work which is done by an entry level person as different from the work done by a more experienced one. An entry level product manager is more likely to write specifications, where a senior business analyst is likely to set strategy. On the ground, we do not have serious definitional differences between BAs and PMs. The two groups do the same type of work and share the same skill sets.
But before the howling begins, allow me to observe that the distinction has currency, and a whiff of ageism. It appears that what we have is a glamour gap. Jeff Gothelf observes in his blog that the usage of one title versus the other has everything to do with the age of the hiring company and perhaps even the age of the desireable PM/BA hiree.
I embarked on the research for this blog post with a bit of a chip on my shoulder about how annoying it is that, categorically, BAs are now being considered the junior helpers to PMs, in a manner that disregards experience level. And indeed it is annoying, but one cannot control the progress of the language. This is why I would almost - almost - conclude that senior business analysts in agile environments should simply call themselves product managers, since there is clearly not a talent gap, and PM is a better brand.
My only hesitation? Well, I suppose it was predictable, but maybe you shared my interest in John Cutler's recent Hackernoon article entitled "We Need Fewer Product Managers." The article appears, despite its disclaimer, to be an attack on anyone who hires people with the Product Manager title, on the grounds that people with other titles can cover the disparate things a product manager does. We need fewer product managers, he says:
Sigh.
A business analyst (BA) is a poor substitute for developers who have both ready access to actual stakeholders and agile modeling skills. Remember, BA is also the abbreviation for band-aid.
 |
| Image courtesy of target.com |
In the past, business analysts were always first to go, when a company decided to institute an "agile" policy where everyone on all teams would get called a "developer," supposedly because everyone on the team could do everything needed, but generally because everyone on the team was, in fact, a developer.
Often times, the next step would be that real world businesses would discover that they couldn't afford to colocate their stakeholders in a single room with the developers, because the stakeholders had other things to do. Meanwhile, the teams of T-shaped equals would discover that none of them had the skill set, time, and especially not the inclination:
- to map one or more corporate "value streams" to help executives make decisions about what to build
- to prioritize the work within the context of the company's strategic goals
- to navigate the political stresses within the overall business environment in a way that would allow a single software stream of work to emerge, all going in one direction
- to advocate for the team to business owners, and for the business owners with the team
- to facilitate meetings with users to collect and test requirements against the real world
- to characterize potential business returns on investment from specific technical efforts
In the old days, a person or two might eventually be added to the all-developer team to handle these types of work, often on an "experimental" basis to see if the individual "added value." Many times, it turns out, the person would add value. Many times, that person was called a business analyst.
Most of us have come to terms with this dance. The Pragmatic BA has the confidence to wait until a team realizes they need help to allow everyone else on the team to perform their roles optimally.
 |
| A country dance, by Hogarth, posted on https://philadancehistoryjournal.wordpress.com/category/%E2%80%A2-18th-century/ |
FRIENDS, SOMETHING REALLY BAD HAS HAPPENED TO THE BA BRAND.
And I don't mean Band Aid versus Curad.It probably won't come as news to you, if you're a BA waiting to be called into action by an agile team. It turns out that the cool business-interfacing people on agile teams are not called business analysts any more. They are called "product managers." They are also called "experience designers," "data modelers," and a host of other names, but more often than not, the person who helps keep the team focused on doing the right thing for a business is called a "product manager." And sadly for you, the product manager totally outranks you, if you are a mere business analyst.
Mark Silver explains in SpecTECHular:
...the two roles overlap at some points, and do require many of the same skills. However, I feel it’s still important to acknowledge the distinction along with the resemblance.Brian de Haaff, of the Aha Blog, explains that a business analyst will be "inward facing" towards the team, whereas a product manager will be "outward facing" towards the market. Additionally, the business analyst writes technical specifications for the developers, where the product manager owns the overall strategy and roadmap.
The pragmatic BA wants to howl at Mark and Brian that this is a distinction without a difference. Surely you are simply describing work which is done by an entry level person as different from the work done by a more experienced one. An entry level product manager is more likely to write specifications, where a senior business analyst is likely to set strategy. On the ground, we do not have serious definitional differences between BAs and PMs. The two groups do the same type of work and share the same skill sets.
But before the howling begins, allow me to observe that the distinction has currency, and a whiff of ageism. It appears that what we have is a glamour gap. Jeff Gothelf observes in his blog that the usage of one title versus the other has everything to do with the age of the hiring company and perhaps even the age of the desireable PM/BA hiree.
In the younger companies (say, 20 years old or younger) the role of the Business Analyst is often non-existent or, at best, a relic of the “early days.” In these...companies, product managers lead the charge with product vision, ownership, customer development, competitive analysis and product strategy. In older companies (20+ years) product management is a relatively new profession being added mainly as a response to what these companies are seeing these younger companies do as well as a recruiting tool to gain the attention of younger applicants.Gothelf goes on to lay out a Venn diagram showing the overlap of Business Analyst with Product Manager in a manner similar to what Mark Silver describes: BA is more inward-facing and tactical, where PM is more outward-facing and strategic.
 |
| Diagram by Mark Silver, published in https://www.jeffgothelf.com/blog/whats-the-difference-between-a-business-analyst-and-product-manager/ |
I embarked on the research for this blog post with a bit of a chip on my shoulder about how annoying it is that, categorically, BAs are now being considered the junior helpers to PMs, in a manner that disregards experience level. And indeed it is annoying, but one cannot control the progress of the language. This is why I would almost - almost - conclude that senior business analysts in agile environments should simply call themselves product managers, since there is clearly not a talent gap, and PM is a better brand.
My only hesitation? Well, I suppose it was predictable, but maybe you shared my interest in John Cutler's recent Hackernoon article entitled "We Need Fewer Product Managers." The article appears, despite its disclaimer, to be an attack on anyone who hires people with the Product Manager title, on the grounds that people with other titles can cover the disparate things a product manager does. We need fewer product managers, he says:
We need MORE internal startup co-founders, UX, customer advocates, domain experts, service designers, complexity untanglers, researchers, and reliable ways to interact directly with users/customers. We need more product thinking, and less product managing. [emphasis Cutler]Eventually, Cutler gets to the real nub of it--"mature" teams don't need a single person to keep them aligned with business sponsors of the work. "What would it take," he asks, "for a team to share ownership? Do you really need a single wringable neck?"
Sigh.
Comments
Post a Comment