Agile Project Management ...

Click here to load reader

  • date post

  • Category


  • view

  • download


Embed Size (px)

Transcript of Agile Project Management ...

  • Agile Project Management CHARLIE PFEIFFER, PMP, CSP


    OCTOBER, 7 2015

  • Agenda 9:00-9:10 – Introduction

    ◦ Agenda ◦ About Charlie Pfeiffer

    9:10-9:25 – Traditional Project Management ◦ Project Management Phases & Processes ◦ Triple Constraint ◦ Waterfall Methodology ◦ Work Breakdown Structure ◦ Project Communications ◦ Waterfall Challenges

    9:25-9:40 – Agile Project Management ◦ Agile Manifesto ◦ Agile Methodology ◦ Scrum Process ◦ Product Backlogs ◦ Scrum Team Communications ◦ Kanban Process

    9:40-9:50 – SCORE (SCrum fOr REsearch) ◦ About SCORE ◦ SCORE Structure ◦ Backlog Management ◦ Feedback on SCORE

    9:50-10:00 – Wrap Up ◦ Agile Resources

  • About Charlie Pfeiffer UC ANR IT Project Manager

    ◦ Joined UC ANR in March 2015

    ◦ Implementing Agile/Scrum Practices within the Web Development Team

    ◦ Managing Infrastructure Projects

    Background ◦ 15+ years in Project Management (Waterfall and Agile Methodologies)

    ◦ Implemented Project Management Processes at multiple organizations (Waterfall and Agile)

    ◦ Various Industry experience, including State, Insurance, Payment Processing, Inventory Management, Retail, Travel, and Loyalty

    Project Management Certifications ◦ Project Management Professional (PMP) – Project Management Institute

    ◦ Certified Scrum Professional (CSP) – ◦ Certified Scrum Master (CSM) and Certified Scrum Product Owner (CSPO)

  • Traditional Project Management Project Management Phases

    Project Management Processes

    Triple Constraint

    Waterfall Methodology

    Work Breakdown Structure

    Project Communications

    Waterfall Challenges

    10:10 AM 10:25 AM

  • Project Management Phases

  • Project Processes Initiation Planning & Design Executing Monitoring &

    Controlling Closing

    • Project charter

    • Collect requirements • Define scope • Create WBS • Assign resources • Develop schedule • Determine budget • Communication plan • Risk management


    • Manage project execution

    • Perform QA • Manage project

    team • Manage stakeholder

    expectations • Distribute


    • Change control process

    • Verify & control scope

    • Control schedule • Control budget • Report

    performance • Monitor & control


    • Close project

  • Triple Constraint (Project Management Triangle)





    You cannot change one without impacting the others

    If you want to increase Scope, then Time and/or Cost will increase

    If you want to decrease Time, then you will need to reduce Scope, or Increase cost

    If you want to decrease Cost, then you will need to reduce Scope

    Quality is be impacted by decisions to change any of the constraints

  • Waterfall Methodology Planning takes place first

    The entire project is defined and documented before the work starts

    Work tends to be done in silos

    Change Management process for handling scope, time, or budget changes

    Regular status meetings to keep project team and stakeholders updated

  • Work Breakdown Structure (WBS) List all tasks for the project

    Estimate the durations of each task

    Identify Task Dependencies

    Assign resources (may need to modify based on resource availability)

    WBS will show what tasks should be worked on every day of the project

    WBS will show the critical path of the project

    Project Manager must stay on top of the WBS every day

  • Project Communications Status meetings with project team to make sure project is staying on track

    Status meetings with stakeholders to update them on progress

    Status meetings with managers to update them on progress

    Meetings include reviewing: ◦ Scope

    ◦ Schedule

    ◦ Budget

    ◦ Quality

    ◦ Issues

    ◦ Risks

    ◦ Project Metrics

  • Challenges with Waterfall Lacks collaborative environment

    “Throw over fence” mentality

    Team members still have functional managers to please (in Matrix organizations)

    Accountability falls on Project Manager, not the team

    Focused on heavy processes, not on results

    Too many lengthy status meetings

    Team members often wait for status meetings to bring up issues

    Stakeholders often don’t see result until project is complete

    “I believe in this concept, but implementation described above is risky and invites failure.” Dr. Winston W. Royce

    “Today is the dumbest day of the rest of our project.” Michael James, CST

  • 2011 CHAOS report (Standish Group)

    Successful 14%

    Challenged 57%

    Failed 29%

    Waterfall Projects

    Successful 42%

    Challenged 49%

    Failed 9%

    Agile Projects

  • Agile Project Management Agile Manifesto

    Agile Methodology

    Scrum Process

    Product Backlogs

    Scrum Team Communications

    Kanban Process

    10:25 AM 10:40 AM

  • Agile Manifesto Promotes teams working together to achieve a shared goal.

    Focus on completing product increments that provide value.

    Constant communications between teams and stakeholders to ensure the right product is being created.

    Flexibility to adapt to evolving visions, rather than following a plan developed when you knew the least about the project/product.

  • Agile Methodology Removes the silos to allow for better collaboration and teamwork

    Succeed or Fail as a team

    Focus on highest priority/value items first

    Work on product increments in iterations/sprints

    Ability to adapt as visions/needs change

    Stakeholders see results/progress after every iteration

    Ability to adapt as visions/needs change

  • Scrum Process Backlog


    Sprint Planning

    Daily Scrum Sprint Review

    Sprint Retrospective

  • Product Backlog All work identified for the product is in the Product Backlog

    Prioritized by the Product Owner

    As new work items are identified they are added to the backlog, including feedback from Sprint Reviews

    Scrum Team estimate level of effort for each work item

    ◦ This should happen at least once every sprint

    Estimated work items provide a roadmap for when items can be completed

  • Sprint Planning First activity of every sprint

    Team commits to work items they can complete in the sprint

    Use estimates to assist in determining which work items can be completed

    Work items broken down into tasks

    Hour estimates for tasks

    Once planning is done, work items should not be added or removed from the Sprint

    Tasks do not need to be assigned

  • Daily Scrum / Standup Daily Standup meeting

    No longer than 15 minutes

    Answer three questions: 1. What you did yesterday

    2. What you will do today

    3. Any impediments preventing your work

    For the team members, not the Scrum Master

    Not a status meeting (the team should not be saving issue updates for the next Standup)

  • Sprint Review Team Demonstrates completed work items

    from the sprint to the stakeholders

    Sometimes stakeholders don’t know what they want until they see it

    Feedback provided from team and stakeholders (product ideas)

    Provide update to stakeholders on roadmap, including what has changed since the last Sprint Review

  • Kanban Process Very similar to Scrum

    Product Backlog is managed the same as Scrum

    There is not a time-boxed sprint, work is done continuously ◦ When a team member finishes a work item, they can assign themselves to the next highest priority

    work item on the Kanban board

    Great for teams that cannot predict work for an entire sprint (sprints are typically 1-4 weeks) ◦ Examples: Help Desk / Support – When high priority support is needed, it can’t wait until next sprint

    Recommend to still have a regularly scheduled review of the work items completed ◦ This keeps stakeholders in the loop

    ◦ It also keeps pressure on the team to continue performing


    Daily Scrum & On Demand Meetings

    Backlog Management

    Feedback on SCORE

    10:40 AM 10:50 AM

  • About SCORE SCORE – SCrum fOr REsearch

    Created by Michael Hicks and Jeffrey S. Foster from University of Maryland

    The traditional approach to working with Ph.D. students wasn’t working ◦ They would block one hour per week for each student to mentor with projects

    ◦ Sometimes an hour was too much, and sometimes it was not enough

    ◦ There was little-to-no collaboration, or learning