Agile Project Management 1 17 2007[1]


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile Project Management 1 17 2007[1]

  1. 1. Agile Project Management Presented by Carter Engelhart – PMI-SVC I80 Roundtable Moderator. – January 2007 Meeting <ul><li>Excerpts extracted from the book Managing Agile Projects by Kevin Aguanno, PMP, MAPM </li></ul><ul><li>ISBN 1-895186-11-0 </li></ul><ul><li>See </li></ul><ul><li>Paperback and PDF editions available. </li></ul><ul><li>Endorsed by PMP’s as well as Staff of The Project Management Institute (or PMI). </li></ul>
  2. 2. What is Agile? <ul><li>Agile is used to denote the ability of Agile Methods to respond to changing requirement in a controlled but flexible manner </li></ul><ul><li>Agile methodologies can equip experienced Project Managers with new tools to manage projects that are set in environments of constant change . </li></ul>
  3. 3. Why do we need new Project Management Methods? <ul><li>Information Technology (as well as other industries) are continuously being challenged by emerging technologies and requirements. </li></ul><ul><li>Traditional Project Management “Best Practices” suggest that we should lock down requirements and setup a change control system up front. </li></ul><ul><li>Traditional Project Management practices also tend to refer back to the original requirements (and/or the contract) when enforcing change control. </li></ul>
  4. 4. Traditional Project Management Practices can Lead to…. <ul><li>Chaos – Junior Project Managers tend to either: </li></ul><ul><ul><li>allow too much uncontrolled changed to take place (to ensure customer satisfaction) </li></ul></ul><ul><ul><li>or are too strict in allowing for change (resulting in irate customers). </li></ul></ul>
  5. 5. Traditional Project Management Practices can Lead to…. <ul><li>Dramatic Project Underperformance – According to the Standish Group’s Chaos Reports , only 16 percent of IT projects are successful, the remainder are: </li></ul><ul><ul><li>Late. </li></ul></ul><ul><ul><li>Over Budget. </li></ul></ul><ul><ul><li>Deliver only a fraction of original scope in order to meet budget restrictions. </li></ul></ul><ul><ul><li>Cancelled. </li></ul></ul>
  6. 6. What Is Different About Agile Methods? <ul><li>They are all about managing the impact of change on a project . </li></ul><ul><li>They allow change to be introduced into a project in a orderly way that that attempts to maximize the benefits for the sponsor. </li></ul><ul><li>They control the risks that the change introduces . </li></ul>
  7. 7. What is different about Agile Methods? <ul><li>Iterative and Incremental development that break down development into a number of repeating cycles called Iterations </li></ul><ul><li>Short iterations are used to keep the feedback flowing (allowing for increased responsiveness to change and reducing the risk of building the wrong thing). </li></ul><ul><li>Open, Flexible and Extensive design using open standards whenever possible </li></ul>
  8. 8. What is different about Agile Methods? <ul><li>Empowered Teams – Experienced specialists are encouraged to work out the detail design on their own. </li></ul><ul><li>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. </li></ul>
  9. 9. The Benefits of Being Agile <ul><li>Reducing Risk – The benefits from improved control and improved communication lead to reduced risks. Examples of risks include: </li></ul><ul><ul><li>Risk of building (or doing) the wrong thing. Did the sponsor get what they asked for but not what they actually wanted? </li></ul></ul><ul><ul><li>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? </li></ul></ul><ul><ul><li>Risk of being placed into an endless cycle of design updates and reviews due to changing requirements or high levels of complexity </li></ul></ul>
  10. 10. The Benefits of Being Agile <ul><li>Relief from continual design revisions -- Agile Methods are of the most benefit when applied to projects where the requirements are either unclear or evolving </li></ul>
  11. 11. The Benefits of Being Agile <ul><li>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. </li></ul>
  12. 12. The Benefits of Being Agile (Improved Control) <ul><li>Frequent delivery of working code allows progress to be objectively measured. </li></ul><ul><li>Early and frequent stakeholder feedback allows the Project Manager to redirect project priorities when needed to ensure that real value is delivered. </li></ul><ul><li>Misunderstandings are cleared up early in the project life-cycle. </li></ul><ul><li>The sponsor is able to end the project earlier than scheduled and still receive value. </li></ul>
  13. 13. The Benefits of Being Agile (Improved Control) <ul><li>Short daily meetings allow team members to share both successes and problems with each other. Each team member should share: </li></ul><ul><ul><li>What they have just completed (so that team members working on dependent tasks are notified). </li></ul></ul><ul><ul><li>What are they going to work on next (allows other team members to contribute information that may be helpful to the task). </li></ul></ul><ul><ul><li>Issues that are slowing down or halting their progress (so that other team members and/or the Project Manager can provide assistance). </li></ul></ul>
  14. 14. Waterfall (traditional) way to plan a software project. <ul><li>Analyze the problem </li></ul><ul><li>Design the solution </li></ul><ul><li>Implement the code (Execution) </li></ul><ul><li>Test the code </li></ul><ul><li>Deploy the code. </li></ul><ul><li>Done </li></ul>
  15. 15. Agile method of planning a software development project. <ul><li>Initial Analysis </li></ul><ul><li>Initial Design (When problems are identified they are pushed back into the analysis step, to improve it). </li></ul><ul><li>Initial coding, push back identified design problems back. Perform another iteration of design to improve it . </li></ul><ul><li>Initial Testing. Identified problems are feed back into another iteration of coding. </li></ul><ul><li>Integration and deployment. Feedback any problems you encounter into the process. </li></ul><ul><li>A system of incremental/continuous improvement. </li></ul>
  16. 16. Agile methods are all about incremental progress <ul><li>Working incrementally allows the most critical portions of the product to be delivered earlier. </li></ul><ul><li>Working incrementally can help reduce risk by receiving stakeholder feedback in increments rather than at the end. </li></ul><ul><li>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. </li></ul>
  17. 17. Agile – Sweat Spots <ul><li>Dedicated developers </li></ul><ul><li>Experienced developers </li></ul><ul><li>Small collocated teams </li></ul><ul><li>Automated Regression testing </li></ul><ul><li>Easy to access users. </li></ul>
  18. 18. Waterfall vs. Agile <ul><li>Money for information (waterfall) </li></ul><ul><li>Money for flexibility (agile) </li></ul>
  19. 19. Agile Documentation <ul><li>A document is any artifact external to source code whose purpose is to convey information in a persistent manner. </li></ul>
  20. 20. Reasons to Create Documentation <ul><li>Project stakeholders require it (a Business decision with costs and benefits associated with it) </li></ul><ul><li>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) </li></ul>
  21. 21. Reasons to Create Documentation <ul><li>To support communication with an external group (e.g. a non-co-located group). </li></ul><ul><li>If it will assist you in thinking something through . </li></ul>
  22. 22. When is Documentation Agile <ul><li>Generally – when it is “Good Enough”, but no more. This of course is subjective. </li></ul><ul><li>When it maximizes stakeholder investment. </li></ul><ul><li>When the documentation contains “just enough” information to fulfill its purpose (and no more). </li></ul><ul><li>Is purpose driven. If you are not clear about the purpose you are creating the document, you should not be doing so. </li></ul><ul><li>When it contains information that is “Less Likely” to change. </li></ul>
  23. 23. When is Documentation Agile <ul><li>When the documentation contains critical information not readily available. </li></ul><ul><li>When the documents have a specific customer and facilitate the work efforts of that customer. </li></ul><ul><li>When the documents are sufficiently indexed, accurate, consistent and detailed. </li></ul>
  24. 24. Relating PMBOK Practices to Agile Practices <ul><li>Relating PMBOK Practices to Agile Practices – Michele Sliger </li></ul><ul><ul><li>Part I </li></ul></ul><ul><ul><li>Part II </li></ul></ul><ul><ul><li>Part III </li></ul></ul><ul><ul><li>Part IV </li></ul></ul>