4: What are the Risks of Not Having an Agile Business
Analyst?
79
current business processes to see beyond them, the Agile
business analyst is able to provide an objective perspective
on the most effective solution.
The online application form described in the previous
section is an example of a situation where business users
assumed that putting the current paper-based forms online
would make the process more efficient. Without a peer
resource to pair with them and question this assumption, it
is likely this would have been the requested capability
brought to the Agile development team in the requirements
review session; and equally likely the online form with
online payments and integration into the application
processing system would have been the delivered
solution. This means the Agile approach would have
delivered a fully functional, high quality, business user-
approved online application form that provided minimal net
gains for the organization. In essence, the software
development would have been a success, and the overall
project would have been a failure.
What to do when the business user is not available
There will come a time in every Agile project when even
the most well-intentioned business users will be unavailable
to provide the Agile developers with real-time answers to
their questions or with feedback on the software in
progress. So what does the Agile development team do
when the business users have limited (or no) availability to
work with the developers?
Unless business users are assigned to work with the Agile
team on a full-time basis, they will inevitably need to
balance their ongoing involvement on the project with their
day-to-day responsibilities. Iterative Agile methods (such as
4: What are the Risks of Not Having an Agile Business
Analyst?
80
Scrum) endeavor to mitigate this risk by ensuring the
business users are minimally available to work with the
team at the iteration planning and review sessions, that is,
once every two to four weeks, but is this really enough
involvement to address the risk of misaligned requirements
and wasted development work? What happens if the Agile
team needs information, decisions, or feedback from the
business users to support their day-to-day work in the 10 to
20 working days in between these sessions?
Earlier in this section, it was identified that the enthusiasm
of the business users for the potential of a new solution can
be a double-edged sword. On the one hand, their excitement
can motivate them to become incredibly involved in the
project, freeing up their schedules to make themselves as
available as possible to work with the Agile team. On the
other hand, their excitement can also result in their going a
bit overboard in specifying the capabilities of the new
solution. This is why Agile approaches rely on the
prioritization of features as the sanity check that keeps the
business users' expectations grounded.
What was not identified is that the business users' initial
excitement for the project is likely to be toned down over
time, partially because of the novelty wearing off, but
mostly because of the competing commitments of their
primary roles.
Although the ongoing delivery of fully functional software
that is the hallmark of Agile approaches is able to maintain
levels of business user motivation far more than the 'wait
and see' model of traditional waterfall approaches, the
reality is that business users continue to have
responsibilities in their day-to-day work that can place
significant demands on their time and on their focus. The

Get The Power of the Agile Business Analyst: 30 Surprising Ways a Business Analyst Can Add Value to Your Agile Development Team now with O’Reilly online learning.

O’Reilly members experience live online training, plus books, videos, and digital content from 200+ publishers.