Search This Blog

Monday, November 18, 2013

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.

Thursday, July 4, 2013

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.

Friday, May 3, 2013

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.

Sunday, April 14, 2013

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.

Thursday, March 7, 2013

The business analyst in agile software development, part 2: What is your value??



Let’s talk about where the somewhat negative attitude toward business analysts in the agile community comes from. Please note that the attitude is changing for the better, and we’ll talk about that later.

The knock on business analysts is because of the observed behavior of business analysts who perceive their role as one of ‘collecting requirements’ from the stakeholders. As such they facilitate a meeting and ask the stakeholders in the meeting what they want. The stakeholders respond, and the business analyst writes the requests down as dictated, rewrites the requests into the formal organization-defined business requirements document, get it approved, and pass it on to the developers. The developers, seeing this, wonder why they can’t simply ask the stakeholders the same question, get the same set of requirements, and start working on them without the interim steps.

As hopefully can be seen, the problem is that the business analyst in the scenario does not really add any value to the transaction between the stakeholder and the developer. Perhaps the business analyst might point out that he or she provided translator services by translating business-speak into tech-speak.  The agile developers say that they can just as easily ask for an explanation of any terms or jargon they do not understand, and there will be less chance that of mistranslation. Again, the question is what value is added?

As a business analyst, in general, not just in terms of agile, we have to know what our value is to the organization, and also to all the parties. What is our value to the stakeholder? What is our value to the solution team?  This is not an insignificant question.  Many business analysts assume that just because they are a business analyst and they are assigned to a project everyone will understand the value they bring.  After all, no one questions the value a Java developer brings to the project.  Remember, though, that the profession of business analyst is very new and as a profession we are still struggling to define our place in the scheme of things.  So if we cannot come up with a universal definition of what a business analyst does (other than practice business analysis) how can we expect that everyone else will share a common definition? 

Even a Java developer has different value on different projects and perhaps even at different times during a project. While the senior line manager is defining the business case, the Java developer may have limited value, for example.  If the primary bulk of the code is being written in C#, the Java developer has less value than the C# developer.  And so forth. 

The issue is, what is your value to the organization?  Can you state it in unequivocal terms?  Can you state it so the organization management not only understands but agrees if you were called upon to do so?

Can you state the value you are adding to the project?  Can you state it in such a way as to gain accordance from the team and stakeholders involved with the project?  Can you defend your value statement if someone does not agree (as in the statement of “I add value by translating terminology” above). 

Once you can define the value you add to the project and to the developers then you will be in a position that any software development approach, even agile, cannot unseat you because they cannot replace your value with anyone but you (or some other equally qualified business analyst). And you don’t have to worry about being booted off the agile island.

I will give you some time to think about your answer and provide a few suggestions later. In the meantime, in the next installment I will address the issue of it being too late. When the die is already cast and the business analyst role is already removed from the software development process, what do you do?  Where do you go?  Answers next.

Wednesday, March 6, 2013

The Business Analyst in Agile Software Development Part 1



I am getting a lot of questions and concerns from business analysts about how business analysts fit into the agile world that appears to be taking over software development, and just about every other thing.  My local grocery store has a sign that says “agile grocery shopping”. I’m not sure exactly what that means. I’ve been afraid to go in and try it.
Because of the interest and uncertainty, I thought I’d do a few blogs on agile and the business analyst, looking at the issue from a variety of different perspectives, both good and bad.
Here is the bottom line according to the agile zealots:  there is no business analyst in agile.  Wow!  Is that harsh! 
I have had many long conversations over the years with agile adherents such as Ron Jeffries, Scott Ambler, and Steve Gordon among others about the subject of business analysts in agile software development and the message was always clear: there is no need of business analysts in agile software development. Why? Because the theory is that the developers will talk directly to the customer, in the form of a product owner or a customer on-site, and need no intermediaries.  To the ardent agilists, a business analyst is just an impediment who offers no value to the transaction. Why would a developer need someone to translate what the business is saying when the developer can talk directly to the business person and not run the risk of miscommunication?
This is not really meant to be a pejorative condemnation of business analysts by these stalwart gurus, although many developers do not have a positive view of the role of business analyst which I will address in my next blog. 
The issue is what does a business analyst do when faced with the situation of the developers and others suggesting that their value to the software development effort is negligible and their services as business analyst are no longer needed?  I have four possible solutions and a bit of positive news in the forthcoming blogs.