This is the second in a series of posts that take a look at the agile business analyst in terms of Laura Brandenburg’s 8 step business analysis process which serves as the foundation for Bridging the Gap’s BA Essentials Master Class. (Note: KBPMedia is an affiliate of Bridging The Gap. When you purchase something from Bridging the Gap as a result of following any of these links, I get a small commission at no cost to you.) Go to The characteristics of an agile business analyst for an introduction to this series.
Whenever you start work on a new internal product, try to solve a problem you haven’t dealt with before, or work with new stakeholders, resist the temptation to dive right into the effort. Take some time to get familiar with the context in which you’re working and the people you’ll be working with.
A small amount of time identifying the things you don’t know you don’t know and then learning about some of those things can pay off huge dividends in the course of your work.
Don’t spend so long getting familiar with your environment that you lose the initiative. Try to keep your acclimation time to 1 – 2 weeks tops. If it makes sense to start sprinkling in work on your internal product, by all means do so.
So what do you do during this orientation time? Chris Matts and I described our approach in the chapter we wrote for the book Business Analysis & Leadership: Influencing Change. Here it is in the guise of an answer to the question “what is the first thing you do on a project?”
There is no first thing we do on a project. There are a number of things which we do in an opportunistic manner to gather as much information about the project and its context as we possibly can:
- Get to know the people involved.
- Understand “WHY” we are doing the project.
- Understand “WHAT” we are trying to achieve
- Get something done.
These items fit nicely into this and the next three steps of the business analysis process, so I’ll explore each idea in a little more detail in the appropriate place.
How To Be An Agile Business Analyst
As a business analyst, you have probably wondered how agile impacts your work. You may look at the popular agile frameworks, notice that business analysts aren’t mentioned and wonder whether you fit.
The key is to not focus on the frameworks and prescriptions, but rather to apply your business analysis skills in an agile manner so that your team solves the right problems with the right solutions. How To Be An Agile Business Analyst shows you how.
Read How To Be An Agile Business Analyst to uncover ways to add value to your organization, make your team more effective and build a more rewarding career.
Key Responsibilities
Each of the 8 steps of the business analysis process included key responsibilities that come along with that step. Here are the key responsibilities for the get oriented step viewed from an agile perspective.
Clarifying your role as the business analyst so that you are sure to create deliverables that meet stakeholder needs.
You work on a cross functional team where everyone is expected to contribute in a variety of ways, but where each of you has a certain specialty. In this setting it’s important to come to a general agreement about what each person on the team is responsible for, as well as an understanding of who has the skills to help out in other areas.
If there is more than one product person (product manager, product owner, business analyst) on a team, it’s especially important for you to decide who will own which product responsibilities. There are four fairly common models that provide a starting point to help you decide how to split up those responsibilities.
One key thing to note: the artifacts you produce are a means to an end (to help you build shared understanding) rather the end itself. Identify responsibilities based on activities that you need to do and decisions you need to make sure get made in order to deliver the outcome that your team seeks to deliver. You’ll find that you’ll have more discussions around “what do we need to do” or “what do we need to decide” rather than “what documents do we need to create?”
Determining the primary stakeholders to engage in defining the project’s business objectives and scope, as well as any subject matter experts to be consulted early in the project.
The focus of your initiative is to deliver some outcome that benefits your organization’s customers. When you’re working on an internal product, that benefit is often indirect in nature and can be influenced by the people who will use the product, and other people inside your organization. In all of this, it’s important to understand the difference between customers, users, and stakeholders and how to work with each.
Customers
The extent to which you get to know your organization’s customers depends on how directly your product impacts them. If there is a direct impact, such as you’re working on your organization’s website or a mobile app, you’ll want a fairly good understanding of your customers, their needs, and their problems. Doing meaningful interviews is extremely helpful. If your work is on an existing product, you can also look into customer feedback, and usage data that you already have about that product.
Users
As you start work on your initiative, you want to get a good understanding of the people who use (or will use) your product. You want to get familiar with them, their environment, and their approach to work so that you can ensure your product allows them to complete their activities effectively in pursuance of the desired outcome.
There are a variety of techniques you can use to build an understanding of your users. Two that I’ve found particularly helpful are user modeling to identify the different types of users and exist and personas, which you can use to get a deeper understanding of those different types of users. As with most other techniques, the act of performing the technique adds as much, if not more value, than the end result.
If your product already exists, a couple of ways to learn more about your users and how they actually use the product is to observe them in their own environment or include them in some usability testing.
Stakeholders
Stakeholders may or may not be directly involved in your initiative, but they are usually in a position to help move it along or severely impede it’s progress. That’s one of the reasons that Chris and I called out getting to know the people involved in your project as one of the things we always do when we start a project:
Getting to know people involved in a project goes beyond simply creating a stakeholder map to show who can influence the outcome. It means meeting the people and getting to know what they are like, how they interact with others, and give them a chance to learn about us. In particular we stress the importance of collaboration and focus on achieving results. Our favourite tool for getting to know someone is the humble cup of coffee. Ideally we go out of the office and meet in a coffee bar, but if we can’t do that we will try to find an atrium or cafe, and as a last resort a meeting room.
Don’t take the excerpt above to mean that stakeholder maps are not helpful, they are. The point is that they provide a good structure upon which you can build conversations in order to understand your stakeholders. Don’t think that creating a map by itself is going to get you all the way there.
Another technique that will help you understand your stakeholders better, and know how to interact with them, is the commitment scale. This is especially the case if you have some stakeholders that aren’t as supportive of your effort as you would like.
Understanding the project history so that you don’t inadvertently repeat work that’s already been done or rehash previously made decisions.
George Santayana is rumored to have said “Those who do not learn history are doomed to repeat it.” or something to that effect. Whether he said it, someone else said it, or the whole story is apocryphal, it does have relevance.
When you work on an initiative that is entirely new or at the least new to you, one thing you don’t want to do is repeat discussions that have already occurred, work that’s already been done, or decisions that have already been made.
Teams working in an agile fashion get the reputation for not using documentation of any sort. The absolute view of no documentation is a myth, but it is quite common for initiatives to lack any real, useful institutional memory. Ironically, that happens just as frequently on phase based efforts that produce tons of documentation, but none that really help you figure out what happened on the project in the past.
That said, if people working on the effort followed the premise of documentation with a purpose, there should be some system documentation that sheds light on the current state of the product.
If not, those conversations with the stakeholders over coffee can be very helpful and often prove to be a very useful source of information about what’s gone on before with the initiative.
You certainly want to know what decisions have already been made and the resulting constraints so you know what boundaries you have to work within.
Techniques such as the purpose based alignment model and decision filters will help you establish a clear understanding of what those constraints are, and identify decisions already made that can guide future decisions for your product.
Understanding the existing systems and business processes so you have a reasonably clear picture of the current state that needs to change.
To get a clear picture of the context in which you’re working, it’s helpful to get an idea about the people you’re going to be working with, but it’s also important to learn about the other products, systems, organizations, and processes you’ll interact with.
This is one of those places where your analysis skills are extremely relevant with a slight change to the level and extent to which you use them.
Two techniques that are particularly useful are the context diagram which helps you understand the different people, organizations, and systems your product interacts with and process models which help you get a better understanding of the process you’ll support.
In both cases, these techniques can help you build a strong understanding of the current context as well as what changes you’ll make to the environment going forward.
Up Next: Define the outcome
All of the context setting described above positions you to have effective discussions around why exactly you’re working on the project in the first place. In the next post, we’ll take a look at ways to discover the primary business objective which is really just understanding the outcome you want to delver.