Specialised Roles In Scrum – Are Business Analysts Part Of A Scrum Team ?

Image courtesy of [image creator name] / FreeDigitalPhotos.net

One of the first things I try to instil into scrum teams is that we are all a team working on the same goal, towards the same target. Often to support this I strip people of their titles within the context of the team. There is nothing worse to destroy a team culture than people working with the confides of a job title. Emphasising roles creates dependencies, bottlenecks and blame cultures and as a result, reduces productivity through knowledge silo’s and counter productive workflow methods. At the Scrum Gathering Barcelona 2012, Michael Feathers mentioned in his keynote that having a QA in a team encourages lazy developers and within a traditional team culture, I couldn’t agree more!

The common counter argument to stripping titles is that people are not generalist. For instance a tester might not be able to write code. Obviously this in most cases is true. However without the emphasis on a title, what you are left with is abilities and skills which the team call upon to complete a task together. You will have specialists who are obviously better than others at certain tasks and they would naturally be more suitable to tackle the relevant issue. It would be inefficient though to assume that all tasks of a particular type are the responsibility of a given job title. Everyone in the team is responsible for quality, not just the testing roles!

A good example of demonstrating the oxymoron of specialised generalist is seen in almost all team sports. Lets take for example a football team. You have specialised roles which include, goalkeepers, defenders, mid-fielders and attack. You even have specialisation within this which includes centre back, wing backs, strikers and so on. Lets compare this to a software team; the team is often divided by developers and testers. However you might have within these roles more specialisation such as QA’s, automated testers, front-end developers, sys-admin and so on. Returning to the soccer analogy, let’s think how a team functions together?

A football team structures themselves into the specialised skills set. Defenders will often stay back and attackers will move upfront. However when the team find themselves in a certain position the team adapt and play out of position to support the ultimate goal of the team which is to score as much as possible and not concede goals. That means that when a midfielder is committed, the striker might fall back; when a there is an attacking opportunity a defender might move upfront to try and score or support the attack and so on. Although the players dominate the game strategy by their specialist skills, they are generalist when required as they adapt to the game in play. These are specialists, playing out of position to support the team and win the match!

I’m sure the above seems blatantly obvious to most. We see this pattern all the time in sport. Yet in a software environment we structure teams in the complete opposite manner. Traditionally we actively discourage people to do anything which is not part of their assumed roles, and confine people by titles. This is not a team structure, but a production line strategy which is embedded in the working culture of offices which actively encourages people to work against each other.

An example of people getting hung up on titles is the common questions which often arises in Scrum which is that the Business Analyst role is not required. This stems from the fundamental principle that the people implementing the work should discover the solution. I completely agree with this in most cases. A Business Analyst in the traditional sense is not part of a cross-functional team. However why can’t the business analyst be part of the team ? ( Roman Pichler offers more information on this here )

If we look at the teams needs, we should not look at a title to solve a problem, but the skills required to strengthen a team. Therefore a business analyst isn’t a title, but a person with a set of skills. In some cases this maybe to obtain better knowledge on the problem to know what is desired by the business to provide a solution. In some cases this might be analysis within a complex domain which a product owner might not be able to fully support although the requirements are to build on top of it. There are many different applications where the skill set can be used as part of the team, to help the team deliver. Ensuring the business requirements are fully captured and understood can significantly add value to the production of a team. For example it maybe advantageous to provide knowledge to the PO to be able to break up stories into smaller stories which can then be prioritised or provide domain knowledge to the team. Yes you don’t need to be a business analyst to discover this information, but the skills of a business analyst could be used in a scrum team.

A Business Analyst who is working with the team to help the team, could be a valuable asset depending on the environment and goal. Obviously this highly depends on the individual of course. If the business analyst is telling the team how to implement the solution, this could take ownership away from the team and also challenge a product owners impact which could be costly for the business. Imagine this role on a football pitch, it would never work. However if the role was to gather information on the opponents strategy or to provide information on the playing conditions it might contribute value to help the team.

A business analyst who can work in an agile structure, who doesn’t provide unnecessary documentation who grasps the concept of adding more information as the stories get closer to planning or ‘Just In Time‘ concepts, can help the team and fit perfectly well within an agile environment. However in order to undertake this role, some of the traditional concepts of heavy documentation and deep planning will be challenged. A good comparison to this is predicting the weather. We can see whats coming in the next few days with some confidence, beyond that there is a higher risk of change which gets more unpredictable over time.

All in all, if you work as a team to accomplish a goal, titles become less restrictive and people are then truly valued. This is where you see a world of difference in quality, performance and innovation stemming from a sense of true ownership and belonging. A business analyst in the traditional sense is not required not because their skills are not needed on an individual level, but because the traditional practice are redundant in an agile context.  However re-applying those skills on an individual level into an agile context can fit well within agile teams. I have experienced first hand the benefits of working with business analysts in scrum teams and I am confident that their input significantly helped the team.

Be the first to comment

Leave a Reply

Your email address will not be published.