Piloting Agile Project Management:
the Google Scholar project
Natalie Collins
May 12, 2009

discussion points
 characteristics of an \"agile\" organization
 managing an agile project
 adapting traditional PM and BA techniques to the method
2

agile principles
Teamwork
Self-organizing
Light
Need-based
processes &
development
documentation
Shared
Knowledge-
decision-
sharing
making
Constant Constant Constant
interaction deployment adaptation
3

agile process
4

goal of our agile project
To reach into the popular and dominant research workflow by
creating a link between Google Scholar and CISTI products and
services.
5

why agile?
6

is your organization . . . ?
 trusting
 confident
 innovative
 team-oriented
 flat
 capable of setting priorities
 decent at portfolio management
 willing to accept risk and failure
 sharing (i.e. knowledge and ideas)
 enthusiastic, available and committed to agile
7

are you right for agile?
If you don’t know whether your organization is agile, it isn’t!
If you are agile, negotiate for dedicated team members.
Impossible??
- Negotiate for a high percentage of time
- Communicate to team why you project MUST come first
- Make sure team knows what is expected from each iteration
8

my organization
• National Science Library
– National Research Council
– Canadian Research and
Development
• Collection and services
– Science, Technology, Medicine
• Discovery and access to scientific
information
Photo by Richard Akerman
9

10

11

12

goal of our agile project
To reach into the popular and dominant research workflow by
creating a link between Google Scholar and CISTI products and
services.
13

preparing metadata for
the web
MODS
convert
xml
(metadata)
extract
metadata NLM
big DB xml search
authorize locate
located and
authorized
insert NLM
NLM
NLM
location xml
xml
xml
14

linking from Google
Scholar to CISTI Discover

project details
• There were six, three week iterations . . .
• . . . then there was an iteration 7 aka etc. etc.
16

why this project was
chosen
• small components
• opportunity to output testable pieces of code each iteration
• clear project scope
• clearly defined business rules
• small effort
• familiarity and success with agile software development
17

the method:
prelude
 determine iteration length A USER STORY IS
 gather user stories
- testable
 build your backlog - prioritized
 - modifiable
prioritize stories
 estimate the effort to implement each
story
2
I must be able to return
to my Google Scholar
search results.
1
4
18

building an understanding
of your project
before you begin, try an iteration 0
• assign reading
• determine architecture
• identify key build or buy components
• identify existing components
• learn about existing components
• storyboard your deliverables or storyboard a like organization’s process
• hold a retrospective
– review and possibly reassign the degree of difficulty previously indicated on
user stories
– identify training needs
19

iteration 1 to n
Iteration planning should include the sponsor and the entire
project team.
• for each story, scope out high-level goals, sub-goals and tasks
• identify dependencies between user stories, goals and tasks
• recommend user stories for iteration
– highest priority + related tasks
– highest risk
– least likely to change
• get approval / changes from sponsor
• get to work
20

the method:
an iteration cycle
gather
plan
Backlog requirements
reflect build
demonstrate test
21

strengths of the method
+ an organic process
+ great for software development
+ focusing effort on small work packages
+ don’t need to know the outcome to begin
+ ready to develop sooner
+ more sponsor involvement
+ improves communications
+ excellent way to handle scope issues
+ engaged and motivated team
22

challenges with the
method
- adapting requirements gathering and design processes
- user story granularity
- working with external organizations
- iterating “project control” tasks
- demonstrating success to the sponsor
23

challenges for the BA &
PM
- accepting imperfection and uncertainty
- determining the level of detail needed for each iteration
- calming the cowboys (i.e. making sure developers aren’t making up
the business rules)
- being on-call throughout the iteration
- deciding how much information is enough to get started
- estimating how much work to put into an iteration
- earning the trust your sponsor and clients
- planning continuously
- tolerating and accepting that some work will be tossed
24

let’s talk about
communication
• hold brief meetings frequently
• launch your project with the whole team
• hold weekly meeting (schedule them at the outset of the project)
• schedule iteration planning meetings with the sponsor
• ask technical team to hold daily meetings
• hold a retrospective at the end of each iteration
• hold ad hoc meetings as needed
• meet with the sponsor after every ad hoc meeting to explain the issue
and, if necessary, to receive approval for changes (i.e. to
scope, resources, time, quality)
• make sure the team knows good communication is a global responsibility
25

adapting to agile
From © Scaredy Squirrel by Mélanie Watt, Kids Can Press, 2006
26

learning points
• characteristics of an \"agile\" organization
• managing an agile project.
• adapting traditional PM and BA techniques to the method
27

Thanks!
this presentation is now available on slideshare
This material is based on a presentation given
at ProjectWorld / BusinessAnalyst World (Toronto
2009) organized by:
Diversified Business Communications Canada
42 Bentley Street, Unit 1
Markham, ON, L3R 9T2
905-948-0470 or 888-443-6786
http://www.divbusiness.com

29