Project Management to Enterprise Agile Product Delivery
•Download as PPTX, PDF•
4 likes•1,746 views
This deck explores how Project Managers, Program Managers and Portfolio Managers fit into an Enterprise Agile setting. The slide deck was used during a presentation by VP & Principal Consultant, Greg King at a meetup with the Atlanta Scrum Users Group.
Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (19)
Similar to Project Management to Enterprise Agile Product Delivery
Similar to Project Management to Enterprise Agile Product Delivery (20)
More from LeadingAgile
More from LeadingAgile (20)
Recently uploaded
Recently uploaded (20)
Project Management to Enterprise Agile Product Delivery
- 1. Project Management to Enterprise Agile Product Delivery
- 2. 2 greg.king@leadingagile.com 404-729-8931 www.leadingagile.com twitter.com/greguf96 facebook.com/leadingagile linkedin.com/in/gregpking Greg King Principal Transformation Consultant * Special thanks to Devin Hedge for his assistance in this presentation.
- 3. Project Managers in Agile?
- 4. THERE IS NO PROJECT MANAGER IN MOST AGILE MANAGEMENT FRAMEWORKS
- 6. THERE IS NO PROJECT IN MOST AGILE MANAGEMENT FRAMEWORKS Traditional Scrum
- 7. Project Manager Responsibilities In Waterfall, the Project Manager Would… Create Project Plan/Gantt Define and Manage Scope & Activities Gather Estimations Form Project Teams Get Progress Status Manage Risks Create Release Plan, Sprint Plans Create, Refine, and Prioritize Backlogs, Tasks Make Estimations Work in Cross-functional/stable Teams Provide Burn-up and Burn down charts Mitigate and Drive Risks down early In Agile, the Product Owner Team or Delivery Team Will… Manage Issue Log Identify and clear impediments
- 8. So, Dude! Where’s My Job?
- 9. PROJECT MANAGEMENT SKILLS ARE STILL NEEDED IN AGILE! Integration Management Scope Management Time Management Cost Management Quality Management Human Resource Management Communications Management Risk Management Dependency Management
- 10. Why Agile Works
- 11. Team 11
- 12. Team User Story User Story User Story User Story User Story User Story User Story 12
- 13. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story 13
- 14. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity 14
- 15. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability 15
- 16. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress 16
- 17. Why Agile Works At Scale
- 18. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Clarity Accountability Measureable Progress 18
- 19. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Accountability Measureable Progress 19 Governance
- 20. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Structure Measureable Progress Governance 20
- 21. Team Database Report Screen User Story User Story User Story User Story User Story User Story User Story Structure 21 MetricsGovernance
- 22. Governance
- 23. Story Ready Story Accepted Story Done DoneFeature Ready Completed Detailed Planning (Clarity & Viability) Solution Validation (Dependencies, Sizing & Risks) In Progress Make Ready FeatureStoryEpic Feature Planning Solution Design To Be Considered Strategic Alignment Execution & Accountability Measurable Progress Demand Planning & Release Commitment Three Tier Governance Model Portfolio Program Delivery Feature Validation Epic Validation In Progress In ProgressRelease Targeting Investment Solution Investment Decision ScrumKanbanKanban
- 24. Structure
- 25. Team Team Team Team Team Team Team Team TeamTeamTeam Delivery Tier Program Tier Portfolio Tier
- 26. Portfolio Teams Flow BasedTeam Team Team Team Team Team Team Team TeamTeamTeam 26 Delivery Tier Program Tier
- 27. Program Teams Portfolio Teams Flow Based Team Team Team Team Team Team Team Team TeamTeamTeam 27 Portfolio Teams Flow Based Delivery Tier
- 28. Product & Services Teams Iterative & Incremental Program Teams Portfolio Teams Flow Based Team Team Team Team Team Team Team Team TeamTeamTeam 28 Portfolio Teams Flow Based
- 30. 30 Metrics • Cycle Time • Features Blocked • Rework/Defects • Backlog Size • Velocity • Burndown • Escaped Defects • Commit % Ratio • Acceptance % Ratio • Scope Change • Lead Time/Cycle Time • Time/Cost/Scope/Value • ROI/Capitalization
- 31. So, Dude! You Still Haven’t Told Me Where My Job Went?
- 32. Project Managers in Enterprise Agile
- 34. Servant Leadership • A Servant Leader manages a team not by telling them what to do, but by removing impediments that get in their way • Other things a servant leader can do: – Coaches in agile best practices – Shields the team from diversions and distractions – Facilitates planning sessions, reviews, retrospectives – Encourages transparency and associated metrics – Arbitrates between team members when necessary – Be an advocate “The best way to find yourself is to lose yourself in the service of others.” – Mahatma Gandhi
- 35. Embrace the Agile Manifesto 35 Satisfy the Customer Welcome Change Deliver Working Product Frequently Collaborate Daily Support & Trust Motivated Teams Face to Face conversations Working Product Primary Measure of Progress Sustainable Pace Technical Excellence Simplicity Self-Organizing Teams Reflect & Adjust Regularly Values Principles Individuals & Interactions over Processes & Tools Working Software over Comprehensive Documentation Customer Collaboration over Contract Negotiation Responding to Change over Following a Plan
- 36. Program Teams Portfolio Teams Flow Based Team Team Team Team Team Team Team Team TeamTeamTeam 36 Portfolio Teams Flow Based Delivery Tier
- 37. Portfolio Team Portfolio Team Business Owner Enterprise Architect Portfolio Manager Financial Leader
- 38. Portfolio Team Objectives, Activities & Artifacts Detailed Planning Epic Roadmap Epic Estimation Objectives Establish a budget for the epic scope Facilitate ROI calculations Artifacts Epic Brief Objectives Provide a 6-12 month roadmap of Epics to be considered. (Understand capacity) Artifacts Roadmap Objectives Collaborate to create a credible release plan Artifacts Release Plan Risk Register Scope Management Plan Objectives Monitor epics in production to evaluate value Artifacts Defect Analysis Change Analysis Usage Develop Build and Test Evaluate Performance Objectives Monitor stats and quality of deliverables Artifacts Status Reports Portfolio performance Delivery team Reviews
- 39. Portfolio Manager Applies knowledge, skills, tools, and techniques through: • Communication Management – Maintains and facilitates the Portfolio team ceremonies and schedule – Communicates decisions that affect delivery schedule to all stakeholders • Quality Management – Defines the reporting metrics used to determine the health of deliveries – Defines the standards for determining Feature and Epic delivery health • Time, Cost, & Scope Management – Approves changes to the toolsets used to track progress • Risk Management – Develops the standards for delivery risk management • Human Resource Management – Aligns delivery capacity to Epics – Removes impediments and is an escalation point for delivery issues that affect multiple teams
- 40. Product Owner Team Product Owner Team Product Owner Test Lead Technical Architect Business Analyst Program Manager
- 41. Product Owner Team Objectives, Activities & Artifacts Release Planning Story Mapping Epic Decomposition Objectives Identifies the Features in an Epic Facilitates Detailed planning Artifacts Feature List Features Definition Feature Acceptance Test Workflow diagrams Objectives Collaborate to create list of high level stories that can be placed in the Sprints of a release Artifacts Initial Release Plan Story Map Objectives Collaborate to create a credible release plan Artifacts Release Plan Risk Register Scope Management Plan Objectives Create an integrated and tested solution at the end of every sprint. Artifacts Regression Suite pass percentage Build Metrics Integration and Verification Objectives Monitor stats and quality of deliverables Artifacts Status Reports Delivery team reviews Develop and Test
- 42. Program Manager Applies knowledge, skills, tools, and techniques through: • Dependency Management – Manages dependencies between delivery teams • Risk Management – Is responsible for overseeing regular risk management activities for the Product Owner team and the Release • Communication Management – Schedules and facilitates Product Owner team ceremonies & meetings • Quality Management – Ensures Delivery and Product Owner team metrics and assessments are reviewed • Time, Cost, and Scope Management – Tracks the progress of features throughout the sprints and release and reports status • Human Resource Management – Works effectively with others to remove delivery roadblocks – Serves as an escalation point for scrum masters
- 43. Other Roles • Release Manager • Scrum Master • Product Owner • Product Manager • Agile Internal Coach • Agile Community of Practice (ACoP) Sponsor • ACoP Facilitator
- 44. Agile is a Mindset 44
- 45. Which Role Fits You?
- 46. Questions
Editor's Notes
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- 11. We start with high level requirements that become more detailed as we learn more about the product we are building. We start with high level architectural representations that emerge toward detailed design as we actually begin developing the working product. You might think of this as rolling wave planning or progressive elaboration. The idea is that we plan based on what we know, and plan more as we learn more.
- We use this governance model which shows how teams collaborate through each of the 3 tiers. The model shows the development flow of value/work through the enterprise. We manage our work within in the tiers through four steps: Strategic Alignment, Solution Validation, Demand Planning & Release Commitment (Detailed Planning) and Measurable Progress (Execution & Accountability). The model is focused on continuous improvement by maximizing strategic alignment, increasing transparency and predictability, improving quality, reducing work, and minimizing delivery risk.
- Structure is made up of a 3 Tier Team Structure approach. The three main tiers of our Enterprise Transformation Model are Portfolio, Program and Delivery. Each tier manages the flow of work associated with delivering on the requirements of the product at the respective level of detail for their tier and in collaboration with the tier above/below it.
- This slide introduces some of the metrics that can be tracked at each of the team levels in order to ensure we are on the right track with our goals as an organization moving to/ adopting agile. Important to note that while these are suggested metrics to track, even more important is to ensure that the metrics being tracked are useful to the teams, and that they actually contribute to the teams’ continuous improvement goals. It is important to identify one or two metrics to start with, set goals for those metrics, then move on to or add other metrics. You should also be able to define each of these metrics and explain them. Delivery Team: Backlog Size: What is the size (in user story points, or whatever other measure your team uses to size backlog items) of the backlog sprint over sprint? Is it growing (meaning scope is increasing)? Is it steadily decreasing as we burn through items, or is it stalled? These are all indications of whether or not we are working through the backlog at a healthy pace, and/or whether we are getting a lot of change from stakeholders that needs to be accounted for in release dates, etc. Velocity: Mainly a metric for teams to track the amount of work they are able to take on in a sprint, velocity can be an indicator of whether teams should hold back or take on more work in upcoming sprints. It’s also a great tool for forecasting and achieving predictability with releases. Some anti-patterns to look for: Are there unforeseen development challenges we didn't account for when estimating work? How can we better break down work to uncover some of these challenges? Is there outside business pressure pushing the team beyond its limits? Is adherence to development best practices suffering as a result? As a team, are we overestimating our ability to take on work in the sprint? Burndown: The Sprint Burndown shows the amount of work the team is “burning through” or completing throughout the sprint. The x-axis represents time, and the y-axis refers to the amount of work left to complete, measured in either story points or hours. The goal is to have all the forecasted work completed by the end of the sprint. Some anti-patterns to look for: The team finishes early almost every sprint - they are potentially not committing to enough work. The team misses their forecasted delivery every sprint - potentially because they're committing to too much work. The burndown line makes steep drops rather than a more gradual burndown - stories may be too big and need to be split into smaller stories. The product owner frequently adds or changes the scope mid-sprint. Escaped Defects: # of defects that escaped the testing/ quality process and were included in a release. Commit % Ratio: This metric helps teams become predictable in their estimating and sprint planning. It encourages smaller stories and more effort getting work ready prior to the sprint. Ideally, teams are delivering somewhere within 10% of the commitment. Number of Committed Stories Delivered/ Number of Committed Stories Number of Committed Points Delivered/ Number of Committed Points Acceptance % Ratio: This metric helps us get a look into the quality of output, as well as the effectiveness of communication between product owners/ stakeholders, and teams. Number of Accepted Stories/ Number of Delivered Stories Scope Change: This metric measures the amount of change introduced into the backlog after we have started a sprint. Number of total stories (or points) at the end of the sprint/ Number of stories (or points) that were committed when the sprint started Product Owner Team: Cycle Time: This metric measures the total time from the beginning to the end of a process per unit of work. Cycle time includes actual processing (or work/ development time), as well as delay time, which is any time that a unit of work is sitting and waiting to be taken to the next action or step in the process. Features Blocked: The number of features that are blocked from moving forward because of technical or organizational dependencies or impediments. Rework/ Defects: The number of items that need to be reworked, or defects that need to be fixed, as a ratio of total items delivered. As you can guess, the goal of the product owner team is to reduce these three metrics, and increase the amount of value delivered to the customer per unit time. Portfolio Team: ROI/ Capitalization: These metrics measure the return on investment in product development, meaning how much of the investment in developing the product was then realized as profit. These metrics are important to the portfolio team as they help guide decisions regarding what products to continue to invest in, and where some investments might not have achieved the expected/ desired returns. Lead Time: Lead Time is total elapsed time for work, and equals Cycle Time * WIP. I.e., Lead time is equal to the amount of time it takes to process a unit of work * the amount of work we have in progress at any given moment. The shorter we can make lead time, the better for customers, since it means we are delivering value faster, and not having items wait in idle states before getting worked on or completed.
- By embracing the agile manifesto, managers have a guide and reference for decision making as well as the kinds of behaviors to reinforce within teams. The values and principles of the manifesto are a clear guideline for managers regardless of the specifics of the agile framework they are trying to implement.
- Scope Management Plan is often an informal agreement on what we’re going to do when scope needs to be adjusted, either because of an important opportunity, or because things are going poorly. It’s policy concerning whether release scope can be revisited each sprint, or not. Agree in advance how they might handle a certain risk. ---- Definition of Ready for initiatives (Ready to go onto the roadmap) Have a Sponsor or owner Have an Epic list Have a target deployment Have a Value Have a cost Tied to Capabilities Definition of Done for an Initiative All Epics are Deployed in production All Software Adoption work is complete Benefits can be realized.
- The Portfolio Team is responsible for setting the vision and strategy, deciding on initiatives in which to invest, and ensuring value is aligned with business strategies. The Portfolio Manager helps make sure that the team has everything it needs to function effectively. This goes beyond just scheduling recurring meetings. The Portfolio Manager can act as a servant leader, removing impediments, measuring progress, and enabling the team to make decisions on the portfolio. The Portfolio Manager is the facilitator for the team. They help keep the team accountable to adhering to processes and working agreements, as well as ensuring the team operates efficiently.
- Discussion: Agility is not a process, methodology or framework. Rather, it is a mindset. Agility is a different way of looking and and approaching things. There can be many ways to achieve agility within an organization, and rather than focus on the mechanics of the process, the most important things to focus on are the values and principles that make up the Agile Manifesto.