詩特林-sterning

The focus of this discussion is on business system analysts (BSAs) even though many of the issues (or flavors thereof) are pertinent to the other analyst types. BSAs typically have experience in a wide range of techniques, including interviewing, structured meeting approaches such as Joint Application Development (JAD), modeling sessions, and model reviews. Good BSAs have a good understanding of the business domain and are typically 損eople persons?  This article covers:

1. Why Have BSAs?
2. The Traditional Activities of an Analyst
3. Business Analysts Gone Awry
4. Towards Agile Analysts
5. BSA as Product Owner?

1. Why Have BSAs?

Why have many traditional organizations adopted the idea of having BSAs on staff?  There are three general reasons, all of which I believe are misguided:

1. Developers can't elicit requirements.  The common stereotype is that developers don抰 have the communication and modeling skills necessary to elicit requirements effectively, and sometimes they don抰 even have the inclination to do so.  At best this is a self-fulfilling prophecy: if you believe that developers can't do this sort of work then you won't give them the training nor the opportunities to gain the skills on the job.

2. Stakeholders can't model and document their own requirements.  In one respect this is true, particularly when stakeholders aren't given any sort of training or support.  With the use of inclusive tools and techniques, and with a bit of training, stakeholders can become active participants in the development efforts.  Yes, project stakeholders still need someone to guide and facilitate their efforts, but they can do the majority of the work. 

3. You need analysis experts. You definitely need to do analysis, but whether you need someone who just does that is a really big assumption.  Agile developers are generalizing specialists, people with one or more specialties, a general understanding of the software process, and a knowledge of the domain.  One of their specialties might be in analysis, or then again it might not.  It is unreasonable to expect everyone to be an expert at every aspect of software development, but it is reasonable to expect IT professionals to have some analysis skills and for some people to have deep skill in this activity (amongst many of their skills).

2. The Traditional Activities of an Analyst

A BSA on a traditional software development project will perform one or more of the following activities:

1. Scope the system. During the initial phase of a project, often called 搃teration zero?or simply the inception phase, BSAs may be the only 揹evelopment staff? assigned to the project. At this point they will work with key project stakeholders to formulate and communicate the business vision, to envision initial requirements, and to scope the project. Their fundamental goal is to get the project focused early by translating the initial high-level vision into something realistic. They may also help to identify potential areas of automation and even to aid in reengineering the underlying business process. 

2. Translate business needs. A major responsibility of BSAs is to work with project stakeholders to translate their requirements into something that developers can understand as well as to translate the resulting questions that the developers have into something the stakeholders can understand. This is an iterative process throughout the project. An important part of this is to the distillation of the differing messages of various project stakeholders into a single, consistent vision. This task often includes significant negotiation and political maneuvering. In this respect a BSA will act as a knowledge integrator. Furthermore, BSAs often find themselves spending significant time in meetings, thereby saving the rest of the development team from this inefficient use of their time. 

3. Translate technical issues. BSAs will also explain technical/architectural complexities to project stakeholders, such as why your HTML-based application can抰 have as slick of a user interface as a Visual Basic application.   BSAs often explain what the developers are doing and why they need to do it, including explanations of the basis of schedules and estimates.

4. Model and document. BSAs will often work with project stakeholders to identify, model, and then document their requirements and business domain details. 

5. Act as a communication broker. BSAs typically have very good connections within the business community and therefore are in a position to help development teams find the right people to work with. 

6. Political mentor. BSAs often help project teams through the political minefields within their organizations, particularly when the BSA has worked within the same organization for several years.

7. Test and validation. BSAs will work with project stakeholders to validate their requirements and analysis models via techniques such as reviews, walkthroughs, and play acting. BSAs will often aid in writing user acceptance test (UAT) cases and will be a liaison between project stakeholders and your testing organization during UAT.

8. Represent stakeholders. When project teams don抰 have direct access to their project stakeholders, clearly not a good situation, BSAs will act as 搒takeholder surrogates? Typically developers will treat a BSA as the 揷ustomer?from which requirements, domain information, and business priorities are provided. The BSA in turn will work with the stakeholders to obtain information and to verify decisions.  

3. Business Analysts Gone Awry

