The document provides an overview of a business analyst's transition from waterfall to agile methodologies. It discusses some of the analyst's initial questions and misunderstandings about agile. Experts informed the analyst that their current practices were not truly agile. The document then covers the agile manifesto, principles, and Scrum framework. It compares the waterfall and Scrum approaches from an analyst lens and highlights benefits of agile like active stakeholder participation, improved collaboration, and ability to adapt to changes. Some challenges of Scrum are also outlined. The document concludes with pointers on when waterfall versus agile is more suitable.

1. Transition of a BA from waterfall to
agile ways of working.
By Dinesh Boomi

2. Early stages of my agile journey
Crack on
with an agile
project
Dinesh
Boomi
Should I
request for a
formal
training?
Why agile?

3. Joined the project team...
Each one in my project team had a view on agile and only one team member
had prior agile experience…
I had a question. Are we really agile?
Really????
Agile is
another
SDLC
Methodology
!!??
Agile and
Scrum are
the same!!??
Agile is a
mindset !!??
Agile is
where your
requirements
are captured
as small user
stories!!??
And the list
of answers
goes on...
Of course we
are.. I attend
stand up
calls run by a
scrum
master!!!
Of course we
work in
sprints!!!

4. What were we doing actually?

5. What did experts (scrum master and agile project manager) say?
What you do here is not truly agile!!!!

6. Missed something that I wanted right from the beginning..
But managed to get into the 2nd training session!!!!

7. But - what is agile?
The agenda of many software industry leaders was to develop software quickly
and easily i.e. to be more agile. They all came together in 2001 to create a
manifesto and principles to develop software quickly and easily.

8. But - what is agile?
Agile Development Methodology
Scrum
Methodology
Extreme Programming
(XP)
Methodology
Crystal
Methodology
Lean
Methodology
Feature Driven
Development
Methodology

9. Agile Manifesto and Principles
Values promoted by the agile manifesto:
1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan
12 Principles
http://agilemanifesto.org/principles.html
There are several behaviours needed to stick to the manifesto and principles.

10. Scrum - Overview

11. Why agile ? - from an Analyst lens
Waterfall Methodology Scrum Methodology
Chasing
business
stakeholder
s for sign
off
Less
support
from
solution
design
Active
Business
Stakeholder
participatio
n
Solution
designers
are part of
the analysis
Bridging the
gap
between
business
and
technology
All
stakeholder
s are in the
room

12. Why agile ? - from an Analyst lens
Waterfall Methodology Scrum Methodology
Detailed
documentati
on
Documentat
ion far from
perfect -
refined
iteratively
More
collaboration
with end
users
through
innovation
school
Lack of
collaboration
with end
users
Managing
changes to
requirements
Ability to
respond to
changes
quickly

13. Why agile ? - from an Analyst lens
Waterfall Methodology Scrum Methodology
Lack of
involvement
in post live
defect
resolution
Involvement
in post live
defect
resolution
Lack of
involvement
in shape it
Key role in
shape it
Less
visibility on
‘How’ aspect
Key role in
defining
‘how’

14. Why agile ? - from an Analyst lens
Waterfall Methodology Scrum Methodology
Challenges
in estimation
Better
estimation
Difficult to
manage
changes in
MoSCoW
Key role in
backlog
prioritisatio
n
Rely on
business
stakeholders
for decision
making
Get chance
to play as a
proxy
Product
owner

15. Why agile ? - from an Analyst lens
Waterfall Methodology Scrum Methodology
I am the only
analyst
Everyone in
the team are
analysts

16. Challenges with Scrum Methodology
Trouble starts
● when stakeholders don’t have time or interest for regular participation with the scrum team.
● when resources are not dedicated completely to the project.
● when stakeholder’s regular participation tends them to ask for additional features randomly.
● when resources are not co-located.
● when a change has a dependency on a waterfall release.
BAs - be ready to change requirements very often :)

17. When to follow waterfall and when to follow agile?
Waterfall Agile
Requirements are stable and changes are
predictable.
Requirements are more likely to change
significantly and it is not easy to predict.
Easy to estimate accurately. Can’t estimate accurately until low level details
are uncovered.
Stakeholders are more concerned about
estimates and timelines.
Stakeholders are more concerned about quality,
user needs over costs and firm timelines.
Stakeholders cant participate regularly. Commitment from stakeholders with regards to
regular participation.
Dispersed team members. Everyone is in the room or right tools are
available to bring a dispersed team together.
Delivering the product at one go will add more
value.
Delivering the product in incremental way will
add more value.

18. Questions?