BA - more biusiness or technical?

A recent question came up that is a common one I've been hearing for years. I had thought the concern had been put to rest, or answered once and for all. Apparently it hadn't.  The question: how much business and technical should a typical BA be? What percentage of each? Should a business analyst focus on technical knowledge or business knowledge? 
Here is my answer:

I think there has been an assumption since the BA moved from a very specific position in telecommunications companies in the early 90s to a profession related to IT that the business analyst has technical chops as well as business acumen.  I recall business analysts of the mid-90s being drafted from the ranks of "super-users" (business people who took to computers and helped the others in their business department with user problems).  IT countered by moving Systems Analysts more to the business side starting in the late 80s without giving them the name "business analyst". (I was one of those).  So as can be seen by where the BA hails from, the amount of technical knowledge will vary. 

That said, we should remember that a business analyst analyzes the business. The business analyst solves business problems.  The solution of a business problem may not include software development and maybe not even technology. Note the definition of business analysis from BABOK V3: "Business analysis is the practice of enabling change in an enterprise by defining needs and recommending solutions that deliver value to stakeholders. Business analysis enables an enterprise to articulate needs and the rationale for change, and to design and describe solutions that can deliver value."  Doesn't mention software development or technology, only solutions.

Reacting to Complaints

Sometimes we have a situation where a particular stakeholder, maybe a manager or a client or customer which makes the issue more difficult, is a complainer. They complain about everything all the time. Some people are simply like that. And we allow for that and tolerated for humor the manager was doing that. But sometimes the complaining gets in the way. When you have a meeting and the first 20 minutes of that hour-long meeting I spent listening to complaints and the last 20 minutes are spent listening to complaints then you were losing quite a bit of time and that is quite a bit of productivity and money. So the question is what can you do about the manager or anyone for that matter who spends an inordinate amount of time complaining?

A complaint always reflects an unmet expectation. Someone expect something to happen and it does not happen, or expect that it shouldn’t happen and it does.

An unmet expectation is a problem. Using Jerry Weinberg’s definition of a problem: “the difference between the way things are and someone’s perception of the way things should be” we can see that an expectation is someone’s perception of the way things should be and that does not match the way things are.

So when a complaint occurs it is a signal, a trigger, to begin a problem solving process.

bsuiness analyst and domain knowledge

A recent posting came out in favor of the business analyst possessing significant domain knowledge in order to be successful. I don't know if I agree with this. 

Ostensibly a business analyst should not need domain specific knowledge to be a top BA.  What the BA needs is the ability to communicate well in all media to all receivers, and the ability to analyze and think critically: to question and consider.  These traits are hard to learn if you don't come by them naturally, but they can be learned. Domain specific knowledge is easy to learn.

Agile or non-agile BA?

When you consider it, if as a business analyst you focus on identifying and solving the real business problem, it doesn't matter whether you are working in an agile or non-agile environment.

Expansion of business analysis scope

The activities that absorb the attention of the business analyst seem to go in cycles. Sometimes the business analyst is involved with more technically oriented work and other times the business analyst is more strategically involved with business planning. Much of course depends on the events and circumstances of the times. Right now there seems to be a significant emphasis on security, especially business and information security and disaster recovery and business continuity.

Granted the experienced business analyst should be able to pick up any business area in a short amount of time applying his or her skills and abilities as communicators and analyzers which equate to fast learning. But the areas of business continuity, disaster recovery, and information security, even when not talking about the technical aspects, are not necessarily what might be considered business lines.

Perhaps there will be business analysts who specialize in the business aspects of disaster recovery and business continuity. Unfortunately these areas are not full-time long-term jobs because once the business continuance and disaster recovery plans are created they are turned over to the people who will test them and then in the unfortunate event that they may be needed, to execute them.

Business security should be a constant and ongoing concern of the business analyst, but seems to only draw the attention of the business in general and the business analyst in particular when there has already been a security breach. Prior to that most businesses, and unfortunately business analyst as well, seem to have either an “it won’t happen here” or “it’s somebody else’s job” attitude.  Each of us as business analyst has to be aware of the risks and potential for security breaches from all sorts of threats and attackers.

Business Analysis Predictions

I was talking to a group at a meeting the other day and they asked me what prediction I would make for business analysis over the next few years.  I have made predictions in the past, but cannot remember what they were or whether they came to pass. So take it for what it’s worth, here is what I said:

Executives will still look for the silver bullet and quick fix especially where people can be removed from the product development equation. At the same time analyzing the business (marketplace, product mix, competition, business structure, root cause analysis of business problems, business capabilities, business capacity, etc.)  will become increasingly important as a factor of business success. Business analysts will move away from IT and requirements orientation and take a more strategic position analyzing the business to uncover problems, weaknesses, vulnerabilities and opportunities which will then be passed to Agile teams to solve or implement. Business analysts who are requirements documenters only will find their jobs dwindling while those business analysts who focus on solving business problems will flourish.

The agile coaching contradiction

Agile teams are supposed to be self organizing. And yet when teams have trouble organizing, the common solution is to bring in an agile coach. But the agile coach is not on the team. If the agile coach provides the motivation or approach to organization, or organizes the team him or herself than the team did not self organize. If all teams, according to agile, are supposed to be able to self organize, what does it mean when a team can self organize? In the agile philosophy if a team does not self organize do you disband the team and try again? Or do you assume that that show this work?