7 Agile Principles from the Agile Extension by IIBA
Principles are the rails that guide people along the path of life. The International Institute of Business Analysis (IIBA) has identified 7 core principles that guide business analysts on how to work to deliver more value to the team and the client by doing less work with more utility. The article will be useful for both novice business analysts and those colleagues who want to dive deeper into Agile or prepare for the AAC exam.
This article is written from the perspective of a business analyst, but describes the principles of Agile that should guide all members of Agile teams to improve their work.
The article is a revision of those paragraphs “Agile Extension to BABOK Guide” that talk about the princes of Agile business analysis, and contains small additions and explanations.
See the whole
The first principle, seeing the big picture, guides business analysts to create, within the team, a collective vision of the value that the decision will bring to the business. Using this principle will help a business analyst answer the question “why”: “Why does the client need this product?”, “Why are we making such a system?”
Using this principle, BA helps clients make decisions about which options to choose. If the principle is used correctly, then a solid understanding of the goals set by the organization or project arises between team members (both on the developer’s side and on the client’s side).
What is Big Picture and how to create it
Talking about Whole it is important to clarify what kind of animal it is. Whole – or Big Picture – is the context in which a change occurs (a product, a project is created). The context is created by more than one business analyst. The participation of the leaders of the initiative is important here: project manager, Product Owner, Product Manager. 5 reasons why BA creates a shared understanding of the context:
so that the team knows where and why the project is going;
to make it easier to validate the solution itself and the approaches to it with the customer;
to make it easier to manage solution creation and change requests, quickly and accurately trace changes to requirements, and see how changes affect the goal of the initiative.
A shattered vision negatively affects the team. The lack of context suggests that developers all no matter what the client’s needs are; the team has no established processes communications, and the team itself does not understand why and where the project is going.
Think As a Customer
Think Like a User helps the analyst and team hear the voices of those who use the product. The analyst starts with a high-level understanding of who is the user of the solution. Understanding increases as the initiative matures, acquiring details of what user or business needs the team is meeting with when creating a project.
A user is not only a person. Experienced colleagues recall projects where cows were the user. In this case, the business analyst must hear in mu a request for requirements that the team must fulfill. The key to fulfilling this principle is value. Concentration on her will tell the organization what goals to set, what functions to develop.
In Agile planning, this principle will help the analyst, organization, and team not do bullshit. Surely the reader will remember about Waterfall and the fact that planning there takes months and years and does not take into account the changing needs of users.
The “Think as a customer” principle includes studying the reaction of users to a solution. In Lean Startup, Eric Rees wrote about speeding up feedback loops. That is, that it is important to understand users and how they use the product quickly. The IIBA writes that focusing on the user will help an organization make the right decisions about whether to continue or cancel an initiative and allocate resources.
Analyze To Determine What Is Valuable
For a team to deliver value to customers, the business analyst must continually check the backlog and what tasks are at the top. According to this principle, those tasks that bring the greatest value to users and the client have the highest priority. To properly prioritize tasks, an analyst must:
understand the meaning of the requirements that come for analysis;
be sure that the solution and components provide the business they need;
use the latest data: the right decisions based on outdated information will ultimately be wrong.
Agile is the answer to ever-changing demands. The values and needs of users are constantly changing. Using this method will allow an organization to understand what is important as the context in which the organization operates expands.
Get Real Using Examples
This principle is similar to genchi genbutsu, a principle from Toyota’s Tao that forces product managers to “leave the office” to understand a user’s request. “Get Real Using Examples” helps analysts build a common understanding of the queries that will satisfy the solution.
`Examples` come constantly from any interaction with users – support complaints, feedback tickets from leaders of the initiative, analytics or interviews with users. The team is working on different solutions that will satisfy the request, creating a joint understanding of how the solution will meet the needs.
The business analyst can use the obtained use cases to create acceptance criteria, develop a solution (to answer the question what are we doing?). They can also act as the basis for the creation of test cases by the testing team.
Understand what is doable
This principle will help the business analyst understand which solution is applicable to meet the need in the context where the team operates. Each time asking the question “Can this be done?” we also answer the questions “Does it make sense to do it now?” and “Should I do this at all?” The context includes:
limitations of technologies used in the project;
team skills;
time for which the team is obliged to deliver the solution to users.
Consideration of context helps to re-prioritize a task. For example, if, due to some technical limitations, it takes 3 months to add a button to the site, then the priority of the button will drop and product leaders will prefer to use the team’s time on tasks more easily – this is more likely to deliver more value to the client. Using this principle, the business analyst acts as an advisor who helps leaders make decisions based on quality information, assessing the quality and relevance of incoming information.
Stimulate Collaboration and Continous Improvement
This principle encourages the analyst to build an environment in the team for the constant exchange of knowledge and thoughts. Such an environment helps to achieve a common understanding of the value that the team brings to the client and create continuous improvement, which is impossible if without constant communication, as information will settle among part of the team. Constant communication will help the team:
be open to changes (if there is a lot of communication between people, then they begin to communicate openly, trusting each other);
relentlessly seek ways to improve team-building processes.
It is important for an organization to create an environment that will allow employees of different departments to exchange views and information about goals, missions, projects. As with each other, company employees must communicate openly with customers. Open communication will accelerate feedback and accelerate learning – the organization will be empowered to create a product that delivers more value.
Avoid Waste
Although this principle seems to be about rubbish, in fact he extra work and helps analysts do less while creating more value. “Avoid Waste” postulates: “More outcome with less output”.
Waste can appear in two ways:
through work that creates value indirectly;
through work that generally does not create value.
Using this principle, the analyst minimizes the first way to create waste and get rid of the second. To avoid unnecessary work, a business analyst should:
use simple methods of communicating requirements (for example: diagrams instead of texts);
do not create requirements and tickets in Jira too early (this threatens with an overflowing backlog that the team will not fulfill);
create detailed requirements as close as possible to the moment when the developer can take them into work in order to avoid rework and changes;
use only fresh data to communicate possible solutions (decisions made on bad data are waste).
Conclusion
Although the principles of Agile Business Analysis may seem straightforward, they are actually difficult to apply in practice. Colleagues, remember that Agile is one of the skills that easy to learn, difficult to master and use the wisdom of the IIBA to create more value in less action.
