As the battle between waterfall and agile rages on, organizations continue modify their approach to software development. Very few move directly to a pure agile approach. Instead, they pilot agile processes, create project selection criteria for agile projects, they shorten release times, minimize project documentation, and many are creating hybrid approaches blending both Waterfall and Agile.
As software development methods evolve, the BA role and their requirement processes come into question. Organizations begin to ask, “How do BAs fit in?”
Some have BAs do the documentation and for Agile projects what gets documented is anything from photos of sticky note user stories, to formalized user stories with acceptance criteria, to the same requirements documentation as in waterfall but done at the end vs. beginning of the implementation.
Where I see the common thread in the BA role is in usage of key techniques needed to understand the business need and maximize the value the solution brings. Regardless of the methodology, roles, and deliverables, the goal of every project is to deliver value to the stakeholders and organization.
In order to deliver value, project teams need a shared understanding of context, processes, needs, wants, priorities, etc. The elicitation and analysis techniques used to build this shared understanding are the common ground between approaches like Waterfall and Agile.
We can share!
- BAs can use agile techniques in non-Agile environments.
- Agile teams can benefit from traditional BA techniques.
Here are a few examples….
This may be a traditional technique, but process modeling can provide huge benefits to agile teams. A visual process model offers shared context across an organization and/or system that creates meaningful dialogue.
Process models help agile and non-agile teams understand:
- the process being executed
- the perspective of the user or the system
- workflow sequence and timing
- how users or systems collaborate
Process models in an agile environment might look different—they might remain high-level and avoid detailed sub-flows. They might reflect only future state. They might focus on user perspective rather than system perspective. However, even a few high-level flows would help agile team members understand the big picture, which can sometimes get lost in short sprints and daily code releases.
Business Rules Analysis
Critical to any business process being implemented, agile teams need to define business rules just as much as non-agile teams.
The timing and depth of the analysis might be different across methodologies. Waterfall project teams might analyze business rules on the front end of the process, resulting in a large, project-wide business rules document.
Agile teams might consider business rules at the beginning of each sprint or face-to-face, with the process owner as they are coding. Agile teams need to have a plan for addressing business rules that cross sprints or a dependent on code that will be developed in other iterations. Many teams use User Stories and Acceptance Criteria where many of the business rules are documented as part of the Acceptance Criteria to the User Story.
User Stories and Acceptance Criteria
These techniques may be coined as “agile” today, but are great techniques for any type of project.
In an agile project, these techniques inspire a high level of collaboration and just-in-time requirements. They integrate requirements, use cases and test criteria in one simple template. The user stories and acceptance criteria templates are generated with an assumption that details will be gathered through direct, usually face-to-face, collaboration at the time of coding.
In traditional requirement processes, user stories and acceptance criteria might be adopted to shorten the requirement gathering process. In traditional projects, it’s often difficult to determine when requirements are “complete.” Using user stories and acceptance criteria in combination with collaboration at the time of coding, might take the pressure off BAs to nail down every detail before a project moves to development.
Collaboration games are often associated with agile development. Even the IIBA currently features collaboration games in the Agile Extension of the BABOK.
However, these techniques can and should be used for any project, regardless of methodology.
Traditional BAs can use collaboration games for requirement workshops, issue resolution, identifying needs and features, prioritization, etc. The games inspire creativity and innovation and help engage stakeholders.
A key input to agile development is a prioritized feature list. In many cases, the feature list is fluid and changes as agile teams work through iterations.
Traditional BAs could share a variety of prioritization techniques with agile teams. BAs know how to gather input from multiple sources and make sure that ALL stakeholder opinions are included and aligned.
Agile teams might rely on a narrow group of stakeholders and might not see connections between organizations that would create dependencies between features.
Traditional BAs use functional decomposition to break complex processes and functions into small, manageable pieces for the purpose of analysis. In most traditional environments, each area would be analyzed and all requirements would be grouped together in one project.
Agile methodology relies on breaking complex processes into small, manageable chunks of work. In this case, the functional decomposition would be the skill needed to identify the sequence and contents of each iteration and may be used to break down user stories. Functional Decomposition helps agile teams see where stories fit into a larger process architecture.
Peace at last…
So, now you see—waterfall and agile can live in peace. They can share techniques.
To deliver value to stakeholders, all teams need people with skills to create meaningful dialog, gather accurate information, inspire meaningful collaboration and align stakeholders.
How do you use your BA skills to add value to an agile team? Share your story below.
Powered by Facebook Comments