Presentation Written by: Chris Mitchell

BEING AGILE IN PROJECT MANAGEMENT

2

CONTENTS

Contents SlideWhat 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 35

The Success of the FBI Sentinel Project 36

References 37

Resources and Links 38

3

Why do we plan so much at the start of a project, when that is

the time we may know least about it.

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.

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

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 come 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).

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]

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.

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.

12

Ron MontgomeryA 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

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

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

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.  Scrum is the most commonly used form of Agile project management.

Product Backlog

Sprint backlog

Working Product• 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.

16

AGILE SCRUM PROJECT PROCESSES

The Following Points explained further in the next slides are key items that go towards making an Agile Scrum project:

• Business Case• Initiation• Road map

• User Stories – Features and tasks.• Release Planning / Sprints

• Release Planning / Backlogs / Sprints• Planning Poker, Story points and estimation.

• Burn down chart• Stand up meeting• Retrospective

17

AGILE SCRUM PROJECT PROCESSES

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 tasks or user stories that is completed in a set time. The sprint is then often repeated.

18

BUSINESS CASE

• 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 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.

19

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. Overly detailed business cases are often just part and parcel of new projects.

20

INITIATION

• On the internet there are various free templates for creating agile initiation documents.

• The initiation document will highlight what will be required to run the project effectively.

• The key is to keep the initiation document lightweight and not overly heavy on detail and text. As great detail will no doubt change the moment the project starts. Using power point for the initiation document is a good idea.

21

INITIATION

• As part of the initiation document the key things included could be project description, project scope, objectives, what benefits will be developed, road map, team member roles, technical requirements, resource requirements, what problem will be solved, what alternatives or comparisons are out there.

22

ROAD MAP• A roadmap is simply an overview of where ideally the project or projects

will lead. Please note that Agile Scrum is primarily a development methodology. Roadmaps are business planning and communication tools. The two are independent of one another, but can be used effectively in conjunction. 

Stage 1 Stage 2 Stage 3

23

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.

24

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. E.g. Create a logo.

25

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 are listed down and put in a product back log. This is like a wish list of everything the product should have.

Release Planning / Sprints

26

RELEASE PLANNING / SPRINTS

• A selection of what is most realistic to be done in the first sprint, is taken from the product backlog and put into the sprint back log.

• It is important to note that different teams may use variations of this approach. There may be a section for user stories and then a section for ‘to do’. There may also be a section for done or in progress. This all depends on the team and how best it is laid out for the team members.

27

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.

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

RELEASE PLANNING / BACKLOGS / SPRINTSTHE WHITE BOXES REPRESENT USER STORIES OR TASKS

Working Product

Product Backlog Sprint backlog (may be repeated continuously)

Working Product

Product Backlog Release backlog Sprint backlog (may be repeated continuously)

29

AGILE 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 number 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 in secret.

• It is initially done in secret so there is no persuasion or influence from other team members.

Planning Poker:

30

• Each team member then shows the number they picked. Then with all the numbers shown. A figure is agree upon – this is 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.

AGILE PLANNING POKER AND STORY POINTS

31

AGILE PLANNING POKER AND STORY POINTS

• Planning poker is done after tasks and user stories have been created. It creates an 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.

32

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 great estimates 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.

• There are various ways of estimation in Agile. An ideal approach may not be to estimate in hours.

33

STAND UP MEETING• As part managing the project - 15 minute stand up meetings can be

done each day. These are done by the scrum master who is similar to a project manger.

• He or she will literally walk around the work area and speak to each team member to see 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.

34

RETROSPECTPOSSIBLY 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.

35

AGILE SCRUM PROJECT LIFECYCLE DIAGRAM

Case Study: Agile Project Management for Government: The Success of the FBI Sentinel Project:

Adobe Acrobat Document

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.

36

37

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

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

38

http://www.managingamericans.com/blogFeed/author/RonMontgomery.htm