BA as team infrastructure!
Or, a new way of thinking about business analysis
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…
But first, TL;DR:
⮑ Teams run on information
⮑ And BAs deal with information
⮑ In practice, BA’s do lots of infrastructure-like activities
⮑ Including caching, routing and logging… and more
⮑ Thinking of BAs in this way is helpful!
What is Team Infrastructure?
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…
Going with the (information) flow!
And yet, despite the importance of information flow in a team, we typically downplay the parts of the BA role that are focused on facilitating it for our team and focus on the flow of information to us and our requirements (or whatever we’re defining). We’re analysts for heaven’s sake—we analyse and define. We don’t do admin.
But I suspect that this is actually limiting the value a BA can bring to a team. We’re already dealing in information. By reframing our work, or seeing it through the lens of Team Infrastructure, we can radically increase the value we’re adding to our teams, projects, and organisations—and with little additional effort.
Now I’m not saying the BA role is the only role on the team contributing to team infrastructure: everyone needs to contribute for the team to function. However, the BA role of being that connector between different perspectives (piggy-in-the-middle) makes us uniquely placed to contribute to the solution.
And by conceptualising our work this way, we can serve the team (not just ourselves or our outputs) better. And serving the team is especially important as it is the mechanism through which we deliver value to our customers.
So, how are BAs infrastructure?
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.
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.
Unlike gossip, team information—especially when being used by other people as reference material—should be as complete and as accurate as possible. Some information (such as team members names) are slow to change, other info is volatile (such as what a team member might be working on right now).
When presenting your info-cache as an accurate source, you need to be aware of when your information is getting stale, and when you should refresh your cache.
Happily, no one expects this kind of information to be 100% accurate all the time. You are better off considering yourself an eventually consistent source. But even eventually consistent information requires effort to collect. To do this really well you should be having regular catch-ups and chats with other information nodes in your network.
And finally, remember that some things simply aren’t suitable for caching (the ‘no cache header’ scenario). In this situation, you’re better off routing the request to the appropriate authority or expert.
Which is a perfect segue to…
Business Analyst as router
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:
- 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.
- 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.
- 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:
- 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.
- 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.
Avoid the scenic route
However, this is not to say that you should stop producing artefacts and outputs in favour of being the go-to information junkie. We’re trying to get shit done after all.
Oftentimes those outputs and documents are the means by which the BA-as-infrastructure is providing information persistence and permanent reference points for the team—another key BA value add.
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?”
Longer term storage
Truthfully, a lot of what we do is formally documenting things. What are requirements if not a form of persistent record keeping of what needs to happen in order to meet a business objective?
We document them so that there is a central source of truth for what was agreed so the team understands what is being attempted (and why). And we store them in requirements format because that’s the format best suited for longer term storage and reference.
Lawdy, that feels like a whole topic in and of itself!
Not yet convinced?
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:
- 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.
- 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.
- 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!
Hey, tell me what you think!
Please do hit me up on Linkedin or by email if you have any feedback! I’m always up for random questions, and I’d love to know what you think of this article!