Agile Business Analyst
In 2014 I changed my vocation from front-end architect to Business Analyst. But what does a Business Analyst actually do?
Let's start with the basic description of the job, courtesy of CIO.com.
Business analysts (BAs) are responsible for bridging the gap between IT and the business using data analytics to assess processes, determine requirements and deliver data-driven recommendations and reports to executives and stakeholders. BAs engage with business leaders and users to understand how data-driven changes to process, products, services, software and hardware can improve efficiencies and add value. They must articulate those ideas but also balance them against what’s technologically feasible and financially and functionally reasonable. Depending on the role, you might work with data sets to improve products, hardware, tools, software, services or process.
CIO.com
Business analyst is a container term. A business analyst tends to have a specific focus:
- Business developer – to identify the organisation's business needs and business' opportunities;
- Business model analysis – to define the organisation's policies and market approaches;
- Process design – to standardise the organisation's workflows;
- Systems analysis – the interpretation of business rules and requirements for technical systems (generally within IT);
The business analyst, sometimes, is someone who is a part of the business operation and works with Information Technology to improve the quality of the services being delivered, sometimes assisting in Integration and Testing of new solutions. Business Analysts act as a liaison between management and technical developers.
Personal experience
One of the main reasons for becoming a BA is wanting to make broader use of your skills. An organisation likes people with deep knowledge of the internal workings of the company, and the various technologies and business practices those entail. It is extremely beneficial for an organisation with a big turnover of external developers to have people be able to get those started quickly and guide them through the various corporate mazes.
In practice
At my current employer, and added layer of complexity is that a Business Analyst is part of a Scrum team. It restricts the usefulness of the analyst as their influence on strategy is limited in an operational team. A lot of the knowledge and skills has an overlap with the Product Owner and Scrum Master.
Let's dig a little deeper, and examine the work I do, or should be doing, using the military's model for the four levels of war.
1. Tactical
The tactical level of warfare is that level where men meet and fight from the individual level through the division. It is the realm of skirmishes, engagements, and battles. Planning at the tactical level starts at 'now' and occurs out to roughly 48 hours in the future, or at most a few weeks. The tactical level of warfare is where one sees the face of battle.
- Create, document and improve team processes;
- Create technical data models, such as data requirements for a software application;
- Gathering of requirements or assisting the Product owner in gathering them;
- Create standards for requirements and tickets;
- Function as a liaison between the business side of an enterprise and the providers of IT services, although this tends to clash with Product Owner responsibilities.
- Advice on technical solutions and issues, function as a buffer for the technical members of the team so they don't have to spend their whole day answering questions.
2. Operational
Operational level planning occurs with the intent of setting missions and objectives that will bend the enemy to your will in an entire theater of operations. Think of this as the blueprint that helps you build a house from a bunch of bricks.
- Help crafting business cases based on risk and return;
- Create road maps for software development;
- Gather data for the Product owner to base their decisions on;
- Liaise with the Software architecture team to prepare proposals and spot potential obstacles;
- Being a central player in software selection, managing the requirements and mapping the stakeholders.
3. Strategic
Strategic plans aim for objectives that lead directly to, or at least significantly toward, peace. In other words, these plans seek to answer the question, "How will we win this war?"
- Translate strategic goals into operational plans for the team;
- Analyse the strategic goals and perform an advance risk and reward assessment;
- Help craft a team strategy;
- Keep an eye on that operational plans stay in alignment with strategic goals.
4. Political
Decisions at this level involve the interrelationships between allies, decisions regarding the factors of production, the national will, and societal issues. And it is here that another profession holds great sway, one that operates in the realm of influencing civilians.
The political level is not necessarily a level where a BA is very active. It is the realm of top management. But that doesn't mean there is no role at all to play.
- Help the Product owner and scrum master to navigate the political landscape;
- Provide timely data and reports to support political arguments.
Growth
When you work in a big company, the personal development focus tends not to be on what you do now, but on things that you need to start doing, and growth. In the current context there a several paths visible to me.
- Become a Product Owner. This implies full focus on stakeholder management and backlog refinement.
- Become a Scrum Master. This implies full focus on helping structuring the team and improving processes.
- Improve the current skill set and invest in helping Scrum masters, Product Owners and new Business Analysts develop the same skills to a higher standard. This implies some seniority.
- Slide sideways to another team, to use their skill set to help in a different context.
- Slide upwards and focus more on broader strategic and tactical concerns on a department level. This implies buy-in from management for this type of placement.
Not all paths lead to personal growth, and honestly, if you are stuck in one development team at a time it is fairly limiting. The best place for a business analyst is near the Architecture team or near the Business to maximise their liaison super powers.
For me personally, I'm perfectly happy to stay in my team, but at least perform a more diverse set of tasks, thus "enhancing my seniority".