A concise overview of Agile in Project Management.

1. Presentation Written by:
Chris Mitchell
BEING AGILE IN PROJECT
MANAGEMENT

2. CONTENTS
Contents Slide
What is Agile Project Management 4
A Brief History of Agile 6
The Agile Manifesto 9
Agile software development diagram Over view 11
A Creative Approach To Project Management (Ron
Montgomery)
12
A high level over view of an Agile Scrum project 15
Agile SCRUM Project Processes (Release planning, sprints,
user stories, estimation, burn down chart)
16
Agile Scrum Project lifecycle diagram 33
The Success of the FBI Sentinel Project 34
References 35
Resources and Links 36
2

3. 3

4. WHAT IS AGILE IN PROJECT
MANAGEMENT?
Agile is an adaptive, flexible, iterative and customer orientated approach
to project management. It promotes customer, user and developer close
cooperation in delivering project objectives. It prioritises adapting to
change rather then extensive rigid planning.
4
There are different styles of Agile that have
been applied to Project Management.
Scrum and Kanban are two of the most
well known and widely used.

5. 5
Wikipedia - “Agile management or Agile Project
Management is an iterative method of determining
requirements for engineering and information
technology development projects in a highly flexible
and interactive manner. It requires empowered
individuals from the relevant business, with supplier
and customer input.”

6. A BRIEF HISTORY OF AGILE
Agile management origins were in part first
developed by William Edwards Deming in his work
helping to rebuild Japan after the second world war
using an continuous improvement approach.
And also from software development, where
iterative software development processes have
been noted to have first started in the 1950s(1).
A flexible and adaptive software development
process was developed by the New York Telephone
Companies Systems Development Centre, under the
direction of Dan Gielan. (2).
6

7. 7
What has become termed lightweight Agile software
development methods evolved in the mid-1990s as a
reaction against heavyweight waterfall methods.
These waterfall methods are characterized by critics
as a heavily regimented, overly documented
waterfall model approach to software
development.[4]
A BRIEF HISTORY OF AGILE
Tom Gilb in the 1970s published concepts of
Evolutionary Project Management (EVO). This
developed into Competitive Engineering.(3) This is
an Agile approach to project management.

8. A BRIEF HISTORY OF AGILE
• Early implementations of Agile methods include Rational Unified Process
(1994), Scrum (1995), Crystal Clear, Extreme Programming (1996),
Adaptive Software Development, Feature Driven Development, and
Dynamic Systems Development Method (DSDM) (1995).
• These are now typically referred to as agile methodologies, after the Agile
Manifesto published in 2001.[5]
8

9. THE AGILE MANIFESTO
The need for an alternative to documentation driven,
heavyweight software development processes that are
familiar in waterfall and traditional management processes.
Gave birth to what has become known as Agile software
development and also Agile Project management.
This reached a central moment in 2001 with the creation of
the Agile Manifesto. It was founded by a group of software
developers who met in Utah to discuss light weight
software development processes.
9

10. THE AGILE MANIFESTO
The Four Key Principles:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
10
http://agilemanifesto.org/

11. AGILE SOFTWARE DEVELOPMENT DIAGRAM OVER VIEW
Although Agile Project Management
came out of software development
processes and is typically used in this
field. Its application can be applied to
many types of project.
It can be used in various product
development, design, government
and many other projects and areas.
11

12. Ron Montgomery
A Creative Approach To Project Management
(The following text in light yellow was written by Ron Montgomery. Please see slide resources and links for further info)
Agile Methodology was born as a lightweight framework
for managing software development. It emphasizes
business-driven prioritization, responding to change, self-
organizing teams, face-to-face communications and quick
delivery cycles.
It de-emphasizes sequential processes and detailed project
artefacts such as specification documents. Since it’s
inception, the benefits of the concept have been spread to
other areas of business. Today you will often hear the word
agile in association with:
• Extreme Programming (XP) – System engineering practices.
• Scrum – Project management practices.
• Lean – Management practices adapted from lean manufacturing.
Ron Montgomery 12

13. The agile movement had been in progress for many years and reached a pivotal point in
February 2001 when a group of software development experts met in Utah to ski,
socialize, and discuss how to improve software development. The result was the “agile
manifesto and principles", which are listed below and also posted at
www.Agilemanifesto.Org.
Agile Values:
“We are uncovering better ways of developing software by doing it and helping others do it. Through this work
we have come to value:
Individuals and interactions over processes and tools.
Working software over comprehensive documentation.
Customer collaboration over contract negotiation.
Responding to change over following a plan.
That is, while there is value in the items on the right, we value the items on the left more.
Ron Montgomery
13

