Agile as a Business Analyst, what are the benefits?
World of Digits / Explore
In our last article, we spoke about the main traits/characteristics an Agile BA must have to be successful in its projects. There is a lot of discussion about business analysis in an AGILE environment and many certification paths and courses have been creating.
At World of Digits, we provide a 2-day training course based on the AAC (Agile Analysis Certification) provided by the IIBA (International Institute of Business Analysis). As an Agile Business Analyst, you will learn how Agile intersects with business analysis and how it interacts. You will gain fundamental awareness of the skills and knowledge involved in the analysis work. Moreover, you will learn how to boost interactions and collaboration within Agile teams.
This training will help you understand the ability to collaborate in an Agile environment and transform project delivery. You will learn the key principles of Agile Business Analysis, three planning horizons, an understanding of how interactions and feedback cross horizons, and how and when techniques of business analysis are applied in different planning horizons. The goal is to help practitioners go beyond user stories and consider what business analysis in an Agile environment really means.
Become Agile Business Analyst!
Subscribe to our next training on the 27th-28th of August 2020
There seems to be a lot of discussion in Agile projects around the role of business analysis. Some, believe this to not fitting the standard role of business analyst, whereas others see the two principles will function perfectly together. I personally believe that the evolutionary path has been defined by the “hybridization” and the “adaptability” (which is, by the way, one of the pillars of the agile mindset).
But do we really have to make a distinction between Agile BAs and standard BAs? Do need teams really to pick one or the other? Or would BAs actually develop in an Agile setting to offer value?
Let’s have a better look at the role of the Agile BAs and how it can support agile teams.
Working Agile is becoming “the new normal”.
Knowing agile principles or ceremonies is no longer just nice-to-have or reserved for software development teams. The majority of them embed agile within their core activities and make it part of their DNA.
Because so, today is fundamental to have knowledge of the Agile “principles” and few frameworks as Scrum, SAFE, etc.
For a business analyst is even more fundamental: “historically” they always been asked to be the bridge between business users and development team. Today, they have been asked to be part of an Agile team, supporting Product Owner and Scrum Masters.
By definition, being a BA means being adaptable in different contexts and sectors. This concept is clearly emphasized when we spoke of Agile. Agile Business analysts are not actually implementing those solutions. Instead, they ensure valuable solutions are created by the development teams. Agile BAs help facing issues and establish approaches analysing fundamental problems such as eliciting real needs/problems, the way to solve those needs/problems and whether those ones really fits the current organization’s goals. It seems clear that Agile BAs provide a high-value contribution to resolve these needs/issues and practically this implies supporting the development teams to create a solution that will fit perfectly organization’s needs or solving the right problem.
With techniques and supporting analysis…
Agile BAs are valuable support within Agile projects supporting development teams and Product Owners solving problems and find solutions.
When BAs don’t consider taking on roles with the client services teams, they could start working with developers. But, while BAs have a well-established position in waterfall projects, in Agile this appears differently. This does not mean that BAs roles are less important in this context, but simply that they are part of the development team. In this context, BAs are part of cross-functional teams (as encouraged by Agile methodologies), adding tremendous values either as specialist and either as generalist being multifunctional and also helping where is they are more needed. As an example, on bigger projects, it is preferable to have a dedicated BA (in particular, when there are more than two or three systems at stake), while on smaller ones the role can be hybrid. In this manner, the product owner does not depend solely on one member to perform tasks, but BAs can step in where they are more suited. It is also important to notice that, some Business Analysts try to become proxy of the product owners: in particular, not every business analyst will easily fit into the development team, which in contrast could result in tension as they attempt to figure out where they are within the organization. In most cases, BAs turn out helping the product owner create user stories and working as a team assistant. The alternative is not to seek and find out what the job looks like, but more to build a role that is personalized and reflecting teams’ needs.
Generally speaking, the product owner role is always a mere extension of the position of a more seasoned business analyst. In fact, they must usually learn new expertise in order to conduct this position, and must also be granted the complete control of product ownership: this latter is in most cases the perfect choice for business analysts. The work of product owner is underappreciated in Agile, but since it is focused at bringing the team to understand the best potential solution, the business analyst who can enable the change is absolutely priceless for the client. Therefore, Agile BAs ultimately provide enormous benefit to companies when deployed successfully and in the correct way.
Here are some very practical benefits:
Firstly, reducing silos of information, because, one of the BA’s primary responsibilities throughout the requirement elicitation process is to connect customers together and guarantee cohesion around a work unit and the effort needed by all team members to achieve that task. This increased coordination and teamwork breaks down knowledge silos and helps the whole team to operate together more effectively to achieve the highest priority required for the work underway.
Secondly, implementing appropriate and relevant requirements: rather than running ahead of the team for multiple weeks or months (as shown in a waterfall environment), Agile BAs completes user stories just in time to be pushed into Sprint. It means the main target remains the requirements being worked on; it assures that the requirements will not have room to go stagnant in the backlog and it maintains the teams cantered on the task at hand. Finally, a BA supports processes where the whole team has input into requirements prior to Sprint Planning, then helping to create meaning around the requirement and ensuring that the exact level of accuracy is in place timely in order to meet the needs of the team.
To conclude, having a Business Analyst role on your scrum team allows for further interaction and collaboration, and offers the team with clearly defined requirements just in time for the sprint to begin. This key advantage allows the team to correctly size the requirements and enables for noticing and acting on barriers and dependencies in advance so the sprint is not undermined.
Become Agile Business Analyst!
Have a look at our training
Written by Adriano
Read this article
Working smarter, not harder, is possible for your developers and designers thanks to the right collaboration tool.Read this article
Many UX designers are familiar with the problem of a creative block. But how do you make the most of this moment of low?Read this article
Read this article