But the Scrum book says no Business Analysts…..


5 years ago I planted a seed, an Agile Scrum seed at the company where I worked. It took a year to germinate and I actually left the company during that time. I was lucky enough to rejoin to take up the role of a Scrum Master.

The role I left behind was that of a Business Analyst. Like many others I have read all the recommended Agile and Scrum books. They do not speak of the BA role. It becomes very simple, become the PO, become a developer, move into commercial analysis or go to a company not doing agile or doing agile ‘wrong’.

I had the gut feeling that the BA team I so proudly managed would not be required in the new world, I’ve never written this down before and I regret not sharing this view with my team. I protected myself from this fate and moved to another company as a BA whilst I pondered my viewpoint and whether I could leave the profession behind.

8months later I took the decision that the time was right and the opportunity was available to move into Scrum Mastery, I didn’t fancy Product Ownership at that point as I wanted to be able to influence a change in the approach to ‘how’ the work was done not the ‘why’, ‘what’ or ‘when’.

When I returned, my old team had indeed moved out of the new ‘Scrum’ feature teams mostly because they were either seen as ‘waste’ or as a frustrated ‘proxy PO’.  They sat all together away from the teams, making up business cases for upcoming work.  In hindsight it was almost a necessary growing pain for the whole company. We questioned the value of the role, it evolved into product insight and commercial and financial analysis and they are in a really strong position now as a collective analytics, BI and data science team(s).

The standard role of a BA (interface between the business and IT) is too simplistic and means most agile teams fail to document new/changed logic for the future to make, in particular, operational support easier, to make change in that same area easier and cheaper in the future. To consider not only technical (non functional) but also customer facing considerations.

Agile encourages the T shape of skills and embrace exactly that, ‘skills’. Whilst we may question having one person sitting in the BA position, as we sometimes do with QA or SM. We still need the skills that the role normally brings.  We must train the team with those skills even if we make the roles non mandatory. Maybe we should all take the view that we should work to make ourselves redundant, share all our skills and automate as much as we can.

Besides there is always something more interesting to work on 🙂

work to make ourselves redundant, share all our skills and automate as much as we can.

So, fast forward to the present, I have a Scrum team with a BA and a PO, what’s that all about? I no longer see it as an obvious problem but I would advise you to review the team, the skills in that team and the context of the work they are doing. My view now is that you need either role or both roles and occasionally neither.

As businesses ‘go agile’ and they add POs and SMs and if you retain BAs, you will notice that the cost of teams stays quite high, I recently read that on average a traditional Scrum team costs £1million per year.  That’s a lot of revenue they need to generate. Thus the risk is quite high.

So why not start with the problem being solved/the objective being set and review the skills you think you need. Build up those skills as required, add people to the team as required. Start everything like a startup, review the potential value in solving the problem or doing the work and be strict on who you need involved. Its really simple, time invested = cost and we must generate more value than the cost.

Inspired by lean we should move the people to the work, so don’t just assign random features and projects to existing scrum teams, question who is best suited to achieve the goal.

It’s harder to manage but will be a better investment for the business as a whole and should hopefully encourage more learning in your teams, higher engagement and better products, always hopefully leading to happier customers.

we should move the people to the work, so don’t just assign random features and projects to existing scrum teams

We are all valuable and teams need a mix of skills, the lesson here is to be very honest about what skills we need, look to train skills within teams and recruit people eager to learn.

We need to move away from the days whereby to start more work we need a new team and that team by default needed 8-10 people. £1million is a lot of money, invest wisely.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: