A discussion recently given for VUW's 1st year Business Analysis class in InfoSys on behalf of the IIBA. Topics covered are: what it's like working on an agile project, being a recent graduate on a software project, fundamentals of agile and how they apply (or not!) on our project, and some of the daily tasks of a cross-functional consultant on the DM project.
4. INTRODUCTIONS: DIGITAL MODERATION
▫ Based at NZQA
▫ The first project in a long-term programme called
Future State which is focused on digitising
assessment.
▫ Our project focuses on the moderation process:
remember in high school how some of your
papers would be sent away during the year?
▫ Core team of about 10, wider team of approx 20
that chip in here and there.
▫ Project will span about 2 years total, 1 year of core
work with a full team.
▫ We’re based in a very colourful cube of an office
with as much of the core team together as
possible.
7. SCRUM MASTER
Agile coach:
◦ Scrum Master for the
Digital Moderation
project team at NZQA
◦ Worked as an agile
coach & team member
for Agile teams at:
▫ Fairfax
▫ BNZ
▫ Westpac
▫ Xero
▫ NZQA
8. SCRUM MASTER
What does a scrum master do?:
◦ “Scrum Master”:
▫ … responsible for ensuring Scrum is
understood and enacted
▫ … servant-leader for the Scrum Team.
◦ Reality is more like:
▫ Facilitate
▫ Coach
▫ Demonstrate
9. HOW WE WORK
We structure our fortnightly iterations into:
◦ Planning (one session at the start)
◦ Standups (daily team check-in on progress)
◦ Review / Demo
◦ Retrospective
We also have the following depending on our
specific work:
◦ Workshops (cross-functional focus on a
feature or sub-feature)
◦ Short-term stand-ups / check-ins
10. COMMON FRAMEWORKS FOR AGILE
Scrum
Popular agile framework
with specific roles, events,
artifacts and rules.
“A framework within which
people can address
complex adaptive
problems, while
productively and creatively
delivering products of the
highest possible value.”
Scrum Guide
Kanban
Inspired by lean
manufacturing processes
Focus is on getting work to
flow through development by
limiting the work-in-progress
More flexible and easier to
start with than Scrum
11. METHODOLOGY: THEORY VS OUR REALITY
Waterfall
◦ Begins with
the BAs
analysing and
defining
requirements
◦ Stakeholders
are consulted
once formally
◦ Deadlines are
absolute
Scrum
◦ Analysis and
requirements
defining is
continuous
throughout
the project
◦ Stakeholders
provide
constant
input
◦ Deadlines are
flexible
Our Project
◦ Had an initial
analysis period,
but is open to
further
development of
requirements
◦ Stakeholders
are re-
consulted at
key points
◦ Project
deadlines are
flexible, but
there are
outside
constraints
12. METHODOLOGY: THEORY VS OUR REALITY
Waterfall
◦ Progress is
linear and
clearly
measurable
◦ Scope is
locked in at
the start of
the project
◦ Documentati
on is a must!
Scrum
◦ Progress is
iterative and
in small
chunks
◦ Scope can be
refactored
◦ Minimize
documentati
on, MVP
Our Project
◦ Chipping away
in chunks
towards a big
goal
◦ Scope is
refactorable up
to a point
◦ Would dearly
like to
document less!
13. ‘PASS THE BATON’ VS THE ‘THREE LEGGED RACE’
◦ In Waterfall projects (and a lot of projects in general) work is
passed down the chain- the BA passes on the requirements, the
developer works from these...
◦ For us, you own the work (sometimes collectively!) the whole
way through each cycle; if there’s a mistake, later on you still
own it and amend it.
◦ Because of the continual team involvement at all points, strength
of the team is very important- this can be a weakness because it
does require continual commitment + getting along
◦ This introduces a certain amount of co-dependency within the
team: success is collective. It doesn’t matter how well we
analysed, designed, tested if the end product doesn’t work.
14. How cross-functionality works in practice
Elastic role boundaries (Katrina Clokie & Chris Priest)
We all have a primary role or specialisation. Some tasks only relate to our role, some
are a regular part of multiple roles.
When a new task appears one role will stretch to cover it and may take it on
regularly
We may stretch between roles to help each other out
… but the elastic always snaps back.
15. SO WHAT DO YOU EVEN DO?
That’s a very good question...
16. Good
◦ Knowing you
can make a
difference
◦ Interacting with
people
◦ Knowing your
project has
purpose
◦ Validating your
analysis
WORKING WITH STAKEHOLDERS
Bad
◦ You can’t
deliver the
world
◦ You have to be
the bad guy
sometimes
◦ Preconceptions
and politics
◦ They change
their minds!
17. SLICE OF LIFE: A LOOK AT LAST WEEK FOR ME
Monday: User Acceptance Testing went live. I worked with the
the test team, sent emails out to external stakeholders, and
coordinated the launch.
Tuesday: A timeline and plan I had been creating went for
sign-off! I ended up editing a lot of documents thanks to
feedback.
Wednesday: I spent the day with internal stakeholders and the
instructional designer capturing updated requirements and
defects and introducing the stakeholders to the new system.
Thursday: After meeting with the stakeholders, I then met with
the developers and the PM to let them know what the
feedback had been. I logged the defects and prioritised them.
Friday: I had a meeting with the developers to discuss the
high-level process map of a new tool we are designing, and
the feasibility of it.
18. WORKING IN AN AGILE TEAM:
GRAD PERSPECTIVE
Flexibility: My work doesn’t have one label! This means being able to
learn a lot of new things and discover what I like.
Support: Breaking down inter-team boundaries means you can get
advice from the most unexpected of places.
Change: Because of the iterative nature of agile, I don’t end up doing
the same thing for a long period of time...good if you tend to get
bored!
Lack of Structure: Because everything is a lot more fluid, it’s
sometimes hard to know what you’re meant to be doing...self
management is a must!
20. TOOLS OF THE TRADE
Microsoft Visio: We love to hate it. I wish I’d been practicing it for
years, so start now!
XMind: Nifty free tool for easy brainstorming. Good for mapping
details and drafting.
Jira: Used to track details of tasks, defects and overall project
progress. A little hard to get experience in before you’re on a project.
Confluence: Jira’s Wiki-based sister. Good for sharing documents and
larger pieces of information between a team.
Pen and Paper: Classic, but still work. Post-its especially are great for
making the walls colourful and getting the information out there.