Business analysts in Scrum - one company's view

I am asked continually whether business analysts have a place in agile, and in particular Scrum where there is no explicit role for a business analyst.  I always answer yes and set about to describe the possibilities and how business analysts are being used in Scrum.  
For example, here at a global financial company in New York they are bringing new graduates into the company to be business analysts, and to work in Scrum (their flavor of Scrum).  The business analysts were just told yesterday that their primary duties in Scrum will be to write and decompose user stories, working with both the business people on behalf of product owners and with the developers, and to write test cases and perform testing along side the QA analysts.  However, they are being trained in classic business analysis functions. None of the graduates are IT specialists or programmers.  A couple, for example, have advanced degrees in economics and finance. So they are in fact "business" analysts. And they will be working in Scrum. 

Interviewing for BA communications skills

The other day someone asked me how a manager would be able to tell that a candidate for a business analyst job has communication skills.  Here is my answer:

Instead of engaging in the apparently mandatory Q&A session where the applicant answers fairly rote questions (so rote that there are companies and people who purport to be able to prepare you for the questions you will get in an interview), start a conversation with the applicant. Ask questions that you might ask someone on first meeting them at a party or social get together. 

The answers are unimportant. You are looking for the way that they answer to determine their communications ability and skill.   If the answers are monosyllabic, evasive (a good communicator is willing to state that a particular subject is off limits or they do not wish to talk about it, rather than simply evading the question or providing ambiguous answers), not to the point, or answering in such a way that you are confused about their answer or not answering at all, then the person is demonstrating a lack of communication skills. On the other hand, if the applicant grabs the questions and runs with them, dominating the conversation (and as a good interviewer, you let the behavior run its course) then the applicant is also showing a lack of communication skills. The questions should not be too personal or threatening (hence the cocktail party analogy).  Develop some questions that would typically evoke questions in response.  Listen to how the applicant asks the questions (if the applicant does) and listens to the answers. Again this is a good indication of communication skills. A trick one friend of mine uses is to start the interview with some information about himself or the company and then ask a question later that would tell him whether the applicant was listening well.

Some experts point out that the interview situation is fraught with stress and that generally applicants in that pressure situation will revert to short answers. Ask more open ended questions as a way of getting the applicant more relaxed and responsive. However, if the applicant cannot get over their reticence in the interview they likely will not be able to overcome it when they have to interview a Vice President about a new project.

I would refrain from doing group interviews with the whole team. The concept there is to see how the applicant will fit in with the team. However, such an interview is terribly unrealistic. Unless you are hiring a person who will be making a lot of formal presentations to upper level management and other judgmental panels, This is not common. A better approach is one-on-one interviews with the team. This approach also has the advantage of some OJT training in interviewing for the team members.

As for the skills, my assumption from your post is that the technical skills or experiential skills have been handled through resume screening or a screening interview by HR or something so everyone you might talk to is technically qualified and you are looking for those with the right set of soft skills for a business analyst.

When someone else does our job

The question came up whether you play the role of business analyst differently if you are a project manager or some other position.  The answer is a clear ‘yes”.  This is mostly because as a business analyst you are analyzing the business full time. In some other position the role is an addendum or an incidental part of your full time job. A project manager is paid and rewarded for the success of the project, bringing it in on time, within budget and fully featured (everything done that was promised for that time frame and budget).  So when prioritizing her activities, the emphasis is going to be on tasks that contribute to project success. The business analyst will seek out different ways to solve the business problem and improve the business process while another position might ignore or avoid adding more to the project or other responsibilities. 

Business analysis is a full time concentration. It requires attention to detail and looking at the big picture, sometimes simultaneously.  It requires a specific attitude and approach. It is not an afterthought or simply the recording of what the business might want the computers to do at this moment.

Those who perform business analysis full time as their primary job are going to do it differently than those whose primary focus lies elsewhere.

Business Analyst as a Bridge Revisited

Periodically there is a discussion on a LinkedIn referencing the analogy of a Business Analyst to a bridge - usually a bridge between the business and IT.  A recent discussion suggested that the bridge has abutments and the business analyst is more like the abutments than the bridge itself. I typically point out, as I have in an earlier post that the bridge analogy is incorrect and that I feel as long as we see ourselves as bridges we will not fulfill our role as business analysts to the full extent we can.  The conversation went on and I suggested in a post that perhaps we might be considered 'hubs' rather than 'bridges' if we need an analogy responding to someone's suggestion of 'cog'. 
It took a while thinking about it, but then I realized what the real dangers are of the bridge metaphor are.  Here is my posting on the subject:

Going back in time I remember I when I was a programmer in the 60s we talked directly to the business people and sketched report formats, and drew up our own 5081 card layouts and even the scrolled conversation when we had terminals. Of course, IT was called Data Processing then and we were software engineers.

Then i was a programmer analyst because things got complicated and the few of us engineers who could put a meaningful sentence together and did not scare the business people were dispatched to talk with the stakeholders. But we still did all the interface design work and the business modeling and the like.  And then it was called MIS.

Time went on and I became a Systems Analyst which was cool.  Things got more complicated on both sides and the programmer analysts were morphing into more technical specialties like communications programming, network programming, database programming, etc. But I was still doing the same thing, although on a larger scale, evaluating business processes for conversion into 'systems'.  And it was now called IS. The "M" was dropped for a number of cynical reasons.

Then came the Business Analyst because systems analysis became too complicated and complex.  And so did business.  And the whole process of merging technology with business splintered. There were user interface designers and business process modelers and information architects and web design specialists and programmers became developers and testers became Quality Assurance and business analysts stepped into the middle.  And IS became IT.

