Pass IIBA IIBA-AAC Exam in First Attempt Easily

Introduction

1. Introduction to the course. Business Agility.

Hello and welcome to the course. We live in a very different world. in a world that is unlike anything that humanity has ever seen before. This world is interconnected. A natural or social phenomenon that happens in one part of the world can affect businesses in another; it can change them, challenge them, or destroy them in a completely unpredictable manner. This inability to predict things drives planners crazy. This new world has just so many variables to take into account and put into the equation to make good, long-lasting, reliable predictions. So it makes it almost impossible. Businesses struggle to commit to long-term business plans. At the same time, software teams struggle to deliver big multiyear programmes of work. What seemed important at the time the project started may become completely irrelevant and useless by the time the project finishes. Just because the state of the world is different, it is new, it is fresh, and it is very unlike how it used to be. When the project started, people always tried to do something about it. Maybe about a decade ago, people were talking about building resilience into organisational processes. The idea behind resilience is very simple. It is the ability of the business to recover after an external shock and get back to its business as usual and usual operations after it gets through hard times. However, over time, this idea proved to be misleading. It was found that businesses and people needed to look for something else—something different than resilience. It was not enough to just survive the shock. They needed to find a way to learn from it, to embrace it, and to become better after it. This is where the idea of business agility comes into play. The HL Business doesn't see the world as a sequence of two states the state of business as usual whenever anything is planned, and the state of emergency when something unpredictably happens and the business needs to make some extra efforts to get through it and then revert back to the business as usual state. On the contrary, HL Business sees the constant changes as an inevitable part of the world. The world is always full of unexpected surprises. Let's embrace it, let's be ready for it, and let's just accept it and plan our work taking this into account. This is what business agility is about. Be ready for changes. Be ready to learn from changes and to adapt to changes. to change your business accordingly, constantly. This shift to new ways of working will undoubtedly have an impact on employees because it is not so much about the business processes, tools, or methodologies that you employ. It is about the mindset of the people in the business, how they perceive the business and the world, and how they react to changes around them. Obviously, this will also affect people's roles and job titles, business analysis included. It is very exciting to be a business analyst. In this ever-changing world, you will have to learn new tricks and tips. But you will be the ones helping the business to navigate through the uncertainty and become successful in this new world. As a part of this course, we will learn a few techniques ourselves. We will learn how to plan big but execute small, how to listen to our customers, how to pick up market brands, and how to deliver the products incrementally and iteratively and help the businesses succeed. I hope you will enjoy it. Let us begin.

2. Evolution of markets

long time ago, the markets were different. It took hundreds of years for the markets to evolve into their current state. Back then, the general lack of supplyand markets reduced the purpose of marketingto defining the just prices for products. The product in this situation would already be manufactured and ready to be sold. The economists are talking about land, labor, and capital as the only driving forces for production. Whoever owns those owns the market. The physical and technical abilities to create products were key to entering the market. Over time, things started to change. The customers selected the shoes from a variety of products to select the ones that served their needs better. This was driven by the Industrial Revolution, which resulted in mass production of goods and new inventions in logistics and storage solutions. Therefore, there were more goods on the market than ever before, and the goods could be delivered to places where they could never be delivered before. This was the first important shift in market demand. For businesses, it meant a shift to a new paradigm. Now, to sell in the market, they need to design a product that meets expectations. The next big shift happened not so long ago. People increasingly require a solution to a problem rather than the good itself. It was discovered that people prefer to receive a service rather than own a product. For businesses, it means they need to understand a problem people try to solve and design a solution to that problem. That is the shift to the marketof services that happened on the market. Let's have a look at an example. Today, many people don't see a car as much of a status symbol as it used to be for their parents. Instead, they look at it as a convenient way to get from point A to point B or as a way to transport some heavy items. Historically, they would need to analyse their situation and understand what drives the need to purchase a car, then buy a car to meet that need. Today, they can choose from a variety of alternatives. It can be a public transportation ride, a bike ride on a sunny day, or a car-sharing trip. So they can solve their problems in multiple ways. They can use different services that are better suited to the needs of their current situation. However, with more and more services being introduced, people no longer see the difference between them, and they don't see how one service transitions into another. All they see and all they care about is the answer and the experience of getting their problem solved. Take an Uber rider as an example. People rarely attribute this experience to this combination of services. Mobile hardware, mobile network, Uber app payment, gateway, banking, processing—all these things let a single taxi ride happen. For consumers, it is a single experience. whereas for the businesses It is a combination of complementing services. This is the most recent market shift we've seen. the shift to the market of experiences. So what does it mean for the businesses? when interacting with a new product or service? Customers will base their expectations on their previous experiences, even if related to a completely new type of product or service. This essentially makes the businesses compete against non-competitors in the traditional sense, as they no longer compete for market share or sales figures, they compete for experiences. Take an Uber ride, for example. People spoil themselves with the ease of payment for Uber. When you take a ride and leave the car, the payment happens automatically in the background. We'll find it confusing and challenging to complete a multi-step payment form on another service. in an app or a website. So this can escalate to a point where they will abandon a product or service with such an underperforming experience. More than that, studies show that people are likely to never come back and spread word of mouth about their experience. For businesses, it means understanding the problem in context and designing a full end-to-end experience for solving it when designing new products or services. Some people call this process human-centered design; others just use common sense when designing stuff. And finally, it also means that changes in customer behaviour are constant, inevitable, and unpredictable in nature.

