Agile development methodologies are leading the way, helping software development teams across Banking, Finance, Technology and Engineering adjust to the new economy.
Agile challenges our notion of software engineering best practices, project management methodology, and how we lead our teams. The Agile movement impacts every role on a project team differently and creates opportunities to learn new skills and develop new ways of working together.
Agile development is having a significant impact on the Business Analyst community. Agile introduces a significant shift in how teams look at requirements and when they are defined in the process. Agile Business Analysts are an integrated part of the team throughout the life of the project and facilitate collaboration across a broader cross section of the project team and the business. Collaboration, facilitation, leadership, coaching, and team building become significant new skills required for Business Analysts on Agile projects. Leadership and collaboration are key components critical to their success. With these new skills and new ways of looking at the development process, Business Analysts are well positioned to become critical to the success of Agile teams.
Moving from traditional project work to agile project work will impact each functional role on a project team differently:
- For Business Analysts (BA), successfully managing an agile project depends on defining requirements in smaller increments and working more collaboratively with the team through the life of the project.
- For Project Managers (PM), success moving to Agile development methodologies depends on acquiring the skills necessary to progressively plan a project through its lifecycle rather than at the onset. Project Managers will also need to adopt new ways of understanding project control and risk.
- For Quality Testers, evolving to an agile framework will mean developing the skills necessary to write tests and validate code in parallel with development.
- This paper will explore the impact agile development methodologies are having on the BA community, what new skills are required, and what BAs can do to ease the transition. Traditional Requirements Definition Business Analysts are conditioned to believe that they can and should define detailed requirements at the beginning of a project. Inherent in this philosophy are several challenging assumptions.
Traditional requirements analysis:
- Assumes that the customer can definitively know, articulate, and functionally define what the system or software should do at the end of the project
- Assumes that, once documented, the requirements will not change – at least not without potential project delays, budget overruns, or stunted feature sets
- Assumes that the requirements process is confined to a single product owner who sits apart from the development team envisioning the product• Does not acknowledge the inherent uncertainty in software development that Agile methodologies seek to embrace.
Experience tells us that these assumptions are faulty. As we learn more about the evolving system, our knowledge will influence the system we want to build. The process of building the system helps the team learn more about what is possible. The very act of creating the requirements will cause them to change. Agile methodologies encourage us to embrace this kind of adaptation in our projects. We begin to realise that change really is good, it helps us deliver greater value to our customers and attempting to define everything up front results in constant change management. To fully understand the impact that Agile has on the Business Analyst role, it is helpful to understand how Agile projects are run.
Agile Project Management Explained
Agile Project Management assumes that the processes required to create high-value working software in today’s economy are not predictable: requirements change, technologies change, and individual team member productivity is highly variable. When processes are not static and outcomes cannot be predicted within sufficient tolerance, we cannot use planning techniques that rely on predictability. Instead, we need to adjust the processes and guide them to create our desired outcomes. Agile project management does this by keeping progress highly visible, frequently inspecting project outcomes, and maintaining an ability to adapt as necessary to changing circumstances.
The benefits of Agile Project Management are derived in part by placing a tremendous amount of responsibility and accountability on the individual team members. There is an understanding that great teams build great software and those teams should be trusted and empowered to deliver. A good Agile Project Manager is an enabler of the team. The Agile PM helps the team stay focused on the larger business issues and removes obstacles that impact the team’s ability to deliver. The focus is on the team because ultimately the team is on the hook for delivery.
Because Agile teams are self-organising and empowered, the Agile PM focuses more on leadership than in a traditional development environment. Skills such as facilitation, coaching, and team building become key components for project success. The PM is creating a culture of empowerment and trust, and an environment where individuals are motivated to contribute to the team’s success. Agile Project Managers focus less on assigning tasks and managing the plan and more on maintaining the structure and discipline of the Agile team; trusting that through visibility, inspection, and adaptation the team will deliver the desired results. This philosophy carries over into the role of the BA and how requirements are collected, distilled, and managed.
As opposed to traditional requirements gathering, where the BA primarily works with the product owner to collect specifications, agile team members from all disciplines are involved in defining project requirements.
Technical team members and Quality Assurance (QA) collaborate with the product owner and the BA to develop the project specifications; each bringing their skills and experience into this collaborative process.
Increasing the level of interaction ensures the team develops specifications that can be built and tested within the overall project constraints.
To effectively deal with scope on an Agile project, specifications must be considered in two dimensions: breadth first and then depth. It is essential that we understand the breadth of what we want to build early in the project. Dealing with the breadth of the solution helps the team understand scope and cost and will facilitate estimating and release planning. The breadth of a project begins to frame the boundaries of the project and helps to manage the organisation’s expectations. Looking at the breadth of the requirements is a much smaller investment of time and resources than dealing with the entire depth. The details are most likely to evolve as we progress through the project so defining them early has less value.
Having a solid understanding of the breadth of project requirements early in the lifecycle helps the development team begin to define the set of possible solutions. The Business Analyst plays a key role facilitating the conversation between the product owner, executives, the technical team, and the QA team. The BA is a key player in ensuring that the full scope of requirements has been defined and balanced by an overall technical understanding of the solution.
Once the team has established the breadth of the solution, it is time to begin incrementally looking at the depth of the solution. The BA will typically take the lead helping the team bring the requirements down to this next level of detail. To incrementally look at the depth of the requirements, we have to abandon our traditional notions of the, Business Requirements Document (BRD), Marketing Requirements Document (MRD), Product Requirements Document (PRD) and the list of “the system shall” specifications. Instead, we focus on how the system
is going to behave.
Managing Agile Requirements
To effectively manage requirements in a traditional environment, BAs sort through the many-to-many relationships between business needs, specifications, and design elements. Because of the complex interactions between these many-to-many relationships, the requirements management industry has created tools to trace their interdependencies. Out of necessity, the Business Analyst will track the impact of any requirement change to its corresponding design element, or likewise, from a change in a design element back to the requirement. This process can get even more complicated when one traces into the software component, tests, and test results.
Agile is focused on driving toward simplicity rather than creating systems that manage complexity. Because of the nature of agile requirements, we have a planned independence between features. Design is contained within the user story and each story is able to be tested independently, eliminating the need for complex requirements management tools. Agile teams will frequently use specialised management tools to track requirements and manage them through the development lifecycle.
New Skills for the Agile BA
Much like the Agile Project Manager, the Agile Business Analyst will rely much more on people facilitation skills than they may have on traditional projects. The BA’s role is to facilitate a discussion between the product owner and the technical team. The BA will typically bring a tremendous amount of system knowledge to the discussion and is well positioned to draw out functional requirements from the product owner. BAs can also help translate user needs into more technical language for the developers.
In addition to facilitation, coaching, and team building, the agile BA needs to think about the software development process in new ways. Agile encourages us to decouple the breadth of the solution from the depth of the solution in order to continuously deliver smaller increments of production-ready code. This can present a challenge for some analysts making the transition to Agile and will create opportunities to learn more about how to write feature driven requirements. Developing a good understanding of software architecture concepts will help bridge the gap between the development team and the business and enable the Business Analyst to show how features will be implemented in the resulting system.
Finally, understanding Agile team dynamics and collaborative decision-making techniques is important in part because agile requirements definition involves more than just the BA and the product owner. These skills enable the BA to accept input from all the team members, specify a more robust solution that meets the evolving needs of the business, and help create a strong sense of confidence that the solution can be delivered to market.
The BA and the Team
Just as every Agile team does not necessarily need a dedicated Project Manager, not every team will need a dedicated Business Analyst. Many Agile projects rely on team members that can perform more than one role. Often a member of the development staff or the product owner will serve as the analyst for the team. BAs may be asked to participate on an Agile team to help bridge a gap between the business and the development staff. The BA may be asked to work on an agile project because the project has a greater need for
written functional specifications or design documents. In either case, remember that your primary role is to facilitate communication and understanding.
A BA should become part of the team involving other members in creating specifications and helping to create a high trust environment. Agile teams begin their iteration with an intense period of collaboration that is followed by more ad-hoc interaction. The iteration is then closed with intense period of inspection and review.
As a BA, you can provide value to the team by helping the team coalesce around the iteration objectives, understanding the requirements at a lower level of detail, and bringing the team together to deliver an acceptable outcome.
While it is ideal is to have a product owner or an on-site customer, for many teams this is not possible. For those teams, the BA may have to fill the role of a customer proxy. Having the role of the customer proxy puts a significant amount of additional responsibility on the role of the BA. In this scenario, the BA is asked to understand the needs of the customer and translate those needs to the development team. This model introduces risk because the true end customer is not directly involved with the people developing the product. The BA can mitigate this risk by encouraging the product owner to review the evolving system as frequently as possible.
Agile on a Traditional Project
Moving to agile is not usually the decision of the Business Analyst. However, given the BA’s critical role on the project, there is often quite a bit they can do to help set the stage for an agile transition.
The BA can encourage collaboration between the product owners and the technical teams. This step alone will ensure that requirements are balanced with feasibility. This will go a long way toward managing expectations and helping the product owner understand the cost of the solution they are conceiving.
The BA can begin to demonstrate the value of loosely coupled functional specifications and begin introducing use cases or user stories to the team. Even where the specifications are completed up front, the development team will derive value from a clear functionally-driven specification. The system will be easier to develop and easier to test, and traceability will be a non-issue.
If your team has a dedicated QA function, agile requirements will enable the functional testing process. Test plans can be derived directly from functional organised specifications.
Success in today’s economy requires us to respond quickly to changing market conditions. Traditional product delivery methodologies cannot deliver fast enough in highly uncertain project domains. Agile processes allow teams to meet the changing demands of their customers while creating environments where team members want to work.
The Business Analyst can play a key role on an agile team. To be successful, BAs first need to shift their traditional thinking about requirements. Additionally, BAs need to consider learning new skills for writing requirements and new techniques for managing them. Success will depend largely on how well BAs adapt to these new ways of working with requirements, setting up teams, and using group collaboration.