Tuesday, 22 June 2010 07:26

The Business Analyst Facilitator Role in an Agile Software Development Team

Written by
Rate this item
(8 votes)

The purpose of this article is to define the need for the business analyst facilitator role in an agile software development team. Traditionally the business analyst role has been defined in the context of a project, utilizing the waterfall solution development life cycle (SDLC). This approach has the business analyst collecting all the requirements and business rules upfront prior to development. However, today's demand for accelerated solutions has changed the dynamics of system development to a more agile approach, where requirements and business rules are defined in conjunction with solution development in iterative cycles. Hence, the question - "Is there a need for a business analyst role in an agile software development team?"

Some readers of this article may believe that the business analyst role is not needed with the agile approach. To those of this position, I encourage you to read on. I suggest regardless of the SDLC chosen (waterfall or agile), the role of the business analyst is still needed. As a developer, you may say, "but we are doing fine on my agile project without a BA role." To you I ask, "Have you examined your expanded role of directly interfacing with stakeholders?" For the past 40 years in the IT business, I have experienced several approaches to solution development. One rule that does not seem to change is that regardless of the SDLC used, functions that roles provide remain. In the agile case, BA functions are absorbed by members of the software development team at some risk.

Please note, I am assuming that the reader is familiar with waterfall and agile SDLC approaches, so I will not attempt to define them in detail in this article. For the purposes of this article, a Scrum like process for the agile approach is used.

As an instructor of business analysis techniques and practices, I often field questions on the role of the business analyst (BA) in an agile software development team as opposed to the traditional waterfall solution development life cycle (SDLC) approach. After much thought and input from many sources, I am convinced that the role of the business analyst facilitator is needed in an Agile Software Development Team.

The Role of the BA Facilitator

The role of the BA facilitator is to guide activities on developing both the vision and software solution. The key word here is guide. The BA facilitator role provides process to group settings and avoids participating in content. Typically, the BA facilitator role serves as the liaison between stakeholders, and the stakeholders and software development team respectively. As the liaison, the BA facilitator role uses various techniques and emotional intelligence skills to assist project sponsors and/or team leaders in accomplishing group meeting goals:

  • Facilitation Techniques for Identifying Solution Features
    • Creating a Solution Vision and Scope
      • Brainstorming - discussing of ideas
      • Brainwriting - submitting written ideas for discussion
    • Eliciting Features and Associated Business Rules
      • Focus Group Meetings - soliciting opinions
      • Joint Application Design - resolving conflicts
    • Analyzing Features - Assumptions, Constraints, Risks, and Issues
      • Root Cause - five whys, Ishikawa Diagrams
      • Force-Field - listing negative and positive influences
      • As-Is and To-Be Gap
    • Making Decisions on Features and Priorities
      • Multi-voting - subjective paring down a long feature list
      • Criteria-Based Grid - weighting feature value criteria
      • Impact/Effort Grid - comparing feature benefits versus effort
  • Emotional Intelligence Skills for interfacing with stakeholders
    • Active Listening and Paraphrasing
    • Generating Participation
    • Neutrality - focus on meeting process instead of solution content
    • Questioning - seeking answers rather than posing solutions
    • Maintaining Focus - use a parking lot and issue log for off agenda topics
    • Obtaining stakeholder feedback
    • Summarizing and synthesizing Ideas
    • Conflict intervention

Under the agile SDLC, the BA facilitator role contributes in two main activities: Continuous Vision and Scope Sessions, Iterative Software Development Meetings and Workshops.

Every project starts with a vision and scope of the solution to meet a business need. This vision may be definitive or fuzzy. However defined, the vision will reflect a prioritized set of high-level solution features that is essentially the scope of work to be done by the software development team. In the agile approach, defining the vision and scope is a continuous set of sessions. Each session represents a snap-shot of the vision and scope at that time determined by the stakeholders. These sessions manage the scope of solution features either as additions, changes and/or refinements until the stakeholders complete their vision.

These vision and scope sessions are chaired by the project sponsor. The challenge for the project sponsor is to ensure that the project vision and scope is a collaborative effort among all the stakeholders, hence the need for the BA facilitator role. The role of the BA facilitator is to assist the project sponsor by providing and executing session plans. Each vision and scope plan consists of:

  • ensuring the correct participants attend
  • accounting for meeting risks
  • arranging for an adequate facility conducive to collaboration
  • setting an appropriate agenda