Hide

Agile analysis overview

1. Agile extension to BABOK(r) Guide

So what is agile analysis? By definition? Agile analysis is the practise of business analysis in an agile context with an agile mindset. There are two important elements in this definition. One is the agile context. It is important that your organisation understands agile, is agile, or is on its journey to become agile for you to perform agile analysis. Otherwise, it'll be really hard, not to say impossible, to be agile in an environment that is very predictive in nature. Another important element of this definition is an agile mindset. I think we've talked about it briefly before. It is not the set of tools or processes that make your organisation agile. It is the mindset, the view of the world, where the world is conceived as a series of changes that you need to adapt to and react to as they happen, that makes the organisation agile. You need to have this mindset, and you need to use this mindset in all the activities that you do as a business analyst to be a relevant agile analyst. This definition is taken from the Agile Extension to the Biblical. The Biblical Guide is a book published by IAB. IAB is an international institute of business analysis. It's a big body that governs the profession of business analysis. They publish quite a lot of material for BS to build a career. They publish white papers and thought leadership pieces that explain what happens in the profession and how the profession evolves over time. The Be Able Guide is probably one of the biggest and best defined bodies of knowledge about the profession. It explains all the areas of knowledge that a business analyst should have to be relevant as a BA. And it explains how different business analysis techniques can be performed from different perspectives. This book is pretty diagnostic of your industry, type of organisation you work for, or methodology that you use. If you're really interested in the core business analysis skillset, I have another course that talks about it, so please feel free to go and explore it. But for this one, we are focusing on another publication, the Agile Extension to the BE ABLE Guide. It is published as a separate book that is an extension to the core skill set. It is assumed that a business analyst will still use the core knowledge areas and the core techniques while working in an agile context. However, the context will also have some influence on how tasks are performed and what business analysts should know and understand in order to be useful for the business. This book was not published by IB alone. It was published together with the Agile Alliance, which is an organisation that studies agile and prepares people for being relevant in an agile environment. In addition to publishing the book, the IABA has also announced an Agile Analysis Certification. It is a competency-based certification that addresses the topic of delivering projects in an agile environment. Basically, if you know business analysis and you know what it means to be agile, how do you apply business analysis skills to an agile world? You can attempt a certification. It is an 85-question scenario-based test, and if you pass it, you receive a certificate and a badge that will tell your potential employers that you are skilled in this area and that you can perform the Agile Analysis according to the IAB's standard. This course, which is structured around the Agile Extension, is meant to be a guide. So it can be good support for you to prepare for the certification and to attempt it. after finishing the course and reading the Agile Extension.

2. Predictive approach

