My first fully-backend project as a Business Analyst (BA) was quite the awakening. I was dropped into a tsunami of jargon, cloud terminologies, architectural diagrams, with no UI or end-customers in sight. Meetings would routinely go into spirited discussions on Kubernetes clusters and orphaned helm charts. Being lost was the de-facto, to the point that I even questioned my ability to contribute. It took me a while, but I eventually understood that BA skills transcend the type of product you’re delivering, as they focus on universal key concepts. Even if you don’t have a dedicated BA on your team, but want to improve the efficiency of your delivery, here are a few things to consider.
1. Simplification
Developers love solving problems, almost as much as they love telling you how they did it. They can go deep into issues with a ton of jargon, which unfortunately may sometimes lose the audience. As fascinating as it might be to hear how the team deftly staved off a potential production incident by increasing the worker nodes from t3.medium to m4.large, this may not be necessary in all conversations. In our world of back-to-back zoom meetings, stakeholders may not have the time or the attention span to absorb the full context, so it’s important to get to the crux of the issue quickly, using the simplest terms possible. This is especially useful when speaking to wider audiences (e.g. product demos) and less involved senior stakeholders. If you’re having trouble with this, think of situations where you’ve spoken to someone less fluent in your native language; did you find yourself slowing down, using simpler vocabulary and becoming a lot more direct? Same way, try simplifying the way your team communicates to ensure your stakeholders stay fully informed and engaged throughout the delivery process.
2. Streamlining processes
BAs spend a lot of time looking at existing processes and trying to improve them . These could range from something as generic as onboarding new team members to triaging critical security alerts across multiple teams, response timelines and bureaucratic forums. Establishing processes allows teams to focus more on their work and less on navigating complexity. If you deal with many external teams, this is especially important as work that requires collaboration takes significantly longer than work that does not. A lot of this is due to miscommunication, incorrect assumptions, context switching, validation delays and getting the timing right so both sides are ready to continue the work during the multiple handoffs. If you need to visualize these bottlenecks, setting up a dashboard on your preferred project management platform can really help. So try going through your current processes and start determining what needs to be improved. Your team will thank you for it.
3. Looking at the big picture
One of the most difficult things in infrastructure development is defining the milestones, as a lot of the work doesn’t fit into traditional “features” per se. This has a few implications. One is development malaise, where releases tend to become routine (What’s that? Team Alpha is celebrating their 10th go-live already? Should we start celebrating how we had zero issues during our last vulnerability scan?) Another is that it gets difficult to track work that's constantly in-progress due to continuous improvements. We are agile and constantly iterating, after all. So how do you set a logical limit to the work, one that’s not too ambitious yet still meaningful enough to call a milestone? This is where you need to start thinking big. What are we really trying to achieve? What will this mean for the other teams that depend on us? How does this align with the overall vision of the product? Once you take a step back to look at the overall value of the work, you can finally begin to create meaningful, trackable milestones that give stakeholders better visibility of the work and make prioritizing a whole lot easier.
4. Measuring success
Finally, the most successful products continuously measure their success. This is especially important if you want to have meaningful conversations with your stakeholders on what to build next and influence the product strategy. Success markers can come from customer satisfaction, higher sales, usage of the product etc. Unfortunately for infrastructure, knowing that you exist can sometimes mean that something has gone horribly wrong. So how to translate value to stakeholders when your success is predicated on non-issues for your end users? A great approach is to use the four key metrics to look at your delivery health. Alternatively, try having conversations with your stakeholders to set the success criteria (ideally based on your milestones) and align on how to track them.
Hope the above has encouraged you to try some typical BA techniques. Feel free to also approach our vibrant BA community for advice. We, too, love solving problems, almost as much as we love telling you how we did it.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.
