Project Management to Enterprise Agile Product Delivery

Editor's Notes

• #12: 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.  
• #13: 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.  
• #14: 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.  
• #15: 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.  
• #16: 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.  
• #17: 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.  
• #19: 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.  
• #20: 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.  
• #21: 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.  
• #22: 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.  
• #24: 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.
• #26: 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.
• #31: 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.
• #36: 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.
• #39: 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.
• #40: 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.
• #45: 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.