BA as team infrastructure!

I’ve had a brainwave. Well actually my partner did, but it was based on something I said and what do we care about him anyway?

I’ve written previously about some of the odd parts of the BA role. You’re a piggy-in-the-middle, and seen as the master of none, with only boring requirements to your name 😬!

But when BAs are on a project or in a team or in an org and they are doing their thing, then things just work better. People often can’t tell you what exactly is making it work—they might say it is “We’ve got a great team” or “I have space to do my work” or “This is a fun project” or something else.

And yes, it could be all those things, but I think it’s likely that it is also that you’ve got your team infrastructure set up well. And further, reimagining the BA role as team infrastructure is a really awesome way to understand (and extend) the value BAs bring to your crew.

Plus, maybe we can finally explain to devs what a BA does?.

Let me explain what I’m talking about…

Infrastructure is the underlying foundation or basic framework that makes everything work, such as plumbing, roads, traffic lights, etc. Commonly, these are considered mundane, maybe even boring… until they’re unavailable 😉.

And what do modern teams—a group of people working together to create some outcome— run on? Candy? Petrol? Story points? Nope, they run on information.

Information is a tricky thing, especially when humans are involved—Agile ceremonies and other team events can only do so much to address the complexity. And the more people you have involved, the more complicated it gets! Each new person adds new information flows to your team. The two pizza rule actually makes a lot of sense:

Arguably, the vast majority of team ceremonies and practices are, at core, trying to facilitate the flow of information.

Stand-ups? That’s how team members know what everyone else is doing. Demos? That’s how people outside the team know what the team has done. Refinement? That’s how to make sure a problem is understood by everyone.

I could go on…

Easy. Let’s start with caching.

I collect information about everything. But I’m especially interested in information about my team. It is because, like most BAs, I’m nosey AF. I love knowing what the dev is focusing on for the day, what the product manager is mulling, and what the exec’s next priority might be.

And while the primary benefit of this is that my team members get a heads-up on goings on (and are the first to hear the gossip from the board meeting), another, arguably more helpful way of looking at it is that I’m building a team information cache.

A cache is a high-speed data storage layer which stores a subset of data, typically transient in nature, so that future requests for that data are served up faster than is possible by accessing the data’s primary storage location. Caching allows you to efficiently reuse previously retrieved or computed data.

AWS

Reconceptualising it as a cache totally changes the value proposition. Instead of gossip and backchannel information, it has value. We can use the information we’re already collecting to protect our team (and others) from unnecessary interruptions, context switching, and repeating themselves.

As I’m going to say frequently throughout this article, you are probably already doing this, and by doing it deliberately, you can simply do it better with little additional effort.

But it isn’t quite a free lunch as there are some things to keep in mind.

Simply put, routing is the process of getting information from where it is now to the place it should be next.

Like actual network routers, a Business-Analyst-as-a-router has three key functions:

1. Path determination: Deciding where the information should go. You’re doing this when you decide what information should be included in requirements, or included in that email.
2. Data forwarding: Actually getting the information to that place. You’re doing this every time you forward an email or send a “hey FYI” message to your crew.
3. Load balancing and redundancy: Ensuring information flow is effective. You’re doing this when you redirect information to the least busy team member to respond to, or when you tell multiple people of that feedback from your exec to ensure it is really heard and understood by your team.

Again, you are no doubt already doing this when you think about it. But thinking of the information flow as a function in and of itself has two powerful impacts:

1. It stops us from focusing on the the outputs of our work (acceptance criteria, user stories, requirements, etc.) in isolation in favour of focusing on the information flow process itself.
2. It enables us to focus on what aids the flow of information to, from, and within the team.

Don’t get me wrong: the outputs are important. But not as important or as valuable to the team as getting information to the right place where it can be put to use as soon as possible.

For the record (heh!) I’ve always hated taking meeting notes. So much blah blah blah to get down in a short space of time, and juggling between engaging with the topic of conversation and how best to summarise that point is exhausting. Not to mention that it often seems pointless—how often are meeting notes ever referred back to?

Well, with approximately the same frequency that we look at log files. And aren’t they sort of doing the same thing? Logging—whether technical logs or meeting logs—is a form of risk mitigation. You hope you won’t have to trawl your way through them in the future, but if you do need to, it’s usually a case of boy you really need to.

Persistent data in the field of data processing denotes information that is infrequently accessed and not likely to be modified.

A funny thing happens when you reframe this sort of admin into “the creation of persistent team information”. Suddenly the focus of the meeting notes changes from “what was said” to “what needs to be on the record” and “what could help someone to troubleshoot later?”

Caching, routing, and logging aren’t the only infrastructure concepts that can help frame (and extend) the BA role. I think I could make a solid argument for many if not all components of infrastructure.

Here are some additional examples:

1. Filtering: You do this when you’re selecting what information should be passed on and with what degree of detail. For example, not sharing with the team a suggested enhancement to a feature until it has been validated. This protects the team from unnecessary action in response.
2. Queuing, ordering, and sorting: You do this all the time. But especially when you’re selecting what issues to escalate to your product management, or which things can be parked until later. You can’t do everything at once, so you have to prioritise the important stuff first. Sometimes that email will simply stay unread for a while and that’s okay.
3. Mapping, parsing, and conversion: You do this when you translate information across mental models. For example, when you convert the PO’s feedback into dev language, or when you translate what the dev said into constraints for the PO.

And I’m pretty sure there are more ways to reframe the BA role, and more concepts that we could use to discuss how what we do supports the team. but I suspect I’m belabouring the point now (I can see my partner’s eyes glazing over 😂), [Editor: how did you know?] so I’ll leave it there.

While I was mulling the idea behind this writing this article, I found myself more aware of the parts of my role that are focused on information flow. Suddenly everything was caching, data persistence, flow efficiency, and more. I began to lean into opportunities to enhance the flow, rather than to reject them as “boring admin”, and saw first hand the value it was creating.

In other words, I was seeing the information system.

I suspect we BAs often think our analysis artefacts are the value we’re delivering rather than thinking about the impact of our work on the system. We expend effort on making our artefacts and processes better—we practice how to write better user stories—but we don’t consciously work to create better teams. 

And I think we should. 💛

Disclaimer: This article was written from the perspective of an agile BA. While I’m sure there’s value in applying the idea to non-agile settings, I’ve not done so, nor have I thought that out!

In other words, as with everything in life, apply mindfully to your context!