Now here's the point:  we started off trying to merge business and technology, working together.  As things got complicated and complex, we added layers between and literally separated the two areas.  Now there is a movement (that has been going on for nearly 20 years) on many fronts to get back together again.  The concept of the bridge does nothing to merge business and technology. In fact, it makes it clear that there is only one connection between the two sides: the bridge, and emphasizes the separation of the two sides, else why would a bridge be needed?

Is there a better metaphor that would get all business analysts thinking in terms of closing the gap, rather than bridging the gap?  Is not one of the roles of the business analyst to blend technology into the business seamlessly so that using a computer based function is as natural as using paper and ink?

How about calling ourselves the 'glue of the organization' rather than the bridge?  Even the 'cog' or 'hub' analogies mentioned earlier imply that the components are separated by spokes, the only connection between the hub and component. I am not sure 'glue' is the right image because there are off-putting aspects of being considered 'glue' (stickiness, residue, hanging by a hard hat stuck to a girder, and so forth), but I am sure there is a better analogy or metaphor to depict our real role in the organization in terms of connecting business and technology.

Reversion to the norm

There seem to be two simultaneous movements going on, both seeming to be contradictory to each other. The first is the growth of agile software development and the corresponding concern in the business analyst community as reflected in the earlier posts and elsewhere. The second seems to be a movement away from "pure agile" (the kind of software development that spurns any business analysis except as done by the developers and any intermediaries at all between the developers and the business and the rest of the organization). 
At first that might seem contradictory. How can we be moving toward agile development and away from it at the same time?  I only observe.  Organizations are renaming their business analysts and other functionaries with agile sounding titles and tasks. Other organizations are moving developers, and former business analysts, into official business analyst roles. Why?
In the first place we are seeing the back end of the adoption curve with organizations stepping up into agile practices and following the preachings of the purists and the books to try to catch up with what these organizations perceive as the path to software development nirvana.  The other trend appears to be followed by the earlier adopters who have tried the pure approach and are now reverting back to a more 'normal' approach.  The natural 'reversion to the mean' that follows any extreme behavior or performance.
Those who have 'reverted' appear to be more 'agile' than they were before their agile excursion and retain many of the agile qualities and practices, but appear to be pulling back from the extreme measures: bringing back professional business analysts as facilitators, administration roles to ease the interaction with the organization, and project management to make multiple project or large project coordination easier.  It seems that pockets of pure agility cannot survive and turning an entire organization that has developed its culture and practices over generations into agile over night as the zealots proselytize just is not working as predicted.  Nor are there major advances in sales, revenue, or profit from the adoption of agile that support the claims. So the way we were becomes the way we are albeit a bit more agile in character and application.

Business analyst in agile Software development 4: Scrum Master

Some business analysts are more comfortable with the soft skills than others, soft skills like conversation, elicitation, mediation, negotiation, influence, reading body language, listening and so forth.  If you are such a business analyst and perhaps are not into defining requirements and dealing with authority but would rather deal directly and continuously with people, then perhaps the role of Scrum Master or Agile Coach is for you. According to the Scrum Guide (2011) by Ken Schwaber and Jeff Sutherland, the Scrum Master serves three roles: the Product Owner, the development team, and the organization.  Specifically, "The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team."  And, "The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team."
This requires a great deal of influence skills and communication skills. one of the primary duties of the Scrum Master is removing impediments or obstacles to the development team's progress.  This requires analysis and problem solving.  It also requires a good sense of organizational politics.
Scrum Masters in the teams I have seen generally facilitate most of the meetings, including the Daily Stand Up, and represent the team and the product owner to management.  Similar to the business analyst, the Scrum Master has no authority of his or her own so must make things happen through influence and political skill.  Many business analysts have moved in the direction of the Scrum Master. Some work as part time Scrum Master, and others are full time on one or more teams. Scrum Master, certified or not, is a positive step in an agile environment where the position of business analyst is no longer welcome.

Business analyst in agile Software development 3: Product Owner

Perhaps the most obvious role for the business analyst to assume when presented  with the options afforded by the typical agile software development implementation is that of Product owner. 

The characteristics seem similar and the experience the business analyst has in defining requirements and solutions seem to play well in the product owner arena. The product owner defines a set of specifications for the project that are rendered as ‘user stories’ and posted in a priority order on the product backlog. This seems right up the business analyst’s alley.  The business analyst must work with all the product stakeholders to define a set of specifications that solve the business problem and render it in the form of requirements.

The product owner meets with the solution team regularly to go over the product backlog to elaborate and explain the details of the stories so the developers can write the code to implement them. The business analyst meets regularly with the solution team to review and explain the requirements and changes that develop during implementation.

There is a lot of similarity between the business analyst and the product owner. Where the similarity ends is where the problems begin.  The product owner has complete authority over the ultimate product and by reference over what the team does and the order in which the team does it. And the product owner has total authority for acceptance of whatever the solution team delivers.  The business analyst by definition has no authority.  If you have been a business analyst for any length of time, assuming that authoritarian position from one who works strictly with influence might be quite a hurdle to overcome.  Additionally, despite the apparently parallel requirements definition tasks, the product owner does not spend time collecting and analyzing information to produce the requirements. In this regard, the product owner is more like a project manager than a business analyst and Ken Schwaber, author of Scrum, warns against the business analyst moving to product owner for just that reason: the business analyst may revert to performing as a business analyst and not as a product owner.  However, if you can make that transition, becoming the product owner is a good step for a business analyst in an agile world.  If not, I have some more suggestions coming up.