There are many ways in which people plan their work at the highest level. The Agile Extension to the BBCGuide defines three commonly used approaches to planning: predictive, iterative, and adaptive. They all sit on an imaginary agility continuum—the degree to which the organisation prefers to adapt to changes or predict changes. Basically, this is how your organisation tackles the unknowns, or in the broad sense, risks. Agility is not binary and is very rare. An organisation is completely agile. The same is true with being non-agile as well. It is even less popular for an organisation to be totally predictive or totally set in stone. Most of the businesses sit somewhere in between, and that's okay. So the first approach that we are going to look at is a predictive approach. A predictive approach focuses on minimising the upfront uncertainty and ensuring that the solution is defined before the implementation starts in order to maximise control and minimise risks. Despite common misconception, a predictive approach is not a direct synonym of the much-criticized waterfall approach. Waterfall is associated with bad project management practises such as the absence of feedback loops or an inability to break the communication silence between different crafts involved in the project. Let's not make this mistake. Being in predictive project management doesn't mean that you are not doing your job in the right way. It simply means that you have decided not to be adaptive, to change, and instead to try to predict it. So how do we characterise the predictive approach? First of all, in the predictive paradigm, solutions are largely defined before the start of implementation. This is the key that tells us that this is a predictive paradigm. We try to predict all the changes, define the solution, and then go into implementation and delivery. This also means that the level of formality on such projects is usually comparatively high, and activities are planned upfront and divided into tasks. Those tasks are then grouped into defined phases. Basically, this is how you scope predictive projects. You need to understand what are the activities that you need to perform and what are the tasks that you need to execute, and you need to define in what order you are going to execute them in order to deliver the solution in full well.But at least the cost of change is typically pretty high on this project. So, as I said before, there is nothing wrong with executing projects in a predictive paradigm as long as you understand when predictive planning works the best. Predictive approaches are usually preferred in situations where requirements can be easily defined ahead of implementation or when the risk of an incorrect implementation is unacceptably high. Or finally, when engaging stakeholders presents significant challenges to the project team, So collaboration is not an option. Essentially, it means that this method works best with extremes. First, when you have the most trivial project at hand, it is very easy to scope everything out upfront and then just execute according to this plan. Consider any so-called standard business change, such as the installation and configuration of a well-known software package or the implementation of a minor change. Another extreme is the most complex projects, where the cost of any mistake is unacceptable. So months, if not years, of preparation and planning to iron out all of the uncertainties actually pay off in the long run. Think about space exploration, for example, or medical equipment. So this is an overview of a predictive approach. Now let us move on and see how an iterative approach is different.

3. Iterative approach

Iterative planning is an approach that is frequently used in situations when long-term planning is not possible. Typically, it means the rate of change is really, really high, and its nature not be predicted in interactive planning. The next step in the plan is based on what you've learned from the previous step. So how does it work? You plan for as much as you can and as much as you have information about. Then you make some informed assumptions about the things you don't know, and you focus on getting enough evidence to determine whether the assumptions are true or not. This is called hypothesis testing. Once you've learned if your hypothesis is true or not, you get enough data to plan the next stage and to move on to the next hypothesis. So what are the aspects of iterative planning? Each hypothesis should be tested before planning what to do next. The hypothesis might be right, wrong, or partially right. Every outcome is accepted, every outcome is a great outcome, and every outcome is used as an input for planning the next stage. The stakeholders and the subject matter experts are learning what they need at the same time as planning is occurring, and plans are only viable for the immediate future. It also means that the cost of change is relatively low. Basically, what the Agile Extension to the A guided iterative approach is necessary when you cannot predict the future and long-term plans are not viable at all. It means that you plan just one step ahead. And as you execute this step, you collect enough information to plan for the next step. You never plan more than a few steps ahead in this approach. I understand it may be very different from what you consider to be a proper iterative approach or what some other books call iterative. So if you are to attempt an A BJail certification, just remember what they call iterative and try to separate it out from your understanding or some other definitions that you might have seen before. So when the iterative approach as defined by the Agile Extension to the BE Book Guide is a preference, first of all, it is a preference for small teams that have really few dependencies. It is used when lots of changes are happening in a really chaotic fashion, when any long-term prediction is not viable, and when you do not have any long-term deadlines. Essentially, this approach works best when the team has the luxury of not focusing on the long term, such as when working on business-as-usual and maintenance tasks in a support environment or an environment. Now, let's have a look at what IV calls an adaptive approach.