This agenda contains facilitation techniques that will lead the stakeholders to a consensus on a prioritized set of high-level solution features to be pursued by the software development team. During the session, the BA facilitator role uses emotional intelligence skills to ensure that all stakeholders participate and that their ideas are respected. The BA facilitator role ensures through "questioning" that the features are justified and can be traced back to the business need. Note that all features are subject to the approval of the project sponsor - chair of the session.

Iterative Software Development Meetings and Workshops

After the initial vision and scope features are determined, the Software Development Meetings begin with a consensus on which of the prioritized set of high-level features will be developed on the first iteration. Once a finite set of features is selected and time-boxed by the software development team, then a series of follow-on status meetings are held addressing progress and the removal of impediments. Between these status meetings, the software development team holds workshops with stakeholders to develop the solution. These iterative workshops conclude with a validation meeting of the developed solution and a decision on implementation by the project sponsor. In summary,

  1. Select vision and scope features from prioritized list
  2. Develop a solution for this iteration within a time-box
    1. Conduct workshops producing prototypes
    2. Hold status meetings on progress
  3. Validate final prototype and implement with project sponsor approval
  4. Return to step one for further features and add rework as needed until feature list is exhausted

Note that with implementation, the iterative software development meetings are renewed by another selection of prioritized high-level features to address. These features may have been changed by the stakeholders in the meantime by further vision and scope sessions held in parallel with the software development meetings.

The feature selection and status meetings are chaired by a team leader similar to a project manager. In these meetings, the team leader faces the same challenge as the project sponsor - ensuring that solution development is a collaborative effort through consensus. Once again there is a need for a BA facilitator role. As in the vision and scope sessions, the role of the BA facilitator is to assist the team leader by providing a plan for each meeting and executing that plan.

The software development team is self-directed and/or self-organized. The team runs the workshops according to their skills and experience, rather than using a set plan by the team leader. The workshops are direct conversations between the software development team and the stakeholders. These workshops involve vital business and technical details in developing the solution:

  • User and system functional requirements
  • Associated business rules
  • Information needed to be managed
  • User Interface
  • Technical implementation methods

Both what needs to be developed and how it is to be implemented are discussed at the same time during the workshop. As a result of these discussions, the development team provides a solution through a series of prototypes each tested with direct stakeholder feedback. The final prototype (for this iteration) is then validated and approved by the project sponsor for implementation. A new cycle then starts with the selection of further features from the vision and scope including possible rework items....etc, etc, etc.

In the workshops, the role of the BA facilitator is different from the previous planning meetings. During the planning meetings, the BA facilitator role provided and executed an agenda. The role of the BA facilitator in the workshop is to assist the stakeholders and the software development team to determine system requirements from stated user requirements for the purpose of building prototypes. The software development team uses these prototypes to build an incremental solution.

The BA facilitator role accomplishes the above by using an expanding BA tool which includes:

  • Business Modeling Tools for identifying and analyzing user requirements, system requirements, and business rules
    • Activity Workflows with Swim Lanes - manual processes
    • Use Case - user / system dialogue - system functional requirements
    • Storyboard - user / system interface - screen flows
    • Entity-Relationship - organizing information used by the system
    • State Change - information changes as it proceeds through processes and systems
    • Class / Object - use for Object-Oriented implementations

The thoroughness with which Business Modeling is used by the BA facilitator role is tempered by the needs of the software development team. Rather than comprehensive documented requirements as in the waterfall SDLC, the BA facilitator role generates "just enough" documentation as needed by the software development team to code the prototypes.

Conclusion - Formal BA Facilitator Role "Just Ensures"

Whenever solution features are being defined, prioritized, analyzed and/or developed, the BA facilitator role is used naturally to ensure stakeholder buy-in and acceptance of the final solution. Whether it is the vision and scope sessions, the iterative software development meetings or the workshops, the BA facilitator role may be taken on by a member of the software development team. However, consider the risk involved in building a consensus with someone less trained and experienced in BA facilitation. The level of productivity and consensus is directly dependent on effective use of the BA facilitator tool set. In addition, there is a risk that the stakeholder and the developer will focus on the technical aspects of the prototype rather than requirements. It is prudent to avoid this risk. To "just ensure" the success of the team, a formal BA facilitator assisting the agile software development team needs to be that best practice.