In theory the idea of having traditional BSAs involved with a project should work quite well, and in practice it often does. The best analysts are organized and great communicators, having the ability to distill the critical information from your project stakeholders out of the 搃nformation noise?that they provide ? often through a wide range of modeling techniques. For many organizations the addition of BSAs clearly improved the quality of the requirements elicitation and analysis modeling. It also opened up communication between the 搕ech weenies?in IT and the 揵usiness morons?that the system was being built for. 

Clearly this was a step in the right direction. However, some very common problems have been known to occur: 

1. BSAs often lack the right skills. Many organizations have difficulties hiring the right people and/or nurturing the right skills in people. The end result is that people are often thrust into the role of BSA but do not have the skills to fulfill that role, nor do they have an opportunity to gain those skills.   

2. BSAs can have undue project influence. A strong-willed BSA may inadvertently influence a project, perhaps by playing down requirements that they don抰 agree with or even influencing architecture decisions by being biased towards one type of analysis technique (such as focusing just on use cases or just on data models). This is particularly dangerous when BSAs act as stakeholder surrogates AND the developers and stakeholders have little interaction other than via the BSA.

3. BSAs can be out of date. Having previous development experience is critical for a BSA because it grounds them in reality. However, it may also lead them astray. For example someone with a data-intensive background may struggle when working with a development team that is using object technology (and vice versa) because they don抰 know which issues they need to focus on.

4. BSAs can act as a communication barrier. Although BSAs can act as a communication bridge between the two groups they also act as a communication barrier. On the Agile Modeling (AM) mailing list Ron Jeffries depicted the communication approach of traditional BSAs to look like 搒takeholder => BSA => developer => BSA => stakeholder? This looks a lot like the game of telephone tag, doesn抰 it? When you play this game you quickly discover that the signal degrades between hops, decreasing the chance that the actual message gets through successfully. Although a highly skilled BSA, one with excellent communication skills, will reduce this problem it will never go away completely.

5. BSAs can reduce stakeholder influence. An interesting implication is that your project stakeholders don抰 have as much influence over the software as they may think. They抮e influencing the traditional BSA, and the models and documentation that the BSA creates, but have no direct influence over what the developers are creating. This can even be said of user interface prototyping efforts, particularly when those efforts are led by a traditional BSA.

6. BSAs often over analyze.   Another inherent problem with traditional BSAs is their tendency to actually do their perceived jobs. What? When you specialize in something you will naturally focus on that task. The implication is that the task of business analysis will be stretched out, instead of Iterating to Another Artifact as AM suggests, such as a design model or even source code, a BSA will likely focus on expanding the artifacts that they specialize in. Not only is your development effort likely to devolve into a more serial process, instead of an evolutionary approach, the BSAs are likely to develop more documentation than is required.  Your goal should be to create models and documents which are just barely good enough.

7. BSAs can reduce feedback. When analysts are only responsible for analysis efforts, for creating models and documents that are meant to be handed off to developers, there is less opportunity for feedback. There is the danger that they will create theoretically sound models, and make unrealistic promises based on those models to your project stakeholders, that don抰 work in practice. The feedback of people working with software is critical, feedback that you can抰 get from models and documents. The BSA quickly learns what actually works, and from the resulting changes requested by stakeholders quickly improves their analyst skills because they recognize mistakes they made.

8. BSAs can reduce opportunities for developers to gain communication skills. With traditional BSAs in place developers aren抰 given as many opportunities to improve their own communication skills, skills that are critical to success in today抯 environment. Nor are they given the opportunity to work closely with business experts, opportunities that would allow them to learn about the nuances of the business environment and thus increase the chance of them building a system that actually meets their users needs. Nor are they given the chance to discover that the 揵usiness morons?are actually pretty smart after all, with interesting knowledge worth learning. Similarly, project stakeholders miss the opportunity to learn about how software is developed, arguably a good thing in some organizations, and to discover that the 搕ech weenies?are actually very interesting people. Houston, we have a problem.

4. Towards Agile Analysts

Fundamentally the activities performed by traditional BSAs are varied, but a crucial goal was always to improve the communication between developers and project stakeholders.  In many 搕raditional?organizations that meant that BSAs formed a bridge between the two groups, a definite improvement in many situations, although at the same time erected barriers.  Now is the time to take the next step, to become more agile and have BSAs become the communication mentors/coaches on project teams.  This isn抰 to say that every existing BSA is qualified to become a communication mentor, but chances are that your pool of BSAs is a good place to start looking for likely candidates.