4. Adaptive approach

The third type of planning as defined by IAB is called an adaptive approach. The adaptive approach focuses on the rapid delivery of business value in short iterations. Unlike others, it welcomes a higher degree of uncertainty in the plans regarding the overall delivery of the solution. It means longer-term planning with the ability to adapt to change as you go. Typically, it supports the exploratory approach to finding a solution when you know what you want to achieve but do not exactly know how you're going to do it. So you explore multiple ways of achieving your goal until you select the one that benefits everybody and is accepted by your stakeholders. So the addictive approach can be characterised by the following First of all, the solution is defined in iterations, with the ability to collect feedback between them and improve as you go. The level of formality is typically lower on adaptive projects, and the information is mostly collected by collaboration and presented just-in-time and as needed to your stakeholders. Deliverables are usually defined first. So when you scope a solution, you first understand what it is you want to achieve within this solution, which value you want to deliver, and then you plan your activities to deliver this value. As you come closer to the implementation of this particular part of the solution in your project, the task will be performed iteratively, and the cost of change is typically lower than in predictive approaches. So when the adaptive approach is a preference first of all, when the solution cannot be defined upfront, or when your context changes much faster than the team can deliver in a predictive manner, So, in order to be valuable in this environment and deliver value in a changing context, you must change the pace of delivery and the rate at which you can adapt to these changes, as well as adjust what you consider to be valuable to match your context. Another thing is that when early feedback is important to shaping the solution, it is in a situation where you do not exactly know what your stakeholders or end users may want or expect from your solution. So you give them something, you collect the feedback—what works well for them, what does not—and then you adapt your solution and make it better based on this feedback, and then you repeat it again and again until the solution is raised and accepted by your stakeholders. When the first time on the market is critical. An adaptive approach allows you to strip off all the unnecessary functionality and deliver the core minimum, and then add extra functionality later on when the solution is already on the market and is already available to your users and stakeholders, and when the cost of a mistake is not too high, which means you are allowed to make mistakes and learn from them to make the solution better. Essentially, this approach can work better in a commercial environment by allowing the product to get to the customers faster and then be adapted based on real-time feedback.

5. The definition of agile delivery and analysis

As you can see, we haven't used the term agile in the discussion of the common approaches yet. The reason for that is simple: there is no one standard way of doing Agile, and your agile project is likely to have elements of all the approaches we've discussed so far. Agile delivery, however, is typically associated with certain techniques. The first is adaptive planning. It involves continuous changes to long-term plans. Constant planning and analysis are used to prioritise and refine the work to be done to deliver the highest value. Second, iterative delivery, which prioritises and refines the work in short cycles designed to provide focus and increase the feedback and learnings gained from the stakeholders, Agile approaches deliver value incrementally, slicing the products into smaller pieces, prioritising them by business value, and delivering items of value. Frequently, agile product delivery, whether for external or internal stakeholders, always includes a degree of uncertainty. By delivering value in a minimum viable way as early as possible, organisations can learn what is valuable and what is not, help minimise waste, and understand what value meets stakeholders' needs better. So why do we do Agile analysis? Agile business analysis techniques help organisations interpret the constant flow of feedback and learning in order to prioritise work with enough speed to meet stakeholder needs, take advantage of opportunities, or respond to a change. First of all, it helps to provide the link between the organization's strategy and the initiative's resources to meet the goals of the strategy. Then it helps to discover, interpret, and communicate information in order to increase understanding and clarity. Where value can be created, it helps to clarify for whom the value is created, who can contribute to the creation of value, and who else might be impacted by the change. And finally, it helps stakeholders make decisions. Now, let's have a look at some foundational principles of agile analysis.

Hide