14. Waterfall Agile
“Plan the work and work the plan” Plan, work and repeat
Plan for activities & tasks Plan for functionality
Learn and document everything at the outset of
the project
Respond to new information during the project
Resist changes to scope Welcome changes in scope
All scope items must be delivered Functionality will be re-prioritized frequently by
the business, and some functionality may never
be developed
Projects are organized like relay races, with
scheduled handoffs between groups
Projects are similar to scrums in rugby, as all team
members work to move the ball down the field
QA is performed at the end of the project or
product that is delivered
QA is performed continuously
Agile is a significant departure from the classical “waterfall” management approach as
summarized below:
Ron Montgomery 14

15. A HIGH LEVEL OVER VIEW OF AN AGILE SCRUM
PROJECT
• The following is a high level overview of how a project may be run using
Agile Scrum framework. Scrum is the most commonly used form of
Agile project management.
• It is important to bear in mind
that there are no best practices
with Agile. What is most
important is adapting an
approach that best serves the
customer and the team.
15

16. AGILE SCRUM PROJECT PROCESSES
The following points explained further in the next slides are elements that go towards
making an Agile Scrum project:
• Vision (or Business Case).
• Product backlog.
• User stories – features and tasks.
• Planning poker, story points and estimation.
• Sprint planning.
• Release planning / Backlogs / Sprints.
• Burn down chart.
• Scrum / Stand up meeting.
• Retrospective.
16

17. AGILE SCRUM PROJECT PROCESSES
17
The details given below are high level and are not a detailed
description of an Agile Scrum project. For further understanding
and more in depth explanation please either refer to the web,
training, reading and Agile people.
The term sprint is specifically used in Scrum. Sprint and iteration
mean the same thing in Agile. A sprint is basically a set piece of
work consisting of several user stories that is completed in a set
time. The sprint is then often repeated.

18. VISION OR BUSINESS CASE
• The Vision or business case: If starting a project from scratch. It
will usually be the case that it requires justification. A business
case will be created to justify the project/product and its
benefits.
• If Agile is adapted to a project
already in motion, then a new
business case would unlikely to
be required, unless requested.
18

19. VISION OR BUSINESS CASE
• It has been noted that detailed business cases may not be
beneficial to a project. They can be overly documented with
various estimations and details that are side lined, not correct
or can quickly change. And most of all don’t even get read.
• Although business cases (apart from detailed financial
information) could be created on just one page.
• An Agile project vision should inspire people.
19

20. AGILE PLANNING
BOARD
• User stories and tasks are written on cards
or sticky notes and stuck onto a board. Or
logged in a online Agile software tool such
as ‘Jira.’
• At the start of a project or piece of work,
all the things that are wanted (User
Stories) are listed down and put in a
product backlog. This is like a wish list of
everything the product should have.
PRODUCT BACKLOG
20

21. PRODUCT BACKLOG
• The product back log can also be seen or used as the road map for the
product or project. A roadmap is simply an overview of where ideally the
project or projects will lead.
21

22. USER STORIES – FEATURES AND TASKS
• User Stories: Agile is a customer orientated approach to project
management. So a piece of work that needs to be done is often defined as
a user story. This is thinking from the customers perspective.
• For example in website
development, a user story maybe
– “I want to be able to leave
feedback in a comments section
for each article written.” This is a
defined user story and is work to
be implemented.
• User stories can be written down
and collected on sticky notes or
cards.
22

23. USER STORIES – FEATURES AND TASKS
• Features: Sometimes user stories and features are given the same
definition and used in the same way. Although a feature can be regarded
as something different. A feature is a basically an over arching part of a
product or service. Or looking at it in another way, it could be described
as a detailed experience of how the customer will use all or part of a
product or service.
• Tasks are set things to do with a User Story. E.g. Create a logo.
23

24. PLANNING POKER, STORY POINTS AND ESTIMATION
• This is a way of estimating how difficult or
how long it may take to complete a task / user
story
• In a team planning session a level of difficulty
is set - E.g. 1,2,3,5,8 Etc… 1 being easy and
higher figures being difficult. Each team
member is asked to estimate how difficult a
user story or task(s) may be, by applying a
number. This is put on a card or a pre made
card is selected.
• Card selection is initially done in secret so
there is no persuasion or influence from other
team members.
Planning Poker:
24

25. • Each team member then shows the number they picked. Then with all
the numbers shown a figure is agree upon for the task – (this will be the
user story or task story points).
• These figures can represent hours. However many people do not like
applying time to these figures as time estimates are nearly always out
and instead the figures can represent difficulty levels.
PLANNING POKER AND STORY POINTS
25

