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,
- Select vision and scope features from prioritized list
- Develop a solution for this iteration within a time-box
- Conduct workshops producing prototypes
- Hold status meetings on progress
- Validate final prototype and implement with project sponsor approval
- 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 – [email protected].
This article first ran in the IIBA newsletter February 2009.
The purpose of this brief article is to laugh. Laugh about how we as business analysts approach our work. Whether you are a proponent of agile, waterfall, or some hybrid solution development life cycle (SDLC), I hope this article makes you laugh. Remember laughter is the best medicine.
The purpose of this article is to provide business analysts with further insight into why writing requirements must be a conscious effort of using an elaborative language. This elaborate language provides details through the use of specifics and metrics, where possible. Because business analysts work inside business area bubbles, it is their nature to write in a restrictive language that assumes everyone understands the nuances of their words. They naturally speak in a condensed code and therefore write requirements in the same condensed format. As a result, they unconsciously imply additional meanings to their words. Unfortunately when their documents are handed-off to systems analysts, who just happen to live in a different bubble, the requirements are misinterpreted.
