Business analysis

A business analyst, or more generally, a business consultant, works together with multiple stakeholders to deliver the greatest value and is equally a driving force to enable change in an organization by defining needs and recommending solutions.

As such, business analysis is a much needed practice. Business analysis is an umbrella term: many other specific job titles exist. There even exists a business analysis body of knowledge and a business analysis career path (to take you to a mgmt. level) (a pity my career doesn’t advance that fast…).

In fact, performing business analysis can be a much satisfying job.

Business analysts as a workaround for organizational problems

Unfortunately – based on my experiences, business analysts are often squeezed between business and IT stakeholders. A group of business analysts is put in place to go on with the continuous task of translating needs and requirements, communicating scope changes from business to IT, and communicating constraints and drawbacks vice-versa; and this continues for the full project life-cycle.

In fact, business analysts are needed as a workaround for organizational problems. Organisations who cannot manage to have a direct, constructive and collaborative approach with all stakeholders will need a unit of business analysts to – what’s traditionally called – bridge the gap (note: in some organisations this figural speaking “gap” is the size of the grand canyon). In such a setup, the output of business analysis mostly happens in the format of some deliverables (documents), with a handover to the next stakeholder – this handover is, by definition, a form of waste.

It’s directly related to the organizational structure. Organizations traditionally shaped have separate silos “business”, “IT”, “operations”, with often intermediate organizational units to make all these people work together.

In a setup where people are collaborating directly in the same team, this gap will naturally be smaller or even dissolve. Claiming business and non-business people cannot directly interact and collaborate is a false prejudgement and it’s even plain insulting. I strongly believe it’s in the vast interest of an organization to share experiences, to create an environment that stimulates learning and improvement, and where people are encouraged to engage in practicing secondary skills.

At the team level

It’s clear that on a team level, the agile spirit translates into a cross-functional team. On the one end of the spectrum, there are small companies, start-ups and spin-offs which naturally have a spirit of cross-collaboration, cross-duties and ownership as a whole. On the other end of the spectrum, in large organizations, the challenges are profound. It’s not straightforward to create cross-functional teams and to establish collective ownership.

Different person profiles may exist in a team or by definition are not allowed to exist. A team – as a whole – will need to be able to perform the different tasks necessary to build whatever they are building – if they don’t have the skills or competences available within the team they rely upon an external resource, or more preferred: they acquire that skill or competence by learning.

The product owner is the business representative responsible and accountable for maximizing business value. That person is responsible for maximizing business value. While elaborating business needs, he’ll perform business analysis (in the broad sense of the term).

The team – together with the business representative will put effort to understand the business needs, analyse and refine and to communicate those business needs and requirements – as necessary; in any kind of format as necessary (oral or written).

As business needs tend to change quickly, we prefer to define the requirements fine-grained for the next work items (1 item in a single-piece work flow, or if working iteration-based, for the next iteration). Other items for the future remain coarse-grained defined. As we proceed with the work, the team analysis and refines, together with the product owner – who also constantly re-assesses the priority and value.

Business analysis revisited

Business analysis encompasses many other activities than simply translating business needs. Business analysis is a skill performed as a team, spreading knowledge about what the business wants within the team, and trying to minimize any hand-off. In fact, this description applies to any skill. Earlier, we wrote a post with the question if business analysis still exists in an agile team. Of course it does. But take care: we do not want to establish a business analyst who acts as customer proxy or proxy product owner. Business analysis is performed collaboratively by the product owner and the team.

More reading:

• When You Have No Product Owner At All
• Rethinking the Role of Business Analysts: Towards Agile Business Analysts?
• Agile Extension to the BABOK® Guide