The Agile PMP Workshop

3,263 views
3,045 views

Published on

A full day workshop that helps traditional project managers make the philosophical and technical switch to agile

Published in: Technology, Business
0 Comments
7 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,263
On SlideShare
0
From Embeds
0
Number of Embeds
15
Actions
Shares
0
Downloads
469
Comments
0
Likes
7
Embeds 0
No embeds

No notes for slide
  • 1/8/2008
  • The Agile PMP Workshop

    1. 1. The Agile PMP Workshop
    2. 2. Introductions <ul><li>Product consultant and agile evangelist for VersionOne </li></ul><ul><li>Previously a Senior Project Manager for CheckFree Corporation </li></ul><ul><li>PMP, CSM, DSDM Agile Project Leader </li></ul><ul><li>Board member of APLN and the current Treasurer. Founder APLN Atlanta </li></ul>
    3. 3. The Agile elevator speech <ul><li>Umbrella term to describe a family of methodologies: </li></ul><ul><ul><li>XP </li></ul></ul><ul><ul><li>Scrum </li></ul></ul><ul><ul><li>DSDM </li></ul></ul><ul><ul><li>AUP </li></ul></ul><ul><ul><li>Crystal </li></ul></ul><ul><ul><li>FDD </li></ul></ul><ul><li>Engineering best practices </li></ul><ul><li>Project management methodology </li></ul><ul><li>Leadership philosophy </li></ul>
    4. 4. Hidden PM Assumptions
    5. 5. Assumptions of Traditional PM <ul><li>Assumptions introduce risk </li></ul><ul><li>We tend to assume that with enough up front planning that we can make projects predictable </li></ul>
    6. 6. Why Agile? <ul><li>Not all projects are predictable </li></ul><ul><li>Market uncertainty drives change </li></ul><ul><li>The less certain we are about our requirements, the more we need to plan to adapt </li></ul>Technical Pace Novelty Complexity * Reinventing Project Management by Aaron Shenhar and Dov Dvir
    7. 7. The Cost of Change <ul><li>Cost of traditional change management is too high in many project contexts </li></ul><ul><li>Change control is bureaucratic and slow </li></ul><ul><li>We become resistant to change when we should embrace change </li></ul>
    8. 8. Ensures acceptable outcomes <ul><li>Agile costs less when you factor in the cost of change management </li></ul><ul><li>Different way of looking at project control </li></ul><ul><li>Risk mitigation tactic that be used when assumptions about predictability don’t hold </li></ul>
    9. 9. Managing tradeoffs <ul><li>New way of looking at the balance between time, cost, and scope </li></ul><ul><li>In traditional methodologies we start with scope and estimate time and budget </li></ul><ul><li>This results in a false sense of certainty about the features </li></ul><ul><li>Unrealistic expectations around the team’s ability to deliver </li></ul>Time Scope Cost Traditional Project Management
    10. 10. Drive your projects <ul><li>Turns the Iron Triangle upside down </li></ul><ul><li>Agile methodologies define the time and cost and vary the scope </li></ul><ul><li>Gives the Product Manger fine grained control on the projects outcome. </li></ul>Time Cost Scope Agile Project Management
    11. 11. The Case for Agile
    12. 12. Agile Project Management <ul><li>Empirical process control </li></ul><ul><li>Visibility, inspection, and adaptation </li></ul><ul><li>Deliver product in short cycles </li></ul><ul><li>Inspect what been delivered </li></ul><ul><li>Adapt process or requirements based on what the team has learned about the emerging product </li></ul>
    13. 13. Ensures acceptable outcomes <ul><li>Agile costs less when you factor in the cost of change management </li></ul><ul><li>Different way of looking at project control </li></ul><ul><li>Risk mitigation tactic that be used when assumptions about predictability don’t hold </li></ul>
    14. 14. Paper Airplane Exercise
    15. 15. The Agile Manifesto <ul><li>We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: </li></ul><ul><li>Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan </li></ul><ul><li>That is, while there is value in the items on the right, we value the items on the left more. </li></ul><ul><li>*www.agilemanifesto.org </li></ul>
    16. 16. 12 Principles of the Agile Manifesto <ul><li>Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. </li></ul><ul><li>Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. </li></ul><ul><li>Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. </li></ul>
    17. 17. 12 Principles of the Agile Manifesto <ul><li>The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. </li></ul><ul><li>Business people and developers must work together daily throughout the project. </li></ul><ul><li>Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. </li></ul>
    18. 18. 12 Principles of the Agile Manifesto <ul><li>Working software is the primary measure of progress. </li></ul><ul><li>Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. </li></ul><ul><li>Continuous attention to technical excellence and good design enhances agility. </li></ul>
    19. 19. 12 Principles of the Agile Manifesto <ul><li>Simplicity--the art of maximizing the amount of work not done--is essential. </li></ul><ul><li>The best architectures, requirements, and designs emerge from self-organizing teams. </li></ul><ul><li>At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. </li></ul>
    20. 20. Agile Process Overview Vision Q1 Q2 Q3 Q4 Product Roadmap Release Plan
    21. 21. Writing the PM Plan <ul><li>Process Groups </li></ul><ul><ul><li>Initiating </li></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Executing </li></ul></ul><ul><ul><li>Controlling </li></ul></ul><ul><ul><li>Closedown </li></ul></ul><ul><li>Knowledge Areas </li></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Cost </li></ul></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><li>Risk </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Human Resources </li></ul></ul><ul><ul><li>Procurement </li></ul></ul><ul><ul><li>Integration </li></ul></ul>
    22. 22. Project Doggie Daycare <ul><li>As part of Doggie Daycare, the local high-end dog salon needs a system that allows customers to: </li></ul><ul><ul><li>Schedule dog appointments online. </li></ul></ul><ul><ul><li>View dog grooming styles. </li></ul></ul><ul><ul><li>View stylist information. </li></ul></ul><ul><ul><li>Interact in an online community. </li></ul></ul>
    23. 23. Product Planning
    24. 24. Backlog Fundamentals <ul><li>Product backlog </li></ul><ul><ul><li>A prioritized list of features that the customer would like to have developed into their software product </li></ul></ul><ul><li>Backlog item </li></ul><ul><ul><li>A high level description of an individual feature in the backlog. It is a placeholder for a future conversation about that feature </li></ul></ul>
    25. 25. INVEST <ul><li>I – Independent </li></ul><ul><li>N – Negotiable </li></ul><ul><li>V – Valuable </li></ul><ul><li>E – Estimateable </li></ul><ul><li>S – Small or Sized Appropriately </li></ul><ul><li>T - Testable </li></ul>
    26. 26. Which are Good Backlog Items? <ul><li>As a dog owner, I want to select a stylist for my dog. </li></ul><ul><li>Administrator adds new style to the style catalog. </li></ul><ul><li>Develop database schema for the style catalog. </li></ul><ul><li>As a dog owner, I want to interact in an online community with other dog owners. </li></ul><ul><li>Susie Stylist updates her stylist profile. </li></ul><ul><li>Select a calendar day. </li></ul><ul><li>Research online credit card processing service. </li></ul><ul><li>As a system administrator, I want to add a new stylist profile so that the user may login. </li></ul>
    27. 27. Writing a Good Backlog Item <ul><li>TEMPLATE </li></ul><ul><li>As a _____________ I want to be able to ______________ </li></ul><ul><li>so that __________________ . </li></ul><ul><li>EXAMPLE </li></ul><ul><li>“ As a newly trained VersionOne user, I want to be </li></ul><ul><li>able to login to VersionOne.org so that I may </li></ul><ul><li>rate my instructor.” </li></ul><ul><li>Assumes architecture </li></ul><ul><li>Valuable to the user </li></ul>
    28. 28. Exercise 1: Doggie Day Care Backlog Items <ul><ul><li>Write the backlog items for the Doggie Day Care Style Catalog. Some basic requirements are: </li></ul></ul><ul><ul><li>Users want to search the catalog for both dog styles and stylist information </li></ul></ul><ul><ul><li>Stylists need to be able to update their own information in the catalog </li></ul></ul><ul><ul><li>A system administrator needs to be able to manage the stylist’s profiles and access to the style catalog administration area. </li></ul></ul>
    29. 29. More Backlog Fundamentals <ul><li>Sizing your backlog </li></ul><ul><ul><li>Story points </li></ul></ul><ul><ul><li>Ideal engineering hours </li></ul></ul><ul><ul><li>Ideal engineering days </li></ul></ul><ul><li>Prioritizing your backlog </li></ul><ul><ul><li>High, Medium, Low </li></ul></ul><ul><ul><li>MoSCoW Rules </li></ul></ul><ul><ul><li>Rank order </li></ul></ul>
    30. 30. The Project Management Plan <ul><li>Process Groups </li></ul><ul><ul><li>Initiating </li></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Executing </li></ul></ul><ul><ul><li>Controlling </li></ul></ul><ul><ul><li>Closedown </li></ul></ul><ul><li>Knowledge Areas </li></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Cost </li></ul></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><li>Risk </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Human Resources </li></ul></ul><ul><ul><li>Procurement </li></ul></ul><ul><ul><li>Integration </li></ul></ul>
    31. 31. Release Planning
    32. 32. Release Planning <ul><li>Release planning is process of determining how much can be delivered in a project by a given date </li></ul><ul><li>Typically release planning will be done by fixing the release date, estimating the team’s capacity, and making an estimate of how many features can be delivered in that time </li></ul><ul><li>The team’s capacity is determined by considering their historical velocity or by predicting a planned velocity at the beginning of the project </li></ul>
    33. 33. Scoping a Release <ul><li>Choose the highest priority features first </li></ul><ul><li>Include a mix of must have features, should have features, and could have features </li></ul><ul><li>DSDM recommends a 60%, 20%, 20% split </li></ul><ul><li>The reality is that the team’s velocity is unknown during the early sprints </li></ul><ul><li>As you begin to execute the project (and measure actual velocity, you will begin to understand what can really be accomplished. </li></ul><ul><li>The team needs flexibility to negotiate content if necessary </li></ul>
    34. 34. Release Planning – a Demonstration <ul><li>Release goal: </li></ul><ul><ul><li>Fully functional Doggie Day Care Style Catalog, with dog owners able to search, stylist able to login and administer their profiles, and system admin able to control security access. </li></ul></ul><ul><li>Let’s estimate the backlog items </li></ul><ul><li>Prioritize the backlog items </li></ul><ul><li>Estimate our velocity </li></ul><ul><li>Allocate backlog items to the release </li></ul>
    35. 35. The Project Management Plan <ul><li>Process Groups </li></ul><ul><ul><li>Initiating </li></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Executing </li></ul></ul><ul><ul><li>Controlling </li></ul></ul><ul><ul><li>Closedown </li></ul></ul><ul><li>Knowledge Areas </li></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Cost </li></ul></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><li>Risk </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Human Resources </li></ul></ul><ul><ul><li>Procurement </li></ul></ul><ul><ul><li>Integration </li></ul></ul>
    36. 36. Sprint Planning
    37. 37. What is a Sprint?
    38. 38. Determining Sprint Length <ul><li>Scrum recommends a 30 day sprint </li></ul><ul><li>Most Agile methodologies recommend between 1 and 4 weeks </li></ul><ul><li>Consider the size and complexity o the solution </li></ul><ul><li>Number of interdependencies </li></ul><ul><li>Degree of automation </li></ul><ul><li>Dynamics of the team </li></ul><ul><li>Shorter cycles are generally better </li></ul>
    39. 39. Sprint Planning - Part I <ul><li>Four hours maximum </li></ul><ul><li>Attended by Product Owner, Scrum team, customers, management </li></ul><ul><li>Product Owner brings the “What” </li></ul><ul><li>Team selects as much Product Backlog Features as it believes it can develop during the next Sprint </li></ul><ul><li>Estimates may be revised upon review </li></ul><ul><li>Lower priority features may be included if appropriate and Product Owner agrees </li></ul><ul><li>Estimated effort/cost for selected features is a budget that team manages to; negotiate with Product Owner before exceeding. </li></ul>
    40. 40. Sprint Planning – Part II <ul><li>Four hours maximum </li></ul><ul><li>Team defines how to build the “What” </li></ul><ul><li>Attended by product owner, delivery team, development management </li></ul><ul><li>Design is extended in this session by decomposing features into tasks, or writing backlog items </li></ul><ul><li>Tasks are estimated between 1/2 day – 2 days in size </li></ul><ul><li>The list of tasks is called the Sprint Backlog </li></ul><ul><li>Team verifies that estimates do not exceed capacity </li></ul><ul><li>Team members commit to the sprint </li></ul>
    41. 41. Sprint Backlog <ul><li>Team collects the tasks in a Sprint Backlog </li></ul><ul><li>Similar structure to the Product Backlog </li></ul><ul><li>Team members sign up for tasks, they aren’t assigned </li></ul><ul><li>Estimates are assigned to tasks by the team </li></ul><ul><li>Any team member can add, delete or change the Sprint Backlog during the Sprint </li></ul><ul><li>Work for the Sprint emerges during the planning session </li></ul><ul><li>Work (content, estimates, sign-up) can change during the Sprint </li></ul>
    42. 42. Sample Sprint Backlog
    43. 43. Exercise 2 – Doggie Daycare Planning Your First Sprint <ul><li>Using the team scenario you are given: </li></ul><ul><li>Working from the prioritized product backlog, decide how many backlog items can be added into your sprint </li></ul><ul><li>Product owners present the backlog items to the development team and allow them to ask questons </li></ul><ul><li>Product owners define acceptance criteria for each backlog item </li></ul><ul><li>Developers break the backlog items into tasks, with hour estimates </li></ul>
    44. 44. The Project Management Plan <ul><li>Process Groups </li></ul><ul><ul><li>Initiating </li></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Executing </li></ul></ul><ul><ul><li>Controlling </li></ul></ul><ul><ul><li>Closedown </li></ul></ul><ul><li>Knowledge Areas </li></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Cost </li></ul></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><li>Risk </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Human Resources </li></ul></ul><ul><ul><li>Procurement </li></ul></ul><ul><ul><li>Integration </li></ul></ul>
    45. 45. Sprint Execution
    46. 46. Executing Through the Sprint <ul><li>Daily Standup Meetings </li></ul><ul><li>Visible Progress/Information Radiators </li></ul><ul><li>Agile Reporting </li></ul>
    47. 47. Daily Standup Meetings <ul><li>Rules: </li></ul><ul><ul><li>Daily, 15-minute meeting </li></ul></ul><ul><ul><li>Same time, same place every day </li></ul></ul><ul><ul><li>No problem solving </li></ul></ul><ul><li>Each team member answers three questions: </li></ul><ul><ul><li>What did you do yesterday? </li></ul></ul><ul><ul><li>What are you doing today? </li></ul></ul><ul><ul><li>What is getting in your way? </li></ul></ul><ul><li>Action the Impediments </li></ul><ul><li>Note the Decisions </li></ul><ul><li>Stakeholders are invited to observe but can’t talk: </li></ul><ul><ul><li>Take issues to ScrumMaster after the Standup has ended </li></ul></ul><ul><li>Optional: collect estimates at the end of the meeting </li></ul>
    48. 48. Visual Progress Indicators (by hand)
    49. 49. Visual Progress Indicators (w/VersionOne)
    50. 50. Exercise 3: Daily Standup Meeting <ul><li>Using your team scenarios and roles, participate in the daily standup meeting. </li></ul><ul><li>Each team member answers three questions: </li></ul><ul><ul><li>What did you do yesterday? </li></ul></ul><ul><ul><li>What are you doing today? </li></ul></ul><ul><ul><li>What is getting in your way? </li></ul></ul><ul><li>Action the Impediments </li></ul><ul><li>Note the Decisions </li></ul>
    51. 51. Definition of Done <ul><li>done [duhn] –verb </li></ul><ul><li>completed; finished; through: Our work is done. </li></ul><ul><li>cooked sufficiently. </li></ul><ul><li>worn out; exhausted; used up. </li></ul><ul><li>in conformity with fashion, good taste, or propriety; acceptable: It isn't done. —Idioms </li></ul><ul><li>be or have done with, to break off relations or connections with; stop. </li></ul><ul><li>done for, Informal. a.tired; exhausted. b.deprived of one's means, position, etc. c.dead or close to death. </li></ul><ul><li>done in, Informal. very tired; exhausted: He was really done in after a close race. </li></ul>
    52. 52. What is “Done” on an Agile Project? <ul><li>Designed </li></ul><ul><li>Coded </li></ul><ul><li>Integrated </li></ul><ul><li>Documented </li></ul><ul><li>All tests pass </li></ul>
    53. 53. The Project Management Plan <ul><li>Process Groups </li></ul><ul><ul><li>Initiating </li></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Executing </li></ul></ul><ul><ul><li>Controlling </li></ul></ul><ul><ul><li>Closedown </li></ul></ul><ul><li>Knowledge Areas </li></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Cost </li></ul></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><li>Risk </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Human Resources </li></ul></ul><ul><ul><li>Procurement </li></ul></ul><ul><ul><li>Integration </li></ul></ul>
    54. 54. Sprint Closedown
    55. 55. Sprint Review <ul><li>Has two parts, typically spans a full day: </li></ul><ul><ul><li>Part 1: Demo and Review of Sprint results </li></ul></ul><ul><ul><li>Part 2: Retrospective to review Sprint process with the team </li></ul></ul><ul><li>Takes place on the last day of the Sprint – no delays </li></ul><ul><li>Precedes the next Sprint Planning Meeting </li></ul>
    56. 56. Sprint Demo and Review <ul><li>Team presents what it accomplished during the Sprint </li></ul><ul><li>Typically takes the form of a demo of new features or underlying architecture </li></ul><ul><li>Informal </li></ul><ul><ul><li>2-hour prep time rule </li></ul></ul><ul><li>Attendees </li></ul><ul><ul><li>Team (Customer Representative, Developers, Testers, Architect, etc.) </li></ul></ul><ul><ul><li>ScrumMaster </li></ul></ul><ul><ul><li>Product Owner, Customers </li></ul></ul><ul><ul><li>Stakeholders </li></ul></ul><ul><ul><li>All other interested parties </li></ul></ul><ul><li>No PowerPoint </li></ul>
    57. 57. What is being made visible <ul><li>Delivered features </li></ul><ul><li>Incomplete features </li></ul><ul><li>Verifying ‘Done’ with the customer/product owner </li></ul><ul><li>Maintaining trust with customer by not “hiding” undone work </li></ul><ul><li>Team and Customer responds to the delivery </li></ul><ul><li>The Goal: Collaborative Decision-Making about the emerging product </li></ul>
    58. 58. Possible Sprint Outcomes <ul><li>Removing features from the Product Backlog that the team unexpectedly completed </li></ul><ul><li>Restoring unfinished features to the Product Backlog (and reprioritizing if necessary) </li></ul><ul><li>Working with the ScrumMaster to reformulate the team (add, remove team members) </li></ul><ul><li>Reprioritizing the Product Backlog to take advantage of opportunities that the demonstrated functionality presents </li></ul><ul><li>Ask for a release Sprint to implement the demonstrated functionality, alone or with increments from previous Sprints </li></ul><ul><li>Choosing not to proceed further with the project and not authorizing another Sprint </li></ul><ul><li>Requesting that the project progress be sped up by authorizing additional teams to work on the Product Backlog </li></ul>
    59. 59. Retrospectives <ul><li>Inspect and adapt at the end of every Sprint </li></ul><ul><li>Attended only by the team </li></ul><ul><li>Facilitated by ScrumMaster or objective third party </li></ul><ul><li>What went well, what could be improved </li></ul><ul><li>ScrumMaster prioritizes improvements based on team direction </li></ul><ul><li>Team devises solution to most vexing problems </li></ul>
    60. 60. Retrospectives Agenda <ul><li>What were the major events in our timeline? </li></ul><ul><li>What can we observe about the flow of events? </li></ul><ul><li>What were the Sprint metrics (tasks completed, actuals versus estimates, resource distributions, builds, bugs etc.) </li></ul><ul><li>What have we learned about the product as a result of this Sprint? </li></ul><ul><li>What have we learned about the team as a result of this Sprint? </li></ul><ul><li>What worked well in our Sprint that we would want to do again? </li></ul><ul><li>What do we wish we’d done differently? </li></ul><ul><li>What recommendations are there moving forward with our next Sprint? </li></ul><ul><li>Inspect the Process not the People </li></ul><ul><li>“ Inspect and Adapt” </li></ul>
    61. 61. Exercise 4 – Sprint Review and Retrospective <ul><li>Review the completed work for the Sprint </li></ul><ul><li>Make decisions on uncompleted work </li></ul><ul><li>Conduct a team retrospective, using SAMOLO: </li></ul><ul><ul><li>What would we do the Same As before? </li></ul></ul><ul><ul><li>What would we do More Of? </li></ul></ul><ul><ul><li>What would we do Less Of? </li></ul></ul><ul><li>Build a list of action items and assign them </li></ul><ul><li>Review the team issues list </li></ul>
    62. 62. Reviewing your PM Plan <ul><li>Process Groups </li></ul><ul><ul><li>Initiating </li></ul></ul><ul><ul><li>Planning </li></ul></ul><ul><ul><li>Executing </li></ul></ul><ul><ul><li>Controlling </li></ul></ul><ul><ul><li>Closedown </li></ul></ul><ul><li>Knowledge Areas </li></ul><ul><ul><li>Time </li></ul></ul><ul><ul><li>Cost </li></ul></ul><ul><ul><li>Scope </li></ul></ul><ul><ul><li>Quality </li></ul></ul><ul><ul><li>Risk </li></ul></ul><ul><ul><li>Communication </li></ul></ul><ul><ul><li>Human Resources </li></ul></ul><ul><ul><li>Procurement </li></ul></ul><ul><ul><li>Integration </li></ul></ul>
    63. 63. Adopting Agile Culture
    64. 64. Agile PM Model <ul><li>Project Manager as the center of the project </li></ul><ul><li>Project manager as an enabler </li></ul>PM Team Team Team Team Team Team Team Team PM
    65. 65. Empowerment <ul><li>Create the context </li></ul><ul><li>Social Engineering </li></ul><ul><li>Process has to be managed </li></ul>
    66. 66. Self-Organization &quot; Simple, clear purpose and principles give rise to complex and intelligent behavior. Complex rules and regulations give rise to simple and stupid behavior.” Dee Hock, Founder and Former CEO of Visa International
    67. 67. Trust <ul><li>Expect the best out of people </li></ul><ul><li>Elevate the individual, give them respect </li></ul><ul><li>Value people and encourage relationships </li></ul>
    68. 68. Accountability <ul><li>Measure results, not processes or steps </li></ul><ul><li>Focus on value </li></ul><ul><li>Inspect the process </li></ul><ul><li>Create a culture of accountability </li></ul>
    69. 69. 8 things to keep in mind <ul><li>Understand Agile team dynamics </li></ul><ul><li>Champion the project vision </li></ul><ul><li>Remove obstacles </li></ul><ul><li>Focus on team building </li></ul><ul><li>Become a facilitator </li></ul><ul><li>Develop talent through coaching </li></ul><ul><li>Encourage project structure </li></ul><ul><li>Help the team commit </li></ul>
    70. 70. It’s really about leadership… <ul><li>Agile Project Management is about becoming a great leader </li></ul><ul><li>Accept input from reality and respond to it </li></ul><ul><li>Look out for the best interest of the team </li></ul><ul><li>Seek out what is not being said </li></ul><ul><li>There is no success for anyone unless we are all successful </li></ul>
    71. 71. APM is different… <ul><li>Focus on individuals and interactions over processes and tools </li></ul><ul><li>Focus on working software over comprehensive documentation </li></ul><ul><li>Focus on customer collaboration over contract negotiation </li></ul><ul><li>Focus on responding to change over following a plan </li></ul>
    72. 72. Wrapping it all up… <ul><li>Agile is a risk mitigation technique available for managing projects in highly uncertain project domains </li></ul><ul><li>PMI is a flexible enough framework to accommodate Agile concepts </li></ul><ul><li>The process groups, knowledge areas, and PM processes represent project management best practice </li></ul><ul><li>It is the rigid application of these processes that make them incompatible with Agile </li></ul>
    73. 73. Simplifying Software Delivery

    ×