Business analysts as a workaround for organizational problems

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:

In Scrum zijn er geen business analisten!

In Scrum zijn er geen business analisten!

Hmm. Toch wel.

In Scrum bestaat de “rol” business analist niet, en  ook geen andere typische IT project rollen zoals functioneel analist, technisch analist, architect, systeembeheerder, project manager, …

Het Scrum framework definieert 3 rollen:

  • Product eigenaar
  • Ontwikkelaars (het team)
  • Scrum master

Het “ontwikkel” team omvat alle individuen met alle vaardigheden en expertises om het product te “ontwikkelen”. In feite kunnen we dit ook het “product” team heten, de term “ontwikkelaar” neigt teveel om enkel (software) ontwikkelaars aan te spreken.

Het team oefent dus alle vaardigheden en expertises uit om tot een succesvolle ontwikkeling van het product te komen. Het team is in principe cross-functioneel en een teamlid hoeft zich niet te beperken tot een bepaalde rol of activiteit. Volgens de nood en planning kan elk teamlid een bepaalde activiteit uitoefenen… analyse, design, ontwikkeling, testing, planning, project administratie, … . We moedigen dit aan in een cross-functioneel team zodat teamleden van elkaar kunnen leren en kennis gedeeld / verrijkt wordt.

“Business analyse” omvat uiteraard meerdere vaardigheden en een analist is actief op vele terreinen: marketing & communicatie, business, functioneel, technisch, … . De business analist heeft typisch vaardigheden om de vertaalslag te maken tussen marketing en technische mensen.

Agile en analyse?

Als “business analist” vervullen we de facto meerdere taken. Een agile analist zou men kunnen omschrijven als:

Een agile analist combineert business, functionele, techische analyse en acceptatie testen. De agile analist streeft naar transparantie in communicatie en het gehele project, werkt in korte iteraties en is continue op zoek naar feedback. De agile analist creëert samen met de product eigenaar en de andere teamleden een visie en bouwt mee aan het product, iteratie na iteratie.

Bron: volledig artikel (