Don't forget to leave your comments below


Mark A. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSMTM) and Certified Scrum Product Owner (CSPOTM) by the Scrum Alliance. He holds an Advanced Master's Certificate in Project Management and a Business Analyst Certification (CBA®) from George Washington University School of Business. Mark is also a member of the Association for the Advancement of Cost Engineering (AACE) and the International Association of Facilitators (IAF). Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail - mark.a.monteleone@sbcglobal.net.

This article first ran in the IIBA newsletter February 2009.

Read 52587 times
Mark A. Monteleone

Mr. Monteleone holds a B.S. in physics and an M.S. in computing science from Texas A&M University.  He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®), a Certified Business Analysis Professional (CBAP®) by the International Institute of Business Analysis (IIBA®), a Certified ScrumMaster (CSM) and Certified Scrum Product Owner (CSPO) by the Scrum Alliance, and certified in BPMN by BPMessentials.  He holds an Advanced Master's Certificate in Project Management (GWCPM®) and a Business Analyst Certification (GWCBA®) from George Washington University School of Business.  Mark is the President of Monteleone Consulting, LLC and can be contacted via e-mail - mark.a.monteleone@sbcglobal.net.

Comments  

0 # leslie munday 2010-06-22 09:38
How is the BA different to that of the Scrum Product Owner? Or to put it another way, which of the Product Owner activities could not be performed using the skills of a BA? Les.
Reply | Reply with quote | Quote
0 # Curtis Reed 2012-06-20 13:04
I have worked as BA on a scrum team that also had a Product Owner (PO), and now I'm a Project Manager (Scrum Master) on teams where the BA is also the PO. Think of it this way: in some situations, the PO is a product manager who may spend time on the road with clients gathering information about what they need for a product. In this case, the BA will meet with the PO and they will work to create the backlog and the BA will elicit information to ensure the Stories are closed, complete, and have adequate acceptance criteria. The BA may then "backfill" the PO while the PO is on the road.
Where I work currently, the BA also wears the PO hat, speaks with the customers directly, writing stories/accepta nce criteria, and explaining everything to the team at the Kickoff and Backlog Grooming, Iteration planning etc.
As you can imagine, there are some folks who make good product owners, but lousy analysts, and vice versa.
So in that situation, the BA is the liaison between the Product Owner and the team and ensures that the stories accurately describe what the PO and the clients want.
Reply | Reply with quote | Quote
0 # Simon Papson 2010-06-22 10:07
Les, My (admittedly limited) understanding is that the Product Owner as defined in Scrum is a Business Analyst under a different guise. "What's in a name? That which we call a rose, by any other name would smell as sweet." Simon
Reply | Reply with quote | Quote
0 # Curtis Reed 2012-06-20 13:08
that may be true in some cases, but it's a gross over simplification. A Product Owner (PO) is the representative of the Stakeholders/Cl ients, understands what they want/need, and helps guide the team in that sense, and approves the work being done prior to the Demo, which is when the client sees the work about to be released.
Sometimes, the PO can perform both roles, but not always. Have you ever known a Product Manager who "knew" what needed to be done but was LOUSY at writing clear requirements? The BA elicits that information and converts what the PO "knows" so the rest of the team can understand it.
It can be DANGEROUS to assume that "hey, we are agile, so the PO can be the BA without any consequences". Both roles require specific skills that the PO may--or may not--have.
Reply | Reply with quote | Quote
0 # Mark A. Monteleone 2010-06-22 10:29
Thanks for your question on the BA vs. the Scrum Product Owner. In discussing the role of the Product Owner with several agile practitioners, many stated that the BA takes over the Product Owner responsibilty of interfacing with the development team and managing the Product Backlog. Particularly on large projects, the Product Owner role is split. The Business Product Owner looks outward from the business and monitors customer needs in the market while the BA translates the vision of the Business Product Owner into the Product Backlog for the development team.
Reply | Reply with quote | Quote
0 # Curtis Reed 2012-06-20 13:09
That description is quite good, and I have seen that division personally work quite well.
Reply | Reply with quote | Quote
0 # David Wright 2010-06-22 12:50
Boy, this is a lot or roles and methodology to make up for the situation where requirements are not being defined fast enough for accelerated software delivery. Would it not be simpler to fix the problem with defining requirements fast enough, then let development get on with designing and building the solution? You may scoff and say the nature of "traditional analysis" can never be sped up, but I would return with the supportable premise that fast requirements is a real option, one that is being used by many Fortune 500 companies today. C'mon, won't you admit that having clear, correct, complete, validated requirements before you start design would make things so much easier? Give experienced requirements professionals a few weeks and you can have them.
Reply | Reply with quote | Quote
0 # Curtis Reed 2012-06-20 13:39
I have seen cases where the PO and the BA are working on upcoming user stories that will be worked on weeks in advance, as you stated, giving them time to work through the requirements written as User Stories with Acceptance Criteria. So being Agile does not always preclude having time to analyze requirements, that is a misconception.
However, note that there are instances in which extremely rapid development must occur. Imagine a team hired to develop a solution that must be released in two weeks. In this case, the cycle is so short, there is no lead time for business analysis: User Stories are elicited with the customer present and discussed with the whole team present, and development may occur literally within minutes of the stories being identified.
I have rarely seen this done, but it can occur. What makes up for the lack of detailed analysis is the constant involvement of the client/stakehol ders daily, even hourly, as they see progress, provide input, change the direction/make corrections. This is truly "managed chaos" and can make some individuals uncomfortable until they become used to the process. If it is done well, it can be VERY exciting to work on projects like these!
Reply | Reply with quote | Quote
0 # laith 2010-06-22 17:08
Great article, it answers alot of questions that i have in my mind about agile methodolgy. you said "defining the vision and scope is a continuous set of sessions" so how could the BA anticipate the time required for completing this phase ? does the developer involved on this phase to define the scope of the project ?
Reply | Reply with quote | Quote
0 # Curtis Reed 2012-06-20 14:20
Vision should change less frequently, as it is a higher level strategic guide of the direction the project is going. I would be a little concerned if Vision changed frequently, but sometimes as market needs change, Vision can change with it. Of course, if Vision changes, Scope is downstream and will have to be re-negotiated.

