As more organizations move toward agility, development and project management teams still struggling to define a common language and standard regarding the agile framework. In addition, many organizations that are implementing agile approaches have not fully planned the transition and are still unclear on how to fully optimize the approach. One area that continues to remain vague is the role of the Agile Lean Business analyst (ALBA). Below are some steps to help business analysts navigate the way through their transitioning to Agility and add the utmost value to their agile delivery teams.
UNDERSTANDING THE AGILE MINDSET
Any business analyst practicing in an agile environment must first have a basic understanding of the agile mindset and why it was established. The Agile Extension of the BABOK Guide describes Agile as a mindset that guides the way work is approached. Key characteristics of the agile mindset includes rapid delivery, increased collaboration, empirical learning, avoiding waste, and producing high-quality products. While agile practice date as far back as the 1960s, the mindset was formalized in 2001 when the Agile Manifesto was published as shown below.
12 principles behind the Agile Manifesto
In addition to learning the concepts of the Agile Manifesto, agile business analysis practitioners must also recognize the 12 Principles behind the Agile Manifesto. Understanding these principles will help agile team members determine how to facilitate the many interactions involved in software and project management. This is especially important in maintaining the overall essence of the framework. Less rule-based approaches can often be misconstrued if the founding principles are not emphasized.
UNDERSTANDING AGILE FRAMEWORKS
Another key component in agile business analysis is understanding that the term Agile is a high-level framework with various defined frameworks that fall underneath. Some of the most frequently used agile brands include Scrum (most common agile framework), eXtreme Programming (XP), Kanban, Crystal Methods, Scrumban, Feature Driven Development (FDD), Dynamic System Development Method (DSDM), Large Scale Scrum (LeSS) and many others. It is important to learn about the various agile frameworks because organizations need to assess the frameworks and employ the one (or combination) that best aligns with the organization. While there will certainly be shifts in organizational operations and culture during the transition to an agile environment, choosing frameworks that complement the existing environment may ease the process.
From the business analyst perspective, learning the roles and responsibilities within these frameworks will assist in setting the proper expectation for new roles or responsibilities. It will also help understand the intended value of the various ceremonies of the frameworks. The business analyst role is not distinguished in some agile frameworks; therefore, it is essential for BAs to understand where their skill set fits so they are able to add as much value possible.
T-SHAPED LEARNING "Cross-functional Teams"
In most agile frameworks variations of three key roles are recognized, which are Product Owner, Team facilitator, and Cross-functional Team Members. Business analysts in an agile environment typically fall into the cross-functional team member role. In order for the business analyst to be successful as a cross-functional team member, he or she must embrace a T-Shaped learning environment. This type of environment encourages team members to be crossed trained in multiple areas. Members add value because they have deep knowledge in one area supplemented by high-level knowledge in a broad range of other areas. This provides the flexibility for team members to pick up work throughout the entire software development life cycle as well as shift work to the highest priority tasks when needed.
Business analysts on agile teams who feel underutilized will need to discuss the issue with the team facilitator to determine what additional skills can be picked up to add more value to the team. Most cross-functional team members are composed of business analysts, developers, and testers. The image below illustrated the T-shaped learning model for a cross-functional agile team.
Business analysts in cross-functional teams can add significant value when they take on the following responsibilities:
Many business analysts have found that Product Owners (PO) have assumed many of the traditional BA responsibilities. This is another area where the business analyst skill set can add significant value. Many product owners are appointed because of their significant business knowledge, however, if not formally trained, many of them lack the project related skills to be fully effective. Team members with a BA background will need to train and support the PO on tasks such as developing business cases, writing user stories, cost/benefit analysis and writing test cases. Some business analysts in agile environments have even transitioned to the product owner role, however, it is generally best to keep the two roles separate.
One thing to note about the business analyst role in agile is that even though the BA title is marginalized, the BA skill set is emphasized. This means that the skill set and responsibilities of the traditional BA are distributed to many different roles on the agile team. Agile business analysis practitioners will need to become comfortable with the fact that requirement elicitation activities will no longer be the sole responsibility of the BA and other team members will need to be trusted with these tasks as well.
AGILE REQUIREMENTS MANAGEMENTLess formal documentation
In agile environments, working software is valued over comprehensive documentation. Contrary to popular belief, this does NOT mean that requirements don’t need to be documented. However, this does mean that requirements are often less formal. Many agile frameworks manage requirements in the form of a product backlog. Here, requirements are usually represented in the form of user stories with acceptance criteria. The BA may need to support other team members to ensure that user stories are usable and that there is a sufficient amount of acceptance criteria to size the story and move it into the upcoming iteration. In addition, the stories in the backlog must be prioritized based on value to the business. While the product owner is generally responsible for the priority of the stories, the BA can add value by assisting the PO to determine the value (cost/benefit) of each story. An agile business analyst may also be a great resource to the product owner when determining the minimum viable product (MVP) for the project.
Due to the fact that agile software development emphasizes elicitation through a working software, it would behoove the agile business analyst to sharpen up on wireframe and prototyping tools in an effort to quickly obtain rich feedback from the customers. In addition to obtaining feedback quickly, business analysis in agile environments involves adapting to a flexible scope. While there is some level of scoping in agile business analysis, the scope of the solution may change as new information is discovered or the organization's priorities change. This requires an agile BA to be flexible enough to quickly course correct, re-prioritize, and elicit new information based on what was learned from customer feedback.
AGILE BA TECHNIQUES
Agile business analysis practitioners many need to expand their BA toolkit to include techniques that are more suitable for an agile environment. Agile business analysis techniques are less focused on research and more focused on experiments and collaboration. Agile BA techniques facilitate knowledge transfers between different planning horizons (Strategy, Initiative, and Delivery), where the feedback obtained in one horizon provides direction to another horizon before moving forward. Below are high-level descriptions of frequently used techniques in agile business analysis:
Culled from https://modernanalyst.com/Resources/Articles/tabid/115/ID/5196/Adding-Value-as-an-Agile-Business-Analyst.aspx