• One room ? Developers and Stakeholders are Co-Located

• Over the wall ?Single Location But Not Co-Located

• Across the network ?Dispersed/Distributed Development

4.1 One Room ?Developers and Stakeholders are Co-Located

First, let抯 assume that you are able to co-locate your development team with your project stakeholders, an ideal situation that you should always strive to achieve. In this situation an agile BSA should be just another one of the developers on the team, likely leading requirements and analysis modeling efforts as needed. They would actively work to facilitate communication within the team, mentoring developers in BSA skills and perhaps even mentor project stakeholders in development skills. Ron Jeffries says it well in his article ?a >Business Analysis in Extreme Programming?

This begins with a simple change of focus, from "We'll go out and find out what the customers want and bring it back", to "We'll go help the customers figure out what they want, so they can tell us". This change of focus leaves control in the hands of the customers, and makes all the difference.  

A critical skill that an agile BSA brings to the table is the ability to investigate and understand how the business actually works, as opposed to how developers think it works or want it to work, an ability that they should be able to mentor developers in. When co-located, Agile BSAs would also perform non-BSA activities as well, perhaps pair programming with one of the developers on some of the business code or working with users to develop acceptance tests.  This way the agile BSA would grow his or her own skill set over time and would help others to do so as well. 

An implication of this approach is that the 搕raditional BSA?is getting dropped in favor of a developer with very good communication skills. This reflects AM抯 philosophy that good developers are generalizing specialists, people who have a general understanding of the complete software development lifecycle and one or more specialties: in this case business system analysis. The danger of this approach is that the BSA can抰 be in the role of 揷onflict arbiter?when developers and stakeholders don抰 see eye to eye ?the BSA is a developer and therefore is likely to be seen as biased in such situations. Conflicts would need to be resolved by the project manager/coach or one or more senior project stakeholders.

4.2 Over the Wall ?Single Location But Not Co-Located

A common situation is for project teams and project stakeholders to be located in the same building but not together ?perhaps the project team is one floor and the stakeholders are on different floors. Furthermore, the project stakeholders are typically not available on a full time basis to the project team. Common scenarios include stakeholders that can co-locate one or two days a week and be available as needed on other days; stakeholders that can be available for physical and teleconference meetings several times a week; and stakeholders whose availability is severely limited and often can only give you an hour or two a week. Clearly none of these scenarios are ideal, but unfortunately they are all too common.

In these situations the agile BSA takes on some of the aspects of a traditional BSA. In particular, in situations where the stakeholders are not able to partially co-locate with the development team the BSA will need to work with them in their own environment. This will likely entail modeling sessions and interviews with the project stakeholders. The Agile BSA will typically bring one or two other developers with them to these sessions, that way the developers can not only learn the business knowledge that they need they can also gain BSA skills in the process. This will also help to build bonds between the developers and stakeholders.

The agile BSA will also model a bit ahead of the team, gathering the information which they need a few days or weeks before it's actually needed: too much modeling ahead may result in the sort of wastage seen with a big requirements up front (BRUF) approach.

4.3 Across the Network ?Dispersed/Distributed Development

In this scenario the project team is located in a different location than their project stakeholders, and in the extreme the project team itself is in several locations as are the project stakeholders. Large organizations, consortiums of organizations, and organizations that outsource development to other companies (often overseas) often find themselves in this situation. I highly suggest that you avoid distributed development situations such as this because of the increased communication risk inherent in this approach. When a team is dispersed/distributed the opportunities for face-to-face discussion, the most effective way to communicate, are reduced. Instead you are forced to rely on less productive communication strategies ?such as video conferencing, telephone conversations, and written documentation ? and thereby dramatically increase project risk. Rich communication between developers and project stakeholders is a fundamental aspect of agile software development. It is possible to take an agile approach in these situations, as Alan Wills describes in Dispersed Agile Software Development and Dispersed eXtreme Programming, but it抯 very hard.

