agile project management 1 17 2007[1]

24
Agile Project Management Presented by Carter Engelhart – PMI-SVC I80 Roundtable Moderator. – January 2007 Meeting Excerpts extracted from the book Managing Agile Projects by Kevin Aguanno, PMP, MAPM ISBN 1-895186-11-0 See www.mmpubs.com Paperback and PDF editions available. Endorsed by PMP’s as well as Staff of The Project Management Institute (or PMI).

Upload: leaptocheap

Post on 14-Jun-2015

418 views

Category:

Documents


4 download

TRANSCRIPT

Page 1: Agile Project Management 1 17 2007[1]

Agile Project Management

Presented by Carter Engelhart – PMI-SVC I80 Roundtable Moderator. – January 2007 Meeting

Excerpts extracted from the book Managing Agile Projects by Kevin Aguanno, PMP, MAPM

ISBN 1-895186-11-0 See www.mmpubs.com Paperback and PDF editions available. Endorsed by PMP’s as well as Staff of The

Project Management Institute (or PMI).

Page 2: Agile Project Management 1 17 2007[1]

What is Agile?Agile is used to denote the ability of Agile Methods to respond to changing requirement in a controlled but flexible manner

Agile methodologies can equip experienced Project Managers with new tools to manage projects that are set in environments of constant change.

Page 3: Agile Project Management 1 17 2007[1]

Why do we need new Project Management Methods?

Information Technology (as well as other industries) are continuously being challenged by emerging technologies and requirements.

Traditional Project Management “Best Practices” suggest that we should lock down requirements and setup a change control system up front.

Traditional Project Management practices also tend to refer back to the original requirements (and/or the contract) when enforcing change control.

Page 4: Agile Project Management 1 17 2007[1]

Traditional Project Management Practices can Lead to….

Chaos – Junior Project Managers tend to either: allow too much uncontrolled changed to

take place (to ensure customer satisfaction)

or are too strict in allowing for change (resulting in irate customers).

Page 5: Agile Project Management 1 17 2007[1]

Traditional Project Management Practices can Lead to….

Dramatic Project Underperformance – According to the Standish Group’s Chaos Reports, only 16 percent of IT projects are successful, the remainder are: Late. Over Budget. Deliver only a fraction of original scope in order to

meet budget restrictions. Cancelled.

Page 6: Agile Project Management 1 17 2007[1]

What Is Different About Agile Methods?They are all about managing the

impact of change on a project.They allow change to be introduced into

a project in a orderly way that that attempts to maximize the benefits for the sponsor.

They control the risks that the change introduces.

Page 7: Agile Project Management 1 17 2007[1]

What is different about Agile Methods? Iterative and Incremental development that

break down development into a number of repeating cycles called Iterations

Short iterations are used to keep the feedback flowing (allowing for increased responsiveness to change and reducing the risk of building the wrong thing).

Open, Flexible and Extensive design using open standards whenever possible

Page 8: Agile Project Management 1 17 2007[1]

What is different about Agile Methods? Empowered Teams – Experienced

specialists are encouraged to work out the detail design on their own.

Personal Communication – Rather than relying on written documentation to communicate design decisions, technical approaches and other typically documented items, agile method suggest that the team work in the same physical space (co-location). Use of white boards in the work area is encouraged rather than lengthy formal detail design documentation.

Page 9: Agile Project Management 1 17 2007[1]

The Benefits of Being Agile Reducing Risk – The benefits from improved

control and improved communication lead to reduced risks. Examples of risks include: Risk of building (or doing) the wrong thing. Did

the sponsor get what they asked for but not what they actually wanted?

Risk of building the right thing poorly. For example, was the product poorly crafted. Was it thoroughly tested as a part of each iteration? Is the final produce extensible?

Risk of being placed into an endless cycle of design updates and reviews due to changing requirements or high levels of complexity

Page 10: Agile Project Management 1 17 2007[1]

The Benefits of Being AgileRelief from continual design

