Date: 04 July 2012
Waterfall tends to be a pass the baton. Let’s get the business case done, gather some requirements and pass the requirements’ document off to the architect and the business case to the PM.
Waterfall tends to be a pass the baton. Let’s get the business case done, gather some requirements and pass the requirements’ document off to the architect and the business case to the PM. If we’re lucky, we may get brought back in to map out some processes during the execution phase, but otherwise we find out how the project is going when asked to scope out a change or when the project ends and it releases. Sounds very cynical, but is often true unless in a more mature organisation.
Scrum revolves around the backlog and uses iterations to deliver either working software (in a development project) or completed user stories. The backlog is owned by the Product Owner, who often does not have the skills to elicit and document requirements. This, together with the skills to put together a value model to analyse what the priorities on the backlog should be, are skills that the BA can bring to the project.
This means that the BA should be spending time understanding the business through contact with the Product Owner. It implies they understand the requirements and thecontext to them. Bringing this into the Scrum team can be invaluable for the team, especially throughout the sprint to cover detail not discussed in sprint planning or backlog grooming. The relationship built between the Product Owner and the BA should also mean that the BA has access to cover further information should it be required by the team on an ad hoc basis. By no means should this be the norm, but reality suggests that this needs to happen occasionally.
“These requirements are untestable”. I am sure many of us have heard these grumblings from the test team who are usually the last in line to see them once the architect and developers have done their bit. A Scrum team includes the testers, the BA and the developers together from the start – what Takeuchi and Nonaka referred to as “overlapping phases over development”. This encourages conversations about good requirements, testable features and quality code to be discussed at the planning stages of the iteration, rather than sometimes months after the fact once code has been cut. Remember knowledge is perishable.
Having access to the testers improves the quality of the requirements and the acceptance criteria produced by the BA. It means starting with the end in mind.
Continuity on a project right through to the end is often something BA’s long for. Sadly, often once the business case is completed by one BA, the requirements and then completed to another, the delivery and process mapping to another and analysis/options to another. Much knowledge is lost in this approach. While there is benefit in BA’s having deep skills in certain areas, this approach can lead to silos of skill and specialists doing the same job over and over without deeply thinking about what it is they are doing. We believe it is more beneficial to also consider width and breadth of skills across the project as this brings continuity, diversity and ultimately job satisfaction.
Communication is a key skill from the business analyst – the ability to talk the language of the business and of the team is extremely valuable to the organisation. The BA can act as the ‘glue’ and facilitator of closer relationships between both sides of the organisation, often resulting in huge benefit. To the business change leader in a project, the BA can help translate what is possible with technology into business needs and language.
While having a strong Product Owner is critical, there are times when the PO may need to nominate a stand-in (travel, for example). It is not uncommon for the BA to perform some of the role of the Product Owner. This can be quite a big step up for a BA. However, with a close working relationship with business and customers, this can sometimes be a logical progression. We add a word of caution here however. We have seen many instances of Product Owners delegating their role to BA’s. This is utterly unacceptable and, as professionals, we should strong resist this. Scrum is explicitly clear on this for good reason – if the business can’t explain what benefit it believes it is going to get from the next sprint, then we should not be continuing development. Period. As Ken Schwaber says in his excellent blog Product Owners, not Proxies.
In summary, while the BA plays an important part in waterfall projects, they become even more important in Scrum. The role changes from one based on working primarily at the start of the process (business case, requirements etc) to one that maintains a strong relationship and constant communication throughout the entire life of the project. For a good BA, this can provide enormous job satisfaction.