In this situation the role of an Agile BSA devolves into something closer to that of a traditional BSA, that of trying to bridge the gulf between developers and project stakeholders. They would realize that this situation is not in the best interest of the project, that they really want to have the project stakeholders working with the developers and therefore should try to get these people together as often as possible. Perhaps they抣l facilitate conference calls, video conferences, and online meetings between the two groups. Perhaps they抣l help to arrange periodic co-locations where some project stakeholders travel to the developers, or vice versa, to enable some direct interaction between the groups.

5. BSA as Product Owner?

A business analyst make take on the role of "product owner" on a Scrum project.  In Scrum the product owner is the single person whom is responsible for prioritizing the team抯 requirements.  Yet, as Figure 1 shows, in practice there proves to be two critical aspects to this role: first as a stakeholder proxy within the development team and second as a project team representative to the overall stakeholder community as a whole.  Although the role of product owner is close in some ways to that of the traditional business analyst what they produce is often significantly different.  Product owners facilitate communication, which means they will be actively involved in modeling and will inevitably produce some documentation, but they will do so agilely. Product owners clearly need to be skilled in agile business analysis in order to identify stakeholder needs, negotiate priorities between repeating stakeholder factions, and then collaborate with developers to ensure that the requirements are implemented effectively. 

Figure 1. Scaling the role of Product Owner.

Although a traditional business analyst could fill the role of product owner, particularly those from the business side of your organization, there is a significant risk that they will fall into their old habits of communicating via documentation.  The traditional software development community has significant cultural barriers to overcome when it comes to modeling and documentation, and as a result experienced business analysts often struggle to fit into agile teams.  Like I said, we need to do business analysis on agile projects but that doesn抰 imply that we need specialized business analysts.

6. Recommended Resources

• Active Stakeholder Participation  
• Agile Analysis
• Agile Best Practices for Data Warehouse (DW)/Business Intelligence (BI) Projects
• Agile Requirements Modeling
• Agile Requirements Change Management
• Best Practices for Agile/Lean Documentation
• Examining the "Big Requirements Up Front (BRUF)" Approach
• Generalizing Specialists: Improving Your IT Career Skills
• Initial High-Level Architectural Envisioning
• Initial High-Level Requirements Envisioning
• Rethinking How You View Requirements Management
• A UML Profile for Data Modeling

		The Object Primer 3rd Edition: Agile Model Driven Development with UML 2 is an important reference book for agile modelers, describing how to develop 35 types of agile models including all 13 UML 2 diagrams.  Furthermore, this book describes the techniques of the Full Lifecycle Object Oriented Testing (FLOOT) methodology to give you the fundamental testing skills which you require to succeed at agile software development.  The book also shows how to move from your agile models to source code (Java examples are provided) as well as how to succeed at implementation techniques such as refactoring and test-driven development (TDD).  The Object Primer also includes a chapter overviewing the critical database development techniques (database refactoring, object/relational mapping, legacy analysis, and database access coding) from my award-winning Agile Database Techniques book.
		Agile Modeling: Effective Practices for Extreme Programming and the Unified Process is the seminal book describing how agile software developers approach modeling and documentation.  It describes principles and practices which you can tailor into your existing software process, such as XP, the Rational Unified Process (RUP), or the Agile Unified Process (AUP), to streamline your modeling and documentation efforts.  Modeling and documentation are important aspects of any software project, including agile projects, and this book describes in detail how to elicit requirements, architect, and then design your system in an agile manner.
		The Elements of UML 2.0 Style describes a collection of standards, conventions, and guidelines for creating effective UML diagrams. They are based on sound, proven software engineering principles that lead to diagrams that are easier to understand and work with.  These conventions exist as a collection of simple, concise guidelines that if applied consistently, represent an important first step in increasing your productivity as a modeler.  This book is oriented towards intermediate to advanced UML modelers, although there are numerous examples throughout the book it would not be a good way to learn the UML (instead, consider The Object Primer).  The book is a brief 188 pages long and is conveniently pocket-sized so it's easy to carry around.

7. Let Me Help

I actively work with clients around the world to improve their information technology (IT) practices as both a mentor/coach and trainer.  A full description of what I do, and how to contact me, can be found here. 

You may be interested in my two-day Agile Requirements Workshop: Something Old, Something New, Something Borrowed, Nothing Blue.