You are not an agile business analyst just because you have a working knowledge of Scrum, you are able to write user stories, or you got a certification.
Remember that agile is an adjective, not a noun. An agile business analyst is a business analyst who works in an agile manner.
You are an agile business analyst when you consider your context so that you use appropriate techniques. You learn more about your customers and users and their needs. You learn more about the constraints that your stakeholders want to apply to your project.
You are an agile business analyst when you help your team focus on delivering maximum outcome with minimum outputs and use that outcome to define success and measure progress.
Outcome is the change you’re trying to introduce to the world. It’s why you’re working on your product. Outputs are the things you produce in order to satisfy that need, or the solution. One of the most relevant categories of outputs for business analysts is requirements and the related deliverables and artifacts.
You no longer define your role as eliciting and analyzing requirements and producing artifacts (output). You define your role as positioning your team to deliver the desired outcome by keeping them focused on that outcome, building a shared understanding, and making sure decisions get made.
You no longer define the goal of your team as producing outputs; it’s to reach a specific outcome. A successful team seeks to maximize outcome with minimal output. That way, you get as close to the desired change in your organization and your stakeholders’ behavior with the least amount of initial and ongoing work as possible.
You are an agile business analyst when you use tried and true business analysis techniques to build and maintain a shared understanding of the problem your team is trying to solve. You use most, if not all, of the analysis techniques you’ve used before, but you use them for different reasons.
You don’t use an analysis technique to produce an artifact that serves as the primary (perhaps sole) means of communication. You use analysis techniques to build and maintain a shared understanding between the team and stakeholders. If you produce an artifact to remember what that shared understanding is, great.
Instead of using Visio alone at your desk, you use a whiteboard collaboratively with your team and stakeholders.
Yes, business analysts elicit and document requirements, but those activities are means to an end. Analysis is about understanding your stakeholders and their needs, identifying the best solution for satisfying those needs in your particular context, and then building a shared understanding of that solution. Requirements play a part in that work, especially around describing the need, but they are certainly not the end product.
When the teams I worked with thought that the BA’s sole responsibility was requirements, my role was diminished and I lost the ability to make sure the project was delivering the right thing. On the other hand, when I stepped up and sought to understand why the project existed in the first place and then made sure everyone on the team had the same understanding, the project tended to go better, I enjoyed my work a lot more, and I found I had much more influence on that project and in the organization.
You are an agile business analyst when you make sure decisions get made, whether you have the responsibility for deciding or not.
You are an agile business analyst when you use short feedback cycles to learn about your users’ needs and adjust your product accordingly.
You learn at each step of the software development lifecycle. You learn about your solution when you build parts of it. You learn about your solution when you test it. You learn about your solution when customers look at it and users use it.
These are all feedback cycles, and you want them to be as short as possible so you can learn quickly and make sure you stay headed in the right direction. To make the most effective use of those feedback cycles, you don’t want to get too far ahead of what’s getting built next. There’s certainly value in understanding the breadth of what you’re trying to deliver, but you don’t want to dive deep on everything too soon. The key phrase is “mile wide and inch deep,” followed by repeated cycles of “inch wide and mile deep.” Establish the general parameters of what you’re going to tackle and then do deep dives on small aspects of the overall solution when you need to.
Let’s take a closer look at the five things that make you an agile business analyst.
Find out more about How to be an agile business analyst
This post is an excerpt from the upcoming book How to be an agile business analyst.
This book helps you be an effective member of a team working in an agile fashion. It explains how to add value to your team and how to apply your business analysis skills. It will help you understand how you can use your business analysis skills to make sure your team builds the right thing.
The annoying, but honest, answer given to most questions about product development. If someone provides that answer and stops there, they’re trying to avoid the question.
If they say that and then continue to explain what happens in various situations, they are admitting the impact of context in product development.
The impact of context prevents best practices from being a real thing. The term best practice frequently describes techniques or processes that were successful for one team or organization and are being copied by others. Unfortunately, what works for one team may not work as well in your situation. Many environmental factors can play a role in the effectiveness of a practice for a given team. For this reason, I prefer to use the term appropriate practices or good practices, emphasizing the fact that there really are no best practices across all situations.
Your team has to consider your environment, your organization, and your product when choosing which processes, practices, and techniques you’ll use, so you can be sure you’re doing whatever will make them successful—and skipping anything that’s not necessary.
Perhaps considering context is the only real best practice.
Focus everyone on maximum outcome with minimum output
Outcomes are changes in the world that happen because of your work. With internal products, outcomes show up as changes in the organization or in your stakeholders’ behavior. You deliver outputs in order to achieve some outcome. Outputs can include code, tests, requirements, and documentation.
Gojko Adzic suggests another way to describe outcomes and outputs. You can look at outputs as effort spent or invested and outcomes as what your customers get as a result of that investment.
Because outputs are typically easier to measure than outcomes, most teams and organizations measure progress and define scope by the number of outputs produced. But it’s possible to produce a large number of outputs, spending a lot of money in the process, and still not reach the desired outcome.
It’s better to focus on the outcome that you want and then as a team determine the minimum outputs necessary to deliver that outcome. This shortens the time required to deliver the outcome, reduces the cost of producing the outcome, and decreases long-term costs, as fewer outputs (code, tests, documentation) need to be maintained.
The secret is to build a shared understanding of the problem your stakeholders are trying to solve (outcome) and then determine the most appropriate solution (output) for addressing that outcome.
Don’t take all stakeholder requests verbatim; instead, dig a little deeper to understand what’s behind each request. Observing people at work is a great way to dig deeper. You may not immediately know what to ask about, but you’ll notice things when you watch your users.
When you consider the information you get from talking with and observing your users, then decide whether the stakeholder request is relevant to your given solution. If it is relevant, determine the underlying need that the stakeholder is trying to satisfy, and tackle that need. If the request is not relevant, explain to the stakeholder why it’s not appropriate to address in this particular effort.
Once you understand the outcome you’re trying to deliver, as well as the assumptions underlying that outcome, use that information to guide what you do next. Select the outputs (often expressed as features) that allow you to make progress toward the targeted outcome, or that help validate assumptions. Which aspect to focus on first depends on how far along you are in the initiative. At the start, you’ll spend more effort validating assumptions (you can also think of this as reducing uncertainty), followed by delivering features that you know provide the value you seek.
The key point here is to identify value first, then iteratively identify the features that you need to deliver that value. Don’t brainstorm a big list of possible changes and then try to figure out what each feature could contribute to business value.
Measuring value at the granularity of a user story is very difficult and can generate wasted effort. Too often, a team spends time overanalyzing the value points associated with a story, when they could easily have made a priority decision in another way. By working from outcome (value) to output (features) instead of in the other direction you’ll have fewer items to manage at any point, and you’ll avoid the tricky business of trying to assign value to any specific change.
In addition to delivering only required outputs, deliver those outputs using only necessary activities. In practice, this means that the approaches your team uses should be barely sufficient (with adjustments along the way as needed, based on experience). You also shouldn’t get too hung up on the arcane semantics of modeling techniques. Remember that you’re generally using modeling to aid with communication and build a shared understanding. Imperfect is okay as long as everyone involved in the discussion understands what the model conveys. You can always chat to clear up any confusion.
Complicated processes or frameworks are rarely good ways to address complexity. In fact, the more complicated a process is, the less likely people are to follow it effectively—and, perversely, the more likely they are to hide behind the complicated process, to the detriment of the entire team. Keep your processes simple, and adjust them as you learn.
Build and Maintain Shared Understanding
In a good collaboration, team members commit to meeting a joint goal, and they’re not afraid to step outside their area of specialization to help others on the team. All the team members have a specialty (such as development, testing, or analysis) on which they spend a considerable part of their time. But when the need arises, they should be able to jump in and work on something else to help the team meet its overall goals.
As a business analyst, this might involve:
- facilitating whole-team collaboration
- helping other team members improve their analysis skills
- help other team members be more effective with discovery
- using team member and stakeholder insights to aid in analysis
- helping out with testing and documentation when other team members get stuck.
- take advantage of different perspectives
Don’t hoard all of the analysis work for yourself, or restrict your team members’ contributions to analysis.
Make Sure Decisions Get Made
Success in many types of organizations (for-profit, not-for-profit, governmental) depends on making well-informed, timely decisions. I’ve worked on successful projects in successful organizations, and one characteristic that always seemed to be present was clear decision making. Conversely, in cases where I had the opportunity to learn from less-than-desirable situations, one factor that always seemed to be present was poor (or nonexistent) decision making.
An important aspect of decision making is who actually makes the decisions. That person should be as informed as possible and also be in a position to make the decisions stick. In many organizations, the people who are expected to make most decisions—senior leadership—are not the best informed; leaders may not have the in-depth knowledge required to make a good decision.
One very effective way of resolving these issues is by spreading decision making throughout the organization. This helps ensure that the people with the relevant information are the ones who make certain decisions. A prime example is teams deciding the best way to approach their work assuming they have the proper understanding of the desired outcome, and they understand the constraints under which they must work.
Operate in Short Feedback Cycles to Learn
Unlike operational work, internal product development rarely uses directly repeatable processes. When you’re engaged in operational work, such as assembling a vehicle or processing a claim, many of the steps can be copied directly from one unit to the next. Identifying improvements becomes easier because often there is very little time between cycles of a particular set of work tasks. Operational work is repetitive and fairly predictable; you can always learn how to do it better.
Product development work is like snowflakes: No two products are alike. Even if you get the opportunity to work on multiple products, all the lessons you learn from one probably aren’t exactly applicable to another. You can note patterns and trends, but each experience will be a little different.
A focus on continuous learning, with iterations being a key component, reminds your team to stop every so often and figure out what they can revise. This also helps them identify meaningful milestones, with progress shown as actual working output rather than intermediate artifacts.
It’s important to validate assumptions early in your project, so you can determine whether you have identified the right solution to the right problem. Asking your stakeholders for feedback is helpful but, due to the influence of cognitive biases, they could give you misleading information. The Build-Measure-Learn loop provides a way to validate assumptions in conjunction with talking to your stakeholders. It also encapsulates the overall approach to building and getting feedback, which is a key aspect of the guiding principle to reflect and adapt.
Quick cycles through the Build-Measure-Learn loop can help your team reduce the uncertainty that often comes along with products. Start by tackling the biggest or riskiest assumptions. Eric Ries calls them the “leap-of-faith assumptions,” but it may be easier to think of them as the assumptions that, if proven wrong, can significantly reduce the chances that you deliver the desired outcome. For example, when I was working on a recent product, we identified that outside interfaces were the biggest source of risk, so we chose to work on building those interfaces out first, even though the data obtained from those interfaces were used at different points in the overall business process.
It’s also helpful to keep a mindset of identifying the right solution rather than iterating on a known solution. One way to approach this is to ask “what is our biggest unknown that would drive a change to our priority list?”
Your team should continuously learn from its experiences if you want to improve your approach and your outcome. Specific initiatives often last longer than a couple of months. During that time, business conditions, team member understanding of the outcome, and the environment surrounding the product will all grow and change. Your team should seek to use that change to its advantage, to ensure that your outcome meets the needs of your stakeholders when the result is delivered—not just the perceived needs of the stakeholders when you started.
Project teams have long done postmortems or lessons learned sessions, where team members gather at the end of the project to talk about what happened—usually the negative aspects—in hopes that they can do better next time.
If that end-of-project analysis is considered a good practice, wouldn’t it make sense to do the same thing while you’re working on a product, when the team still has time to make changes that affect the outcome? This is the idea behind retrospectives, which provide teams with a mechanism to discuss what has transpired to date—things the team did well, along with opportunities for improvement—and decide what course corrections should be made.
A recent example
I was the product owner for the initiative to revise the Agile Alliance website, membership, and conference registration systems. When it came time to do a deep dive into the membership aspects of the system, I took it upon myself to write up all the specifics about membership—what information we wanted to track about members, what rules were relevant, and what types of memberships we had. It was a fairly short, yet comprehensive, set of requirements. I was admittedly quite happy with them.
Until the delivery team started developing functionality and they didn’t seem to pay much attention to the requirements. At first, I was perplexed. Did I not clearly tell the team where the requirements were? Then I was irritated. Why weren’t they paying any attention to them?
Then it occurred to me that I had focused on the requirements as an output, without considering how it contributed to our desired outcome—increased membership. I didn’t talk with the delivery team to find out the best way to share information with them as they built the various aspects of the membership functionality. We didn’t have conversations as we went along to point out the relevant rules and pieces of information for the specific backlog item that they were working on at the time.
Once I came to that realization, we changed how we communicated. We still used the rules and data element information, but we used them more as reference points in the frequent conversations we had. We also started using examples on a more regular basis to talk through the specifics of a given backlog item. We found that it was not enough for me to simply write those examples down. In many cases, the real advantage was talking through them as the delivery team was getting started on a backlog item.
I should have known better than to start the way we did. But it’s easy to forget good practices when you’re in the thick of it and the pressure is on. Here are some good practices I hope you don’t forget when you run into the same situation:
- Take time to talk with your team about how you want to work and the best way to communicate information in order to build and maintain a shared understanding. When you have those discussions, don’t be afraid to suggest approaches that your team is not familiar with if they are applicable to your project.
- Document requirements collaboratively during your discussions with the team to build and maintain a shared understanding.
- Stop thinking of analysis in terms of gathering and capturing requirements, and instead think of it as solving problems and building a shared understanding.
One time where we can talk about the how
If you’ve been doing business analysis for any length of time, you’re probably used to having it beat into your had to focus on the what, not the how.
That is true.
However, when it comes to talking about being an agile business analyst, it’s ok to break that rule.
We just discussed five things you need to do to be an agile business analyst. Chapters 4 – 8 in How to be an agile business analyst describe in more detail how you go about doing that.