The Agile BA - Visionate Process Asset - The Agile BA.pdfsome ways that the Business Analyst role...
Transcript of The Agile BA - Visionate Process Asset - The Agile BA.pdfsome ways that the Business Analyst role...
T h i s d o c u m e n t i s p r o v i d e d f r e e f o r u s e p r o v i d e d t h a t t h e f o r m a t t i n g i s n o t c h a n g e d a n d c o p y r i g h t n o t i c e s a r e m a i n t a i n e d . R e a d e r s a r e w e l c o m e t o m a k e a n d d i s t r i b u t e m u l t i p l e c o p i e s o f t h i s d o c u m e n t .
v i s i o n a t e . c o . n z
The Agile BA
A Visionate process asset
Version: 1.0 Version date: March 2015
www.visionate.co.nz P a g e | 2
Document Information
VERSI ON REVI SI ON DATE DESCR IPTI ON EDITOR
1.0 Mar 2015 Init ial Creat ion Visionate
Contents
Document Information ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
The Agile Chal lenge ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Flexing to the Agi le Environment ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Scrum Master .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Product Owner ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Agile Requirements Analysis .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Value Realisation ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Solution Specif ication ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Technical Activit ies .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Configurable Systems.... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Testing ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Conclusion ... . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 3
The Agile Challenge
As Business Analysts , we tend to be passionate and proud of what we do. We have invested the time and effort to develop ourselves and fine -tune our analytical skillset to the best of our ability. And it has taken a significant amount of time for the IT industry as a whole to truly appreciate the role and value that the BA brings to project delivery. We are now in a time when many organisations realise that BAs are indispensable, and this brings us great career satisfaction.
With the rising popularity of Agile-Scrum, we have seen an apparent shift of focus around the execution of project related analysis. We may feel that our hard won reputations are threatened by this new paradigm . The Agile approach encourages a reduction in detailed analysis and a scaling back of traditional documentation. There is a push towards generalist rather than specialist roles, and some might even go so far as to suggest that the analyst has become redundant in Agile environments . Given the situation, it’s no wonder that some BAs feel bewildered and anxious about the future of business analysis .
But as the Agile methodology has bedded itself in and we have observed how it truly functions in practice, we can see that there is no need for BAs to feel this degree of anxiety about their careers. Agile-Scrum does not remove the demand for the specialised analytical skills that we bring to the table. The BA skillset is still of great value within the Agile context. But it does mean that BAs will need to be flexible in how they perceive their role within the project team. The key to engaging with an Agile-Scrum project is to understand the approach more clearly, and to recognise how we as BAs can flex our hard-won expertise to contribute and provide value.
In the following pages we will examine some ways that the Business Analyst role can engage in an Agile-Scrum approach.
Note: in this document we will simply outline how the BA role applies to Scrum . The document is not intended to be an exposition of the Agile-Scrum method. As such, a familiarity with Scrum is assumed.
www.visionate.co.nz P a g e | 4
Traditional SDLC Model
The straata® version of the V Model represents the IT project lifecycle.
In an Agile project, these activities are stil l addressed, but the timing,
depth of detail and rigour may differ from the traditional approach. We
will use this model to structure our discussion and consider the role of
the Business Analyst in these activities within the Agile context.
Flexing to the Agile Environment
The aim of Agile, where appropriate, is to allow project teams to bypass
the formal approach used in Waterfall, thereby getting more work done
in less time. The effectiveness of the Agile approach depends on the
size and nature of the project, as well as organisational culture and
tolerance for risk. There are many different types of Agile
methodologies, with Scrum being the mos t popular.
© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 5
Agile methodology does not mean ‘no method’, and in this context the
value that the BA brings to Agile-Scrum in terms of applying a structured
analytical approach should not be underestimated.
There is great value in ensuring that amidst the swift and collaborative
environment on an Agile project, that a degree of rigour is maintained
to ensure that the project addresses the underlying business need and
provides genuine value to the organisation . This does not mean weighty
overhead and paralysis by analysis ; it means right-sized and effective
approaches to assure quality and ensure that the business value is
realised.
We will now look at the different roles and activities that the BA can
assist with.
Scrum Master
In Agile-Scrum terms, project management is
a shared responsibility of the self -organising
Scrum team. In practice, however, this
concept can become more aspirational than
real, at least until such a time as Agile -Scrum
has been well established within the
organisation and the Scrum teams have
accepted and taken ownership of managing
their own projects. In this context, taking
responsibil ity for the quality outputs of other people is a challenging
concept for many in IT, irrespective of their area of specialisation.
The Agile-Scum role of Scrum Master is not meant to be a project
management role. The Scrum Master is meant to be a mentor and guide
for the team to assist them in taking joint ownership. In practice
though, because of a reluctance to take shared ownership, or an
unfamiliarity with doing so, the Scrum Master will often wind up acting
as a de-facto Project Manager.
www.visionate.co.nz P a g e | 6
Irrespective of how the Scrum Master role is applied, as Business
Analysts we are ideal candidates for the role. We are already
accustomed to working with all roles in the SDLC to ensure that the
business benefit we help the business define at the earliest stage of
requirements, is designed, implemented, tested and deployed to ensure
value for our business stakeholders. Often in smaller scale waterfall
style projects, we may have acted as the Project Manager and as such
are accustomed to applying project management techniques.
So taking on the role of the Scrum Master is a natural area that we as
BAs can flex to in support of the Agile-Scrum method.
Product Owner
The Scrum team includes the formal role of Product
Owner. This individual is essentially the
representative for the business and is empowered to
make immediate decisions within the context of the
project. The Product Owner ensures that a focus on
the business benefit is maintained at all times and
that the viewpoints of all relevant stakeholders are
considered. Ultimately the Product Owner is
responsible for ensuring the project’s success.
In the ideal Agile environment, a dedicated Product Owner fro m the
business is available on a full -time basis to the project. However for
some organisations, this is simply not practical. The primary focus for
business people is running the business, so dedicating themselves to
fulltime project delivery is not feasible. In this scenario, the individual
best suited to step in as Product Owner is the Business Analyst. The BA
has the necessary skills and experience when it comes to understanding
the needs and drivers for the business. In this situation we can end up
with one of two scenarios. The first being where a business Product
Owner is available to the project part -time and attends only key
meetings and planning sessions. Outside of these sessions, the Business
Analyst supports the Product Owner by liaising with them and acting on
© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 7
their behalf. The second scenario occurs where there simply is no
Product Owner available from the business and so the Business Analyst
steps into this role full -time. In this way, the skillset of the Business
Analyst is indispensable in terms of supporting the objectives of the
Scrum team.
In the context of either supporting or being the fulltime Product Owner,
the Business Analyst will provide valuable structure in terms of
stakeholder engagement. A key thing to remember with Agile projects
is that just because the Product Owner represents the business and has
decision making power, this doesn’t mean they always know what every
area of the business needs. The danger here is that we may end up
following the restricted viewpoint o f a single business representative.
The key activity is that of stakeholder engagement, a core BA focus area,
and a critical expertise that we are able to provide to the project.
Agile Requirements Analysis
In terms of analysis, the Scrum approach does
not aim to define requirements with utmost
rigour and depth at the beginning of the
project. The reason for this is to support
speed and agility in delivering a project. This
approach allows for maximum flexibility in an
environment where the requirements are
changeable and the organisation does not
wish to spend a great deal of time attempting
to pin down the detail upfront. Requirements are understood at the
highest level at the start of a project, with the detailed requirements
being articulated just before the iteration or sprint where the
development is to take place.
In an Agile project, the preference is often to articulate requirements
as user stories. The user story captures the essence of the business
need and is not examined and elaborated u pon until just prior to
development – this is termed just-in-time analysis . These user stories
www.visionate.co.nz P a g e | 8
are prioritised by the Product Owner and held in the product backlog
which acts as a requirements repository. Like the Product Owner, the
product backlog is also a formal Agile-Scrum construct.
During the inception phase of the Scrum project, headline requirements
are identified and captured as epics. An epic is a large user story which
is typically too big to implement in a single iteration. Epics are then
decomposed into smaller user stories during the course of the project.
Scrum is primarily a software development methodology and the Scrum
team operates in iterations during which collaborative development
takes place. It is therefore important to note that much of the
traditional requirements analysis takes place outside of the iteration,
and as such outside the Scrum team. The Business Analyst works with
the Product Owner to create and refine the product backlog. The
Analyst typically works one to two iterations ahead of the team to make
sure the epics are decomposed into user stories and the necessary detail
is ready for the team to pick up and run with. As such, there is still very
much a place within the Agile project for a Business Analyst to apply
skill and rigour to process of identifying, validating , decomposing and
prioritising the requirements.
Over time, there has been a shift in attitude within Agile projects
towards documentation. In the early days, committing anything to
paper beyond user stories and acceptance criteria was frowned upon.
This made the Business Analyst’s role challenging as most traditional
BAs are experts in producing structured documentation. So to be
plunged into a world where documents were not permitted was
somewhat disconcerting. But these days, there is an appreciation within
Agile for the value of lightweight documentation. This is surely a
heartening shift for most BAs, and revalidates one of our hard earned
and well-practiced skillsets.
© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 9
In their zeal to embrace the Agile philosophy, advocates of the approach
can become unnecessarily resistant to anything that smells l ike a
traditional waterfall method. To a degree, this is understandable
because they need to maintain some rigour in adhering to Agile
principles. However, there is a risk in Agile projects that the importance
of structured requirements analysis is overlooked and undervalued. In
this situation, the Scrum team runs the risk of using agility as an excuse
to become sloppy in their efforts.
Value Realisation
In the straata® method we speak of value
realisation . By this we mean putting in
place measures to ensure the organisation
receives tangible value from the project
work we are doing. These are the
requirements to ensure that the delivered
product is actually adopted by the business, training is identified and in
place, resistance to adoption has been identified, mitigations have been
defined and ways and means to measure actual business value
realisation are identified. Whether a project is implemented using a
traditional Waterfall delivery methods or a collaborative Agile
approach, this concept is still relevant. We all undoubtedly want to
make sure the value of what we are doing is realised by the organisation
as a whole. Once again, this is an area where the Business Analyst can
assist. Whether Waterfall or Agile, specific requirements for value
realisation must be considered and included in the project scope, and
as the BA it is our role in Scrum to ensure they are captured in the
product backlog.
The straata® method provides an approach that can be f lexed for use in an Agi le environment in order to rightsize the analysis effort, thereby ensuring a degree of rigour is maintained without overcooking it. Click here to access documents that cover the straata® approach for requirements analysis.
www.visionate.co.nz P a g e | 1 0
In terms of assessing whether or not the project has realised the
intended value, this is something that will generally occur outside of the
sprint, potentially using tools delivered during the sprint. For example,
a report identified as a requirement for Value Realisation measurement
and generated during the sprint could show that the functionality added
to the ABC website has increased customer sign-ups by 20%.
Solution Specification
During the solution specification activity
the Business Analyst lays out the
functional and non-functional
specification for the solution. The degree
to which this analysis activity is necessary
during an Agile-Scrum project will depend
upon complexity and level of business
engagement in the project. In some
situations, functional specification will
occur on-the-fly as part of the sprint. And
in other situations, the developers have sufficient analytical abilities
themselves to design the solution. In both cases, the role of the BA may
be reduced in this activity. However, in some projects there may be a
need for additional rigour and focus in this area. Developers may feel
the need for a more detailed specification of the functio nal design for a
requirement, or testers may need it in order to comprehensively design
a testing regime. Functional specification of requirements, or detailed
exposition of acceptance criteria for testing is of course a core skill set
of the BA function.
© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 1 1
Technical Activities
The technical arena is one in which the Business
Analyst does not often venture, with the exception
being those Business Analysts that have come from a
technical background. Activities in this area involve
ensuring the right technical principles, protocols and
procedures are in place, application architecture is
defined, and technical architecture patterns and
standards are identified. How this gets done will
depend on how Agile-Scrum is being used by the
organisation and the shape of the internal IT function.
Some organisations will mix these activities into the sprint, on-the-fly,
whilst other organisations will take a more formal approach . The formal
approach may involve a separate Scrum team tasked with creation of
the application and technical architecture. Another formal approach is
to include specific architectural requirements as pre-requisites in the
product backlog, or even via separate preliminary sprints to set-up the
required technical environment. BAs with a strong technical bent may
dabble in this area, but traditionally most BAs shy away from this and
leave it to the technical experts. And it’s safe to say that most BAs will
steer will clear of actual hands on development and coding. This
generally is not a role that the BA can easily flex to fi ll. The exception
once again, being those BAs that have come from a strong technical
background.
www.visionate.co.nz P a g e | 1 2
Configurable Systems
In the situation where a configurable off-
the-shelf package is being implemented, a
different dynamic applies. Typically,
configuration of an off-the-shelf system
involves the identification of business
rules (i.e. detailed requirements) which
are then applied to the package through
in-built configuration.
The package solution may require specialist configuration resources to
be involved (e.g. SAP FICO specialists), or it may be amenable to
configuration by an individual knowledgeable in the business process.
In either case, as BAs we are well suited to be involved in determining
how the business requirements can be fitted to the capabilities of the
configurable package. And in some cases, we could even be involved in
carrying out the configuration itself.
Testing
The validation activities that are
traditionally handled by a formal testing
function are, with Agile-Scrum, the
responsibil ity of the Scrum team. These
activities are carried out within the sprint.
The Scrum team may or may not have
formally assigned testers.
There are a number of different aspects of testing to consider , and
Business Analysts are able to assist in many of these areas. Technical
testing such as integration and unit testing are not something that most
BAs would attempt, however a BA with a technical background may feel
comfortable lending a hand in this area. Functional testing of the
solution is an area that most BAs could flex to perform, depending of
course on the nature of the project and complexity of the system.
© V i s i o n a t e L t d 2 0 1 4 / 1 5 a l l r i g h t s r e s e r v e d P a g e | 1 3
User Acceptance Testing (UAT) is an activity that traditionally the
Business Analyst will assist in coordinating. Depending on the level of
business engagement with the project, the BA may simply assist with
scripting and coordinating the testing, right through to actually
participating in the execution of UAT. If the business is heavily engaged
in the project, then the UAT may occur during the sprint, otherwise
some form of UAT will need to be conducted outside of the sprint.
Conclusion
In summary there are a number of roles within the Scrum team that are
ideally fil led by Business Analysts. There are also roles which we can
flex to, in support of the multi -skilled approach promoted by Agile
thinking. Irrespective of the project methodology in use, we should all
have the same ultimate goal: to deliver a quality result to the business
that provides measurable value. As Business Analysts, this is our core
focus.
To enable our own flexibil ity and be capable of filling the different roles
described in this document, we as BAs must cultivate a mind-set of
willingness and cooperation. In doing so, we must shed any attitude
and rigidity around what a “Business Analyst” does and does not do. At
the end of the day, on an Agile project, the BA needs to be the sponge
that expands and fill any perceived gaps within the team. Much of the
success of the Agile approach lies in the empowerment of a self -
organising team. The BA, and all members of the Scrum team for that
matter, need to adopt an attitude of serving the team in any way
possible to support the successful execution of any given sprint.
www.visionate.co.nz P a g e | 1 4
The nature and degree of our involvement as BAs will vary, depending
upon the particular organisation. But it is clear that regardless of how
Agile-Scrum has been adopted in practice, there remains a primary
requirement for Business Analysis expertise within the Scrum team.
Thank you for reading our document on the Agile BA. For more
information on the straata® method, please visit our website
www.visionate.co.nz