I had a conversation with an ex-colleague who has recently transitioned to Agile and is still a little unsure about the approach. As is often the case, he wanted to use me as a sounding board. It turned out to be a very interesting discussion.
Part of his role involves working in Scrum, with another Scrum team within a part of the organisation that is held up as an agile champion. What he found surprising was that the team had been operating with only a Product Owner and without a Scrum Master for quite some time.
This might have been manageable but it seems that the product backlog was not maintained, user stories were lacking, and the PO did not know which features were to be added, including which defects to be fixed.
Perhaps inevitably, the product was behind time on expected new features, and defects preventing new features from being added were annoyingly persistent.
When he asked what was going to be done to address this, he was told that a Scrum Master would not be forthcoming any time soon, and that a Business Analyst (BA) would be assigned at <50% instead, and with instructions not to occupy the Scrum Master space.
Product Owner (PO), Scrum Master (SM), and the Team
According to Jeff Sutherland (one of the creators of Scrum and co-writer of the Agile Manifesto in 2001), these three roles perform specific tasks. A BA is not a role, and to also operate without a Scrum Master it was clear that my ex-colleague was right to be puzzled.
It isn’t right to dogmatically say that having a BA will lead to failure in Scrum. A BA is often a multi-skilled individual, the type of person who is very useful in a Scrum team. The perceived issue with having roles other than the PO and SM on the team is that this creates a “my job / your job” approach, with people unwilling to do certain jobs.
The BA in Scrum / the Scrum BA
So, is the BA role dead? A role to be left behind with the Waterfall approach? Something to be scoffed at by agile evangelists?
As I've mentioned, a BA trained team member can be very valuable in a Scrum Team. A BA will have good modelling and analysis skills, possibly formally acquired, and experience gained from working across the entire project life cycle.
BA skills will always be needed and the reality is that many Scrum Teams will consist of domain experts, with little project or delivery experience, and without the skills of the BA.
In fact, a BA trained individual can make a great Scrum Master, Product Owner (if they have good domain knowledge and are empowered to make decisions), or a multi skilled Team member. A BA skilled team member can be the one who trains the the rest of the Scrum Team, and impart the skills that are possessed by the BA. For example, how to write test cases, how to state user stories that are requirements rather than solutions, and to be able to design team processes.
For these reasons, the Scrum BA is a positive addition to the Scrum Team, whose activities should not be limited, through self imposition or otherwise, due to a designation of 'Business Analyst".
A great Scrum BA recognises that the objective of the team is to create value, and it's team work that matters.
A Scrum Team with a Business Analyst but no Scrum Master
Lets have a quick recap on what a Scrum Master does and how the Scrum Team is served. A Scrum Master:
- Coaches the Scrum team in self-organisation and cross-functionality
- Helps the Scrum Team to create high-value products
- Helps the Scrum Team understand the need for clear and concise Product Backlog items
- Removes impediments to the team’s progress
- Coaches the team in environments in which Scrum is not yet fully adopted and understood
- Facilitates Scrum events
And will serve the Product Owner in the following way:
- Finds techniques for effective Product Backlog management.
- Helps the Product Owner to arrange and understand the Product Backlog.
With that in mind, let's return to the start of this story, and that a team considered to be working as a Scrum team:
- Does not have a Scrum Master
- Will have a Business Analyst
- That the Business Analyst will not perform in the role of Scrum Master
- Does not have the expected Scrum ceremonies
I was also told by my poor suffering acquaintance, that the team is expected, from a more senior source, to just 'get on'; to make it happen, "to be agile".
Should we abandon all pretense that the team is working in Scrum and instead is working in heroic desperation mode? Late product releases and a lack of backlog transparency would suggest this is the case. How do we square this circle?
The team can still work in an agile way but in reality, the Scrum Team is actually working in "Scrum ... but" mode. In other words, the 'Scrum Team' is not actually a Scrum Team. It is working in a similar style, using words taken from Scrum, but for a significant period of time has not been operating as Scrum.
A Scrum Team always comprises a Product Owner, Development Team, and a Scrum Master. There are ceremonies that must take place.
If this isn't the case, then it's just not Scrum.