26. PLANNING POKER AND STORY POINTS
26
• Planning poker is done after tasks and user stories have been created. It
creates the estimate for how long or how difficult a task or user story may
be.
• The collection of these estimates for a given sprint will allow for an estimate
of how long the sprint may take.
• This information can be put into a burn down chart that shows how much
work needs to be done and how long its taking or may take.

27. 27
SPRINT PLANNING
• A selection of what user stories can most
realistically can be done in the first sprint; is taken
from the product backlog and put into the sprint
backlog.
• Sprints can be 1 week, 2 weeks or 4 weeks in
length. But they are never more than a month or 30
days in length.

28. Product Backlog > A prioritized list of work for the entire product. E.g., user story 1, user story
2, etc… (This may not appear on the board as it will be the initial wish list of the product that is
being made / developed).
Release Backlog > A subset of the product backlog that you are targeting for completion for the
next or first release. E.g. user story 1, user story 2. (Technically in scrum you can release at any
time and you don’t need a backlog to do this).
Sprint Backlog > A subset of Release backlog through a set of detailed tasks/user stories. E.g.,
(user story / task 1, t 2, t 3)
Please note some teams use a release backlog, although this is not recommended by some
people working in Agile. Please see link and blog below for more on this
http://www.mountaingoatsoftware.com/blog/why-there-should-not-be-a-release-backlog
The slide below is a high level over view of the Agile work flow process.
RELEASE PLANNING / BACKLOGS / SPRINTS
28

29. Working
Product
Product Backlog
Sprint backlog (may be
repeated continuously)
Working
Product
Product Backlog
Release backlog
29
Sprint backlog (may be
repeated continuously)
RELEASE PLANNING / BACKLOGS / SPRINTS

30. BURN DOWN CHART
• If you have 10 user stories in a sprint backlog and each has been given roughly the same time
to complete. For example each user story will be about 10 working hours. Then after 50 hours
roughly half of the sprint work would have hopefully been done.
• As mentioned some teams may
not use hours for estimates.
Instead use, user stories or tasks
for the burn down chart.
• If a certain amount of user stories
or tasks is being done a day, this
can also give a great estimate on
how many more days it will take
to complete the sprint! E.g. 3
tasks are being done a day. This
means 10 more tasks, will take
about 3 days.
30
• There are various ways of estimation in Agile. An ideal approach may not be to estimate in
hours.

31. SCRUM / STAND UP MEETING
31
• As part managing the project - 15 minute stand up or scrum
meetings are held each day.
• Each team member will say what they are working on and what
they will be doing today. Also they can raise any issues or concerns.
• On a Scrum project, there are three main roles: Product owner,
Scrum Master, and team. The Scrum Master should act as the team's
coach. Helping team members work together in the most effective
manner possible.

32. RETROSPECT
POSSIBLY CONTINUOUS DEVELOPMENT
• A retrospective is usually done at the end of a sprint. It very
simply looks at what went well and what didn’t. What could
be improved for the next sprint.
• They are different ways of doing retrospectives. Some of
which may just be a brain storming session with the whole
team.
32

33. SCRUM PROJECT LIFECYCLE DIAGRAM
33

34. Case Study: Agile Project Management for Government: The Success of the FBI
Sentinel Project:
Please see below for a very interesting and brilliantly written case study in Agile being
used at the FBI. This Case study was written by Brian Wernham.
Please double click icon to open.
34

35. REFERENCES
1. Gerald M. Weinberg, as quoted in Larman, Craig; Basili, Victor R. (June 2003). "Iterative and
Incremental Development: A Brief History". Computer 36 (6): 47–56.
doi:10.1109/MC.2003.1204375. ISSN 0018-9162
2. http://en.wikipedia.org/wiki/Agile_software_development
3. http://www.gilb.com/Project-Management Evolutionary Project Management (EVO)
4. http://en.wikipedia.org/wiki/Agile_software_development
5. ^ Larman, Craig (2004). Agile and Iterative Development: A Manager's Guide. Addison-Wesley.
p. 27. ISBN 978-0-13-111155-4
35

36. RESOURCES AND LINKS
Scrum the story of an Agile Team (right click to go to website)
www.mountaingoatsoftware.com
http://www.youtube.com/user/axosoft?feature=watch
http://itsadeliverything.com
http://chrisjmprojmanagement.wordpress.com
http://agilemanifesto.org/
http://www.agilealliance.org
36
http://www.managingamericans.com/blogFeed/author/RonMontgomery.htm
http://www.scrumguides.org/