revisions -- Agile Methods are of the most benefit when applied to projects where the requirements are either unclear or evolving

Page 11: Agile Project Management 1 17 2007[1]

The Benefits of Being Agile Improved Control – Agile methods

allow the Project Manager to their control over the project in high change environment. Utilizing less rigid, yet structured agile methodologies, control is through a number of mechanisms.

Page 12: Agile Project Management 1 17 2007[1]

The Benefits of Being Agile (Improved Control) Frequent delivery of working code allows

progress to be objectively measured. Early and frequent stakeholder feedback

allows the Project Manager to redirect project priorities when needed to ensure that real value is delivered.

Misunderstandings are cleared up early in the project life-cycle.

The sponsor is able to end the project earlier than scheduled and still receive value.

Page 13: Agile Project Management 1 17 2007[1]

The Benefits of Being Agile (Improved Control) Short daily meetings allow team members to

share both successes and problems with each other. Each team member should share: What they have just completed (so that team

members working on dependent tasks are notified).

What are they going to work on next (allows other team members to contribute information that may be helpful to the task).

Issues that are slowing down or halting their progress (so that other team members and/or the Project Manager can provide assistance).

Page 14: Agile Project Management 1 17 2007[1]

Waterfall (traditional) way to plan a software project.Analyze the problemDesign the solution Implement the code (Execution)Test the code Deploy the code.Done

Page 15: Agile Project Management 1 17 2007[1]

Agile method of planning a software development project. Initial Analysis Initial Design (When problems are identified

they are pushed back into the analysis step, to improve it).

Initial coding, push back identified design problems back. Perform another iteration of design to improve it.

Initial Testing. Identified problems are feed back into another iteration of coding.

Integration and deployment. Feedback any problems you encounter into the process.

A system of incremental/continuous improvement.

Page 16: Agile Project Management 1 17 2007[1]

Agile methods are all about incremental progress Working incrementally allows the most critical

portions of the product to be delivered earlier. Working incrementally can help reduce risk

by receiving stakeholder feedback in increments rather than at the end.

Working incrementally allows project teams to continuously make small corrections along the way. Each incremental corrections contributes to the overall quality of the entire project.

Page 17: Agile Project Management 1 17 2007[1]

Agile – Sweat SpotsDedicated developersExperienced developersSmall collocated teamsAutomated Regression testingEasy to access users.

Page 18: Agile Project Management 1 17 2007[1]

Waterfall vs. AgileMoney for information (waterfall)Money for flexibility (agile)

Page 19: Agile Project Management 1 17 2007[1]

Agile DocumentationA document is any artifact external to

source code whose purpose is to convey information in a persistent manner.

Page 20: Agile Project Management 1 17 2007[1]

Reasons to Create Documentation Project stakeholders require it (a Business

decision with costs and benefits associated with it)

To define a contract model (to define how your system and an external one interact with each other). Typically required when an external resource controls an IT resource your system requires (e.g. DB, Application or IT service)

Page 21: Agile Project Management 1 17 2007[1]

Reasons to Create Documentation To support communication with an

external group (e.g. a non-co-located group).

If it will assist you in thinking something through.

Page 22: Agile Project Management 1 17 2007[1]

When is Documentation Agile Generally – when it is “Good Enough”, but no

more. This of course is subjective. When it maximizes stakeholder investment. When the documentation contains “just

enough” information to fulfill its purpose (and no more).

Is purpose driven. If you are not clear about the purpose you are creating the document, you should not be doing so.

When it contains information that is “Less Likely” to change.

Page 23: Agile Project Management 1 17 2007[1]

When is Documentation AgileWhen the documentation contains

critical information not readily available.When the documents have a specific

customer and facilitate the work efforts of that customer.

When the documents are sufficiently indexed, accurate, consistent and detailed.

Page 24: Agile Project Management 1 17 2007[1]

Relating PMBOK Practices to Agile Practices

Relating PMBOK Practices to Agile Practices – Michele Sliger Part I Part II Part III Part IV