As for Scope-changes.. .this can happen quite frequently. Imagine a team developing a reservation page for a Hotel. they identify all the features they want, and must have in 6 weeks. The team works with the client to prioritize, creates an iteration and release plan, and finds that a couple of features can't make it during that period. They re-negotiate and a couple of "nice to have" items get bumped.

Now imagine 1/2 way through the client finds another "must have" feature. Re-negotiation happens and they need to get the client to push out or give up something to keep the release on track. So whereas Waterfall projects may push out the release week after week as Scope increases, Agile will often push out features to a future release and keep the High Value items on track for the desired date. Good PO/BA work will enable the client to assign value to all features and decide what can be dropped, or pushed out, and at what cost.
Reply | Reply with quote | Quote
0 # Mark A. Monteleone 2010-06-22 22:02
Thanks for your question on time required for defining the vision and scope. In the agile approach, the requirements evolve over the length of the project. Therefore there is no set time for adding new product requirements. What typically happens is that the customer discovers a "fit for use" point in what is delivered and stops the project. One of the observations in agile is that there is a significant reduction in requirements as opposed to waterfall. In waterfall, product owners have a tendency to request everything possible because they expect to sign-off on a formal business requirements document. As a result, product owners in waterfall ask for nonessential requirements. This is why I believe "fit for use" is a good definition for quailiy in agile as opposed to "documented and approved requirements" definition in waterfall.
Reply | Reply with quote | Quote
0 # laith 2010-06-22 23:09
till the client discovers that he/she has reached a 'fit for use' point, we dont face a scope creep as a developement company ???? if no how could the company set the porject cost of an agile projects ??
Reply | Reply with quote | Quote
0 # David Wright 2010-06-23 11:58
"In waterfall, product owners have a tendency to request everything possible because they expect to sign-off on a formal business requirements document. As a result, product owners in waterfall ask for nonessential requirements" That is NOT requirements elicitation, it is just asking somebody want they want. That is an open ended question, one with which you can never be sure you got all the requirements, essential or not. If that is the way you do requirements, you will fail. A Business Analyst needs to elicit requirements that are clear, correct and complete, not just write down somebody's desires. If this is what you are trying to solve with agile, it seems like overkill to me. What do you do when there is no development? You want to reuse available software, or do an RFP for a COTS solution. Agile won't help with that...
Reply | Reply with quote | Quote
0 # Curtis Reed 2012-06-20 14:28
I think you misunderstand. In a Waterfall project, the SRS generally contains ALL the features of the complete system, and very often, it is presented as an 'all or nothing' approach. Yes, at times, requirements are identified as "Critical", "Must Have", "nice to have", this is ideal. I think the author meant that as a part of the Agile approach, VALUE is assigned to features, and the team works on the HIGHEST value items first. When all those high value features are released, sometimes the client is satisfied and the project can end, (because the solution is "fit to use") even though there are many "nice to haves" still undone. By contrast, in a Waterfall project, the developers work on the whole package including less important items, even though they really could have delivered a percentage of features and satisfied the customer, collected their money, and gone on to the next revenue generating project.
Mark, if I mis-speak, forgive me. But that is my understanding of his comment.
Reply | Reply with quote | Quote
0 # Mark Monteleone 2012-06-20 16:15
Curtis, I am in full agreement with your comment. Thanks for continuing the dialogue.
Reply | Reply with quote | Quote
0 # Rodolfo Meda 2010-06-28 07:30
Excellent article!. Just one point that I want to express, SDLC lifecycle stills lives in Agile Approches, it must be followed in each iteration, timebox, or wathever you may call it, but the differents "disciplines" are still there. So I do agree that BA role works perfectly as a moderator for Requirements Analysis activities in different stages. Best Regards, Rodolf o http://ar.linkedin.com/in/rodolfomeda
Reply | Reply with quote | Quote
+1 # Mark A. Monteleone 2010-07-07 01:52
Rodolfo, thanks for your comment. I noted that you used the word “moderator.” Many people use the word moderator and facilitator in the same context. Actually, there is a big difference. A moderator governs a debate ensuring all parties have equal voice. The purpose is to allow views to be heard, but there is no goal for consensus. A facilitator does much more than a moderator by driving the discussion to a consensus while remaining neutral. BAs are facilitators driving discussions to a consensus on requirements. A good example of the difference was the first presidential debate in the USA a couple of years ago. Mr. Jim Lehrer of Public Television was the moderator between the two candidates. At one point, Mr. Lehrer asked the candidates to face each other and see if they could come to an agreement on an issue. When this happened, I jumped from my couch and stood in front of the TV, pointed a finger at Mr. Lehrer and said, “He just changed from a moderator to a facilitator!” At this point, my wife told me to “shut-up and sit down.” I did.
Reply | Reply with quote | Quote
0 # leslie munday 2010-10-23 09:45
One issue that I rarely (if ever) see discussed in an Aile environment is the constant refactoring that must occur if the team is to maintain quality software. If working in a waterfall environment, all the software development can (in theory) be planned up front and a full architectural design be created into which the functionality is implemented. I f you have not defined all of the requirements up-front before starting design, how do you know that a requirement on a future iteration is not going to have architectural implications? My solution: Use a RUP-like approach - identify as many requirements as possible before doing design. Detail those requirements that are going to have architectural impacts (interfaces to other systems for example). Design an architecture. Then prioritise the requirements and assign them to iterations (or sprints, or whatever). Requirements are detailed in parallel to the software development according to a priority. So, if you don't identify requirements up front, how much more effort is involved through re-factoring?
Reply | Reply with quote | Quote
+1 # Ali 2012-09-19 01:32
I have been doing traditional BA activities based on waterfall and iterations. Just to add on more to what Leslie has mentioned;
Does anyone has answer for the following issues?
1--What if something is developed using Agile and then the maintenance phase kicks in. A new team takes over due to some reason to develop code in maintenance. In this case there is no trace of requirements. Won't there be any issues?
2- Is bare minimum doc enough to define all the scenarios required for development and testing. For example details on user screens, business rules, alternate scenarios, data definition, label dictionaries etc.
3- What about excellent design of DB and Software when all the requirements are captured and signed off in waterfall.

What i feel is Agile approach might be beneficial for already made app or products when further enhancements are going on , but that too have a question mark in terms of re-work.
If there is development from scratch for new project or new app or new product, I would prefer going for waterfall +iterations methodology as there would be detailed information for DB design, architecture design and re-work will be drastically reduced.
As you all know the cost multiplies 10 or more folds when something is changed on production server.
Any thoughts?
Reply | Reply with quote | Quote

Add comment

Security code
Refresh

search Articles

© BA Times.com 2016

DBC canada 250