Pega Delivery Excellence Workshop Master slide set, January 2017

Pega Delivery Excellence Workshop Master slide set, January 2017

Read me first! This is the entire set of DEW slides – pick and choose the ones you want! DCO best practices and a discussion deck that describes how to use “do DCO” when using other Agile management tools are filed separately in the Mesh Have fun and share feedback!

Introductions Name Role What are your expectations for this workshop?

Delivery Excellence Workshop Overview
Pega 9/15/2018 7:02 PM Delivery Excellence Workshop Overview Goals Develop optimal blended implementation methodology that incorporates ConEd’s and Pega’s best practices Share best practices for successful project delivery Create a roadmap to promote agility Lay the foundation for a Center of Excellence

Delivery Excellence Workshop Overview
Pega 9/15/2018 7:02 PM Delivery Excellence Workshop Overview Activities and Deliverables Activities Review current implementation methodologies to understand what works and what doesn’t Take a deep dive into Pega’s best practices and processes Conduct working sessions to define a blended methodology incorporating process alignment, best practices, identified risks and assumptions, and allocation of resources Deliverables Defined blended methodology Phase and artifact mapping Governance approach This Delivery Excellence Workshop presentation

Agenda review

Setting the stage: Client challenges

Where are we challenged?
Pega Team Feedback What worked well? Where are we challenged? xx xx I normally record these comments on a whiteboard and insert a photo in the final deck COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Pega delivery methodology overview

Guiding Principles Iterate to Success Practice Co-Production
Pega 9/15/2018 7:02 PM Guiding Principles Iterate to Success Frequent business user playbacks Prove value early Right size each project Plan for a max 90 day first release followed by max 45 day subsequent releases Practice Co-Production Collaborative effort between business and IT to execute Empower business users through hands-on experience Leverage JIT role-based training Maximize Capabilities Fully leverage OOTB strategic application features Design for reuse Maximize use of Pega 7 Use DCO Implement with Best Practices Practice multi-level governance Proactively manage risk Manage application quality with tools Establish appropriate environments Focus on Outcomes

Styles of Implementations
Highly Adaptive Big Bang WATERFALL Iterative & Incremental ITERATIVE WATERFALL Agile SCRUM Ovals – represent release cycles as well as feedback loops In Waterfall feedback loops are very slow, if they exist at all; continuous delivery stresses on-going feedback from all involved (ops, mgrs, dev, admins) We work with any and all methodologies These are the two that we see most often Highly Prescriptive

Waterfall Plan Driven Sequential process in which progress is seen as flowing downwards through phases Process modeled based on building highly structured manufacturing & construction systems Structured model was adapted for software Applied structure and order to software development

Iterative Waterfall * Risk Minimization Systems built through repeated cycles (iterations) and in smaller portions (increments) Constant collaboration between business, IT, and end users Start with a simple implementation of the requirements and iteratively enhance them Begin construction as soon as possible in elaboration Test what you can as soon as you can Modify design at each iteration to add new functional capabilities * formerly known as “Pega BPM”

Scrum Change-Oriented Software development methods in which requirements and solutions evolve through collaboration of self-organizing, cross- functional teams Promotes adaptive planning, evolutionary development, early delivery, and continuous improvement Provides for co-production and active business end-user participation Encourages rapid and flexible response to change

Choosing Your Implementation Methodology
Iterative Waterfall vs. Scrum What’s different about Scrum? CHARACTERISTIC ITERATIVE WATERFALL SCRUM Planning / Execution Driven by plan Inspect and adapt (learning and innovation) Adaptation to Change Business requirements change, but not that rapidly Business requirements are rapidly changing Approach Step by step, iterative & incremental Freeform and laser-focused toward goal Scope Fixed for the project Variable and time-boxed to respond to changes in business requirements Estimates Up front and as precise as possible Generalized and flexible - dependent on team efficiency and velocity Iterations Variable, as needed to accomplish work Rapid release model: fixed, 2-4 weeks Artifacts Defined and template-oriented Minimum needed by team to deliver product Roles Well-defined and role-specific Skill-focused; team is self-managing and members play multiple roles Team size Sized as needed to complete given scope in specified time Small – no more than nine, no less than five

Initiate * * Same activities regardless of methodology Pega
9/15/2018 7:02 PM Initiate * Introduce methodologies at a high level to set the context for the DCO discussion * Same activities regardless of methodology

* Called Sprint 0 in Scrum
Initiate * Three Concurrent Activities Plan - Understand Strategic Application – or existing application - OOTB or reusable capabilities Set Up - Platform and Strategic Application installation and gap analysis Prepare – Refine and document approach and get ready to begin implementation INITIATE Establish environments Install software Load data Align vision and roadmap Define release milestones Refine scope alignment Confirm resources Enable team members Establish governance PLAN SETUP PREPARE * Called Sprint 0 in Scrum

Plan Activity Artifacts (*-Pega-generated)
Activities & artifacts Activity Artifacts (*-Pega-generated) Review the organization’s vision and roadmap for the engagement Vision / Project Charter Refine scope and define release milestones Application profile Confirm estimate and high-level delivery plan Program / project delivery plan Refine and backlog / use case inventory Pega and / or Scrum management tool Create iteration / release schedule Project management tool

Pega Plan Best Practices Perform gap analysis using Strategic Application or existing applications Understand current (“as-is”) business operations Identify opportunities for improvement Examine reusable asset inventory and apply existing assets to solution Create specifications that fill the gaps and estimate effort at high level COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Plan Best practice: focus on business Objectives/outcomes Business Outcomes are clear, specific, measurable descriptions of the future end states to be achieved in business-as-usual (BAU). They define exactly how the business will be when the changes have been implemented, adopted, and everything is working ‘just right’. “We invoice all service calls within 24 hours of completion in order to reduce the level of unbilled service calls and the work associated addressing customer questions about late bills.” “We will automate our customer service center in order to reduce time spent resolving dispute cases by 25% and reduce customer complaints by 30%.” When the business has delivered these outcomes, the associated benefits can be realized and the new, operational BAU will be achieved

Plan Best Practices: business outcomes, continued Establish and share business outcomes: connect project to overall company strategy and objectives so that executives see the value Create plan for sharing business outcomes and measures throughout the implementation Be evangelists: weave business outcomes into every conversation that the project and governance teams have about the product

Set Up Activity Artifacts (*-Pega-generated) activities
Install Pega Platform Installation guide Establish UI Standards Style guides, UI best practices Define Security Model (Security and Org Structure) Authentication and authorization schemes, organizational structure, operator attributes Review architecture, application foundation, and enterprise organization/class structure Pega Enterprise Class Structure * Set up defect tracking tool with users, products, delivery calendar, and other administrative items Defect tracking tool ready to use Define performance model and set up performance testing environment Performance testing environment

Set Up Follow the Pega or Strategic Application Implementation guide
Best Practices Follow the Pega or Strategic Application Implementation guide Establish a data model and acquire customer data as soon as possible Allows business to better envision solution using realistic data Provide requirements and sizing for environment as early as possible Confirm UI standards as early as possible

Prepare Activity Artifacts (*-Pega-generated) Confirm resources N/A
activities & artifacts Activity Artifacts (*-Pega-generated) Confirm resources N/A Review sales demos, Proofs of Concept (POCs) and existing applications to identify OOTB or reusable capabilities and customizations Specifications and requirements * Perform Pega Delivery Excellence Workshop (DEW) and confirm the methodology Blended methodology approach Enable team members Methodology Training, Pega Academy Establish project governance model Governance decks and status reports Conduct project kickoff Kick Off Deck

Prepare What does it mean? Why do we do it?
Pega Prepare Best Practices: co-production What does it mean? Why do we do it? Active, meaningful business end- user participation “Doing DCO” during elaboration or assisting with application configuration UI development Process flows Business logic Leading playbacks Assisting with testing: both QA and hands-on, informal UAT role Speeds adoption when users evangelize solution Maximizes investment in enablement when user training paired with direct contribution during delivery Faster realization of ROI for projects and programs COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Prepare Best Practices: co-production Engage key Pega resources (Lead and other Business and System Architects); ensure that all resources are certified and fully enabled for their role Plan to co-produce your application: partner experienced Pega resources with new teammates to speed knowledge transfer Consider pair programming, or pairing a manual tester with an automated tester Ensure that business end-users or their representatives can partner with team to ensure quality

Iterative waterfall deep dive
Pega 9/15/2018 7:02 PM Iterative waterfall deep dive Introduce methodologies at a high level to set the context for the DCO discussion

Iterative Waterfall Methodology
Pega 9/15/2018 7:02 PM Iterative Waterfall Methodology INITIATE ITERATIVE WATERFALL DELIVERY F I R S T P R O D U C T I O N R E L E A S E PLAN TRANSITION GO LIVE ELABORATION CONSTRUCTION INCEPTION Align vision and roadmap Define release milestones Refine scope alignment E X T E N D E D P R O D U C T I O N R E L E A S E S SETUP Establish environments Install software Load data OOTB functionality Integration with customer systems First Production Target Extend OOTB Unique customer functionality Extended Production Releases PREPARE Confirm resources Enable team members Establish governance DCO Co-Production Governance Continuous Testing

* Called Sprint 0 in Scrum
Initiate * Three Concurrent Activities Plan - Understand Strategic Application – or existing application - OOTB or reusable capabilities Set Up - Platform and Strategic Application installation and gap analysis Prepare – Refine and document approach and get ready to begin implementation INITIATE Establish environments Install software Load data Align vision and roadmap Define release milestones Refine scope alignment Confirm resources Enable team members Establish governance PLAN SETUP PREPARE * Called Sprint 0 in Scrum

Delivery Inception Elaboration / Construction Transition Go-Live
Four phases Inception Elaboration / Construction Transition Go-Live

Iterative waterfall: A deep dive

Iterative Waterfall Methodology
Pega 9/15/2018 7:02 PM Iterative Waterfall Methodology INITIATE ITERATIVE WATERFALL DELIVERY F I R S T P R O D U C T I O N R E L E A S E PLAN TRANSITION GO LIVE ELABORATION CONSTRUCTION INCEPTION Align vision and roadmap Define release milestones Refine scope alignment E X T E N D E D P R O D U C T I O N R E L E A S E S SETUP Establish environments Install software Load data OOTB functionality Integration with customer systems First Production Target Extend OOTB Unique customer functionality Extended Production Releases PREPARE Confirm resources Enable team members Establish governance DCO Co-Production Governance Continuous Testing

Delivery Inception Elaboration / Construction Transition Go-Live
Four phases Inception Elaboration / Construction Transition Go-Live

inception

Delivery: Inception objectives Create high-level scope for an individual project or sliver Ensure that project participants understand proposed solution Confirm candidate architecture, application foundation, and enterprise class structure Verify that project team is in place and prepared to start the project Prepare for elaboration sessions We have already talked about this…

Delivery: Inception Activities and artifacts Activities
Artifacts (*-Pega-generated) Conduct Inception Kick Off Kick Off Presentation Refine foundational cases and stages and confirm end-to-end process Foundational cases and stages in Pega and Strategic Application Review and confirm scoping data (requirements, specifications, interfaces, actors, etc.) Application Profile and Specification documents * Generate automated sizing (effort estimation) Application sizing (effort estimate) and project plan * Create testing strategy Test strategy Perform phase readiness assessment Phase readiness assessment Compile Inception-based Use Case Inventory Use case inventory Create and distribute elaboration schedule Elaboration schedule

Delivery: Inception tools Environment used to capture the high-level business process, objectives, requirements, and specifications for scoping and documentation Pega Helps provide a budgetary estimate of the effort for Pega projects during the early planning phases Application Effort Sizing Tool Automated document that describes the scope of the program/projects at a high level Application Profile Document Checklist to ensure the team is ready to move to the next phase Phase Readiness Checklist

Delivery: Inception Use Pega tools to help with high level planning
9/15/2018 7:02 PM Delivery: Inception Best practices: planning Use Pega tools to help with high level planning Application document for high level artifacts Application sizing tool for high level estimate Create small slivers for early “wins” and to help identify potential environmental or process issues Include integration (if possible) in early slivers: if team discovers issues with those interfaces, can use lessons learned to speed and ease remaining integration work Reuse assets that have already been built to speed implementation Reusable assets have already been tested, so saves effort from requirements gathering all the way through transition

Pega Delivery: Inception Best Practices: requirements gathering Create a naming convention to help organize specifications and requirements Capture the business needs in the form of business requirements Create high level specifications that document what it will take to meet the business requirements Create stage-based work flows to present business processes COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Pega Delivery: Inception Best Practices: requirements gathering, continued Rather than build a fully functional, production-ready application, only define: High level business stages High level steps High level specifications Requirements / business rules Only capture enough information to understand and define the scope and relative level of effort required to deliver the scope Go FAR ENOUGH but not TOO FAR COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Delivery: Inception What does it mean to go FAR ENOUGH?
Pega Delivery: Inception Best Practices: requirements gathering, continued What does it mean to go FAR ENOUGH? You have what you need to determine the scope and estimated effort Your requirements adequately represent the business needs Your specifications contain multiple line descriptions (not a single sentence) You have defined stages in your business process You have defined high-level steps for the process stages You have reviewed your reuse potential What does it mean to go TOO FAR? You are building screens, Pega flows, activities, interfaces, etc. Your specification detail is 100% complete COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Pega 9/15/2018 7:02 PM Delivery: Inception Implementing a Co-Production Model: Sample Activities by phase Phase Activity Inception Appoint co-production champion Draft enablement plan and measurements Elaboration / Construction Formalize enablement plan Draft end user training plan Users lead elaboration sessions Users participate in application configuration by creating screens, Pega flows, decision logic Users host formal playback sessions with support from delivery team Transition Users work with trainers to finalize end user guide Users partner with trainers to deliver training Users participate in user acceptance training and system verification before go-live Just a reminder…

Elaboration / construction

Delivery: Elaboration / Construction
objectives Execute an incremental and iterative plan for analysis and build Extend Inception artifacts into production quality components Design, construct, and unit test a working application, including UI, reports, correspondence, data connectors, and interfaces Ensure application quality by using DCO capabilities and Pega best practices Recap TRANSITION GO LIVE ELABORATION CONSTRUCTION INCEPTION

Activities and artifacts Activities Artifacts (*-Pega-generated) Complete set up of QA and Transition environments NA Organize the work effort into manageable components Iteration-based project and elaboration session / playback plan Plan and execute elaboration sessions to capture application details Specification document and application document* Refine initial effort estimate Application document and sizing* Design, build, and unit test Detailed application document* Create QA test plan and scripts Test plans and scripts Complete end user training plan Training plan Perform a phase review Phase readiness assessment* Plan Transition and Go-Live

tools Environment used to capture the high-level business process, objectives, requirements, and specifications Pega Documents the current state of the Pega application Application Documentation Wizard Built-in application quality tools like guardrail compliance measures, alerts, warnings, PAL, UI Inspector Technical Governance Tools Checklist to guide users on Pega best practices for phase transitional tasks Phase Readiness Checklist

Best practices: iterations Execute an incremental and iterative plan for analysis and build Organize the in-scope specifications into logical units of effort which can be iterated until they are production ready Organize the work product into release packages that can potentially go into production Keep the global architecture of the system in mind while developing smaller iterations Focus on core functionality, and deliver it as quickly as possible Use OOTB capabilities or reusable assets to reduce implementation, testing, and support effort Integrate testing throughout the life-cycle

Best practices: unit testing Use test-driven development for unit tests Focus on what the code must do before how to write the code Write tests first, then write the code needed to pass the tests Results in simple, testable code with fewer defects Involve business resources in validating unit tests

Pega Delivery: Elaboration / Construction Best Practices: application governance Create a governance model to enforce technical best practices Ensure alerts, warnings, and other best practices are inspected and addressed regularly Governance tools and capabilities are available on the landing page for easy access Monitor application quality governance model during the build lifecycle with an eye toward usability and support COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Best practices: application governance, continued Guardrail compliance dashboard included in Pega7 Compliance score from 1 to 100 covers all rules in the current application Indicates the project’s technical health Review continuously and share with project governance team

Best practices: application governance, continued Compliance Score trend reporting in Pega7 Project stakeholders can see an application’s compliance score over time to better understand and manage ongoing development against Pega 7 guardrails

Best practices: business outcomes Measure and share business outcomes established in Inception Be evangelists: weave business outcomes into every conversation that the project and governance teams have about the product

Best Practices: getting help, or getting even better Engage Pega Consulting for: Methodology assessments Application health checks Design reviews Decisioning maturity assessments UI reviews Performance reviews CoE maturity assessments

Pega 9/15/2018 7:02 PM Delivery: Elaboration / Construction Implementing a Co-Production Model: Sample Activities by phase Phase Activity Inception Appoint co-production champion Draft enablement plan and measurements Elaboration / Construction Formalize enablement plan Draft end user training plan Users lead elaboration sessions Users participate in application configuration by creating screens, Pega flows, decision logic Users host formal playback sessions with support from delivery team Transition Users work with trainers to finalize end user guide Users partner with trainers to deliver training Users participate in user acceptance training and system verification before go-live

transition

Delivery: Transition objectives Ensure that product meets business objectives, specifications, and requirements Complete final testing and obtain final user acceptance Establish training plan Verify that system performs well and can be monitored and maintained Execute production support model Verify that deployment and maintenance plans are in place TRANSITION GO LIVE ELABORATION CONSTRUCTION INCEPTION

Delivery: Transition Activities and Artifacts Activities
Artifacts (*-Pega-generated) Create the production deployment plan Deployment plan and playbook Conduct testing (QA, system integration, user acceptance, performance, other) Test scripts for each Execute an application governance model to monitor Compliance dashboard (alert logs, guardrails, system warnings) * Create maintenance plan Maintenance plan Create end user guide; execute training and rollout plan End user guide, training and rollout plan Train maintenance and “business as usual” (BAU) support teams BAU governance model, responsibility matrix, support processes, and SLAs Develop backup and recovery procedures Backup and recovery procedures Ensure that business outcomes align with product vision, and that the system can fulfill them Business outcomes and measures

Delivery: Transition Tools Environment used to capture the business processes, objectives, requirements, and specifications Pega Platform Manage and track defects and issues Defect Tracking System Checklist to guide users on Pega best practices for phase transition tasks Phase Readiness Checklist PAL, SMA, Tracer, DBTrace, alerts log, Verbose GC, LoadRunner Performance Tools

Pega Delivery: Transition Best Practices Be as agile as possible: test what you can as soon as you can Testers should review application well before QA starts to reduce the number of defects found during testing Perform boundary / exception testing and incorporate scenarios and scripts into the user acceptance test suites Conduct smoke testing after each migration to ensure that no application components were left out of the migration Conduct performance testing to ensure compliance with guardrails, performance, and load testing standards Conduct usability testing to evaluate human factors Monitor expected business outcomes established in Inception COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Pega 9/15/2018 7:02 PM Delivery: Transition Implementing a Co-Production Model: Sample Activities by phase Phase Activity Inception Appoint co-production champion Draft enablement plan and measurements Elaboration / Construction Formalize enablement plan Draft end user training plan Users lead elaboration sessions Users participate in application configuration by creating screens, Pega flows, decision logic Users host formal playback sessions with support from delivery team Transition Users work with trainers to finalize end user guide Users partner with trainers to deliver training Users participate in user acceptance training and system verification before go-live

roles in iterative waterfall
Pega 9/15/2018 7:02 PM roles in iterative waterfall

Initiate Key Roles and Responsibilities Role Responsibility
Business Sponsors Business solution and project owners Process or Product Owner Represents the business and serves as a single point of contact for business decisions SMEs Process experts and Process Owner support Project Manager Begin preparing program and project plans and contribute to roadmap Lead Business Architect Assess reuse, write high-level specifications, and support estimation Lead System Architect Assess reuse, and support estimation Track Lead Facilitate scope discussions between SMEs and Pega team Deployment Architect (often Pega) Pega7 installation System Administrators Strategic Application installation, configuration, and smoke testing

Delivery: Inception Key Roles and Responsibilities Role Responsibility
Pega 9/15/2018 7:02 PM Delivery: Inception Key Roles and Responsibilities Role Responsibility Business Sponsors Business ownership, governance participation, escalations Process Owner Business Architect support and decision making Project Manager Scope and plan project Lead Business Architect High-level artifact capture Lead System Architect High-level Pega application design Track Lead Manage inception progress, provide solution guidance Test Lead Understand Pega application design and draft test plans SMEs Process experts and Process Owner support Organizational change management team Identify readiness issues, draft training materials, adoption plans, and organizational change management plans

Key Roles & responsibilities Role Responsibility Business Sponsors Business ownership Process Owner Business Architect support and decision making Project Manager Monitor project progress against plan, risk and issue management, lead governance activities Lead Business Architect Refine specifications, requirements, stages, and steps to construction-ready level of detail Lead System Architect Pega application design, lead developer Senior System Architect Construct and unit test application Track Lead Manage elaboration progress, provide solution guidance QA Tester Test application and collaborate with BAs and SAs to ensure that designs are testable SMEs Process experts and Process Owner support Organizational change management team Identify readiness issues, refine training materials, adoption plans, and organizational change management plans

Delivery: Transition Key Roles and Responsibilities Role
Responsibility Business Sponsors Accept the production-ready application Project Manager Ensure solution success Lead System Architect Ensure application is successfully migrated to production Lead Business Architect Defect triage System Architects Address defects Track Lead Assist with testing and test validation, manage defects, update specifications QA Lead Quality acceptance of the application UA Testers User acceptance testing Performance Testing Lead Performance testing Integration Testing Lead Integration testing Organizational change management team Conduct training, address readiness issues, enact adoption and organizational change management plans

A deep dive into Scrum * * with Pega’s “special sauce”

Show of hands… How many of you are familiar with the basic Scrum concepts? 3 roles 3 artifacts 4 ceremonies

Also, “we prefer ATTITUDE over APTITUDE”
The Agile Manifesto Framework for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Client collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more Also, “we prefer ATTITUDE over APTITUDE” from Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Ilan Goldstein, 2013)

Scrum Framework Overview
scrum is simple A product owner creates a prioritized wish list called a product backlog During sprint planning, the team pulls a small chunk from the top of that wish list, puts it in a sprint backlog, and decides how to implement The team has a certain amount of time - a sprint (usually two to four weeks) - to complete its work, and meets each day to assess progress (daily Scrum) Along the way, the Scrum Master keeps the team focused on its goal At the end of the sprint, the work should be potentially shippable or able to be shown to a stakeholder The sprint ends with a sprint review and retrospective As the next sprint begins, the team chooses another chunk from the top of the list and the process begins again

General Principles Scrum’s theme is “Inspect and Adapt” Since development involves learning, innovation, and surprises, Scrum emphasizes Taking short steps in development Inspecting both the resulting product and the efficiency of current practices Adapting to product goals Examples of “Inspect and Adapt” Sprint planning Sprint execution via self-organizing teams Playbacks Reviews and retrospectives (lessons learned)

General Principles It’s all about the sprint An amount of time - usually two to four weeks - to complete user stories Time-boxed: a sprint’s length is not extended Team commits to delivering user stories that represent a potentially shippable product at end of sprint

General Principles Determine optimal sprint length
Some guidance about sprint length Determine optimal sprint length Longer duration – such as 4 weeks - enables more momentum Shorter duration – such as 2 weeks - simplifies planning, but required events (planning, review, retrospective) occur more often Consider requirement volatility – shorter sprints may work best if high likelihood of requirements change Recommend 3 week sprints to start Keep sprint length constant Changes to sprint length increase logistical and administrative burden for scheduling events, establishing activity cadence, etc. Changing sprint lengths make velocity unreliable

Scrum Principles Change-Oriented Software development methods in which requirements and solutions evolve through collaboration of self-organizing, cross- functional teams Promotes adaptive planning, evolutionary development, early delivery, and continuous improvement Provides for co-production and active business end-user participation Encourages rapid and flexible response to change

Scrum Framework SCRUM DELIVERY INITIATE/SPRINT 0 PLAN SET UP PREPARE
Pega 9/15/2018 7:02 PM Scrum Framework INITIATE/SPRINT 0 SCRUM DELIVERY PLAN First Production Release OOTB functionality Integration with customer systems Extended Feature Release(s) 1-N Extend OOTB features Unique customer functionality Align vision and roadmap Define release milestones Refine scope alignment Sprint 1.a Sprint 1.b Sprint 1.z First Production Release SET UP Sprint 2.a Sprint 2.b Sprint 2.c Sprint 2.z Establish environments Install software Load data Sprint 3.a Sprint 3.b Sprint 3.c Sprint 3.z Remember that the Initiate phase is the same, regardless of methodology Sprints 2-4 week cycles Prioritized scope Frequent playbacks Continuous grooming Sprint Z Application hardening Testing Deployment PREPARE Extended Feature Releases Confirm resources Enable team members Establish governance DCO Co-Production Governance Continuous Testing

Scrum with Pega Introduction
9/15/2018 7:02 PM Scrum with Pega Introduction What does “with Pega” mean? Scrum with Pega: Leverages Scrum best practices: it does not change standard Scrum Augments Scrum by supporting sprint management tools Pega’s Project Management Framework, Rally, Jira, Version One, others Applies techniques to make delivery more effective and efficient Direct Capture of Objectives (DCO) Processes, such as Project Initiation and Inception Best practices such as grooming sessions and playbacks using Pega tools Pega automated development tools (flows, UI, document generation, sizing) So… what’s different about scrum with Pega?

Roles Artifacts Ceremonies
Scrum Master Product Owner Team Artifacts Product backlog Sprint backlog Increment Ceremonies Sprint planning Daily scrum Sprint review Sprint retrospective

Roles Create and manage tasks based on the staffing model
Pega 9/15/2018 7:02 PM Roles Primary Roles Product Owner Scrum Master Team members Extended Team Users Stakeholders Key Behaviors Self-organizing: Each person decides what they will do or how they will do it. They resolve issues as a team. Cross-functional: Team composed of people with diverse skills. Everyone participates. Select people based on qualities, rather than qualifications Ideally, co-locate Scrum Master, Team, and Product Owner Create and manage tasks based on the staffing model If offshore of offsite resources, may create more granular tasks (e.g., verify ready for offshore QA)

Roles: Product Owner Represents the business and serves as a single point of contact for business decisions Manages product backlog Sets stakeholder expectations Sets priorities for the Scrum team’s work Answers questions from the Scrum team and clarifies details Accepts or rejects user story completion

Roles: Scrum Master Agile coach that serves the team by
Removing impediments that prevent the team from making progress Protecting the team from outside interference Mentors the team on the Scrum process Helps to coordinate the Scrum team and outside resources Not a team or project manager

Roles: Scrum Team A multi-disciplined team with the skills (development, testing, documentation…) needed to complete the work Self-organizing and self-managing: while Product Owner sets priorities, the team plans and completes the work Collaboration maximized when team size is between five and nine resources Combine smaller teams Split larger teams

Roles: The Tester Role on Scrum Team
Testing is everyone’s responsibility in Scrum Encourage specialized “consultant, designer, and explorer” * mindset for QA role Help non-testers understand test-driven development Help user experience designers anticipate issues with complex workflows Consider “pair testing” to encourage skills transfer Look to the future: create QA tests that serve as input into technical design for future sprints Conduct exploratory tests to recognize problems that automated testing tools will not address Think about what the novice or expert user would do when using the system * Scrum Shortcuts without Cutting Corners: Agile Tactics, Tools, & Tips (Goldstein, 2013)

Roles: Participation across phases
Pega 9/15/2018 7:02 PM Roles: Participation across phases Planning Sprint 1-N Sprint Z / Hardening Go-Live Project Manager Project selection, Gathers objectives, requirements, Kick-off Manages team assembly, env setup, release plans, scope & sprint readiness Manages budgets, timelines, status reporting, coordinates x-team availability and dependencies, mitigates risks, continuous improvement task owner Facilitates test prep & execution – environment, test data, scripts, etc. Facilitates deployment and production rollout, defect management Scrum Master Facilitates backlog grooming, DoD creation Facilitates sprint planning, daily touchpoints, sprint demos, retrospectives, escalations, impediment and dependency resolution, burn-down tracking Facilitates defect resolution Product Owner Identifies Key Solution Features and Priority, Release Planning Drives product backlog creation, prioritization, scope decisions, DoD creation Continues product backlog refinement, provides feedback and decisions on dev playbacks, sprint reviews and acceptance of work per DoD Prioritizes defects, oversees validation, drives acceptance Drives end user training, adoption, defect prioritization Team member: LBA / BA Assist PO with backlog refinement, Pega expertise, sprint 1 readiness Dedicates 50% to supporting development Dedicates 50% to backlog refinement for next sprint Supports solution validation, playbacks, improvements Support defect triage Support test/validations Support training plans Support production rollout as needed Team member: LSA / SA Establish solution design Pega expertise, env setup, estimations, DoD creation Communicate task breakdown, implement solution, Incorporates UX & early feedback, maximizes reuse, performance, dedicates 75% dev : 25% next iteration Resolve defects Documents design Assist w/ code migration Team member: Tester Define test scenarios Estimations, DoD creation Prepare test env, execute test scenarios, provide early feedback, triage and prioritize defects Execute UAT & performance testing Business SMEs Influence requirements definition, be available Support product backlog refinement, shape requirements, provide active feedback, clarifications Assist testing efforts, acceptance and training Assist with end user training, adoption, defects Technical SMEs Influence technical design, support integration efforts Support technical design, databases and system integrations, performance considerations & testing Support load testing, data migration, deployments Supports production rollout and escalations Stakeholder Scrum multi-disciplined Core Team Scrum Dedicated Role Scrum Extended Team Member

Roles: Stakeholders and Extended Team
Have interest in the work product of the team Help the team maintain focus on the goals and needs of the business Attend product demonstrations to influence product direction Extended team Directly supports or is affected by the work Helps coordinate development dependencies Don’t forget about the users!

Pega 9/15/2018 7:02 PM Roles: Best Practices Select people based on qualities, rather than qualifications Ideally, co-locate Scrum Master, Team, and Product Owner Keep team consistent from sprint to sprint (and project to project) for continuous improvement Create and manage tasks based on the staffing model If offshore of offsite resources, may create more granular tasks (e.g., verify ready for offshore QA)

Open discussion about scrum roles

Artifacts Building blocks Product backlog Sprint backlog Increment
Epics and user stories Technical user stories Acceptance criteria Product backlog Sprint backlog Increment When we “do DCO” we enter these artifacts in Pega and benefit from: Full traceability Reuse Enhanced collaboration Work automation Speedy playbacks to ensure quality Roles Scrum Master Product Owner Team Artifacts Product backlog Sprint backlog Increment Ceremonies Sprint planning Daily scrum Sprint review Sprint retrospective

Building Blocks Epics and User Stories Epics and user stories are specifications that contain a description of a business capability proposed for construction Epics are user stories that are too large to be executed within a single sprint and often represent complex business processes User stories are granular, and along with Acceptance Criteria are designed to deliver clear and measurable business value Fixed structure: As an <<ACTOR>> I want <<DESCRIBE CAPABILITY>> so that <<VALUE>> Example epic: As an auto mechanic, I want to order parts online when I need them, so I can reduce inventory costs and save time driving to the store. Example user story: As an auto mechanic, I want to manage shipping addresses for the items in my shopping cart so I can send the right item to the right location.

Building Blocks User story examples As a customer, I can enter all necessary information in a single screen, so that I can see all the data at once. As a customer, I can access basic account information while working on the screen, so that I do not have to leave the screen. As a customer, I can start a chat session with a customer representative if there are issues or questions while entering data, so that my questions are in context.

Building Blocks User story & Acceptance criteria Pega
9/15/2018 7:02 PM Building Blocks User story & Acceptance criteria

Building Blocks Acceptance criteria sample (Epic level) Pega
9/15/2018 7:02 PM Building Blocks Acceptance criteria sample (Epic level)

Building Blocks Acceptance criteria sample (story level) Pega
9/15/2018 7:02 PM Building Blocks Acceptance criteria sample (story level)

Acceptance criteria not shown – see upcoming slides
Pega 9/15/2018 7:02 PM Building Blocks User story sample, using use case format Acceptance criteria not shown – see upcoming slides

Building Blocks User story sample, using use case format (continued)

Building Blocks Describes a technically-focused capability
Technical User Story Describes a technically-focused capability If stated in a user story would say “as a DEVELOPER I need to” …. Examples Integration Database creation Prototype Architecture Bug fixing Spikes (research)

Building Blocks Acceptance Criteria “Conditions of satisfaction” that accompany user stories Must be met for the Product Owner to affirm that the user story is complete Created by the Product Owner during backlog grooming Examples from auto parts ordering story: I can ship to US addresses I cannot ship overseas I can ship via FedEx and UPS, but not USPS I can view up to 20 addresses I can select a default address

Building Blocks User Story & acceptance criteria samples Name
Description Acceptance Criteria Design Reviews As a user of self service portal, I want to create a Design review request so that BPM CoE can review the design and approve it. Requestor is successfully able to create a Design Review request. Request is routed to correct Work Basket Send feedback back to the Requestor Requestor should be able to close the request after incorporating the review comments. notification is sent to right recipients at every stage of the process. Database Change Requests As a user of self service portal, I want to create a DB Change Request so that BPM CoE can review and route it to IPC team Requestor is successfully able to create a DB Change request. After approval of request, Request should be send to IPC team

Product Backlog Sets the stage for the sprint Prioritized list of high-level requirements and requested features in the form of epics and user stories Owned and managed by Product Owner Entered and tracked using sprint management tools The team selects user stories from the product backlog to work on during a sprint

Sprint Backlog User stories targeted for completion during a sprint
Where the sprint begins User stories targeted for completion during a sprint The entire team commits to the stories Scope is locked: the team can not remove user stories during a sprint

Sprint Backlog Scrum board Burndown chart
Tracking Sprint Progress Scrum board Can be manual (sticky notes on a wall) or automated Team members responsible for daily updates Burndown chart Demonstrates the progress of a sprint over time Shows story points or hours depending on the type Backlog burn-down chart is in story points Effort burn-down chart is in hours

Increment At completion of sprint The sum of all the Product Backlog items completed during a sprint and the value of the increments of all previous sprints At the end of a Sprint, the new Increment must be “done,” which means it must be in usable condition and meet the Scrum Team’s definition of “done” (discussed later) Must be in usable condition regardless of whether the Product Owner decides to actually release it Source: The Scrum Guide, 2013 (available electronically)

Ceremonies Sprint planning Daily Scrum Playbacks Review Retrospective
Recommended Ceremonies Sprint planning Daily Scrum Playbacks Review Retrospective “Doing DCO” allows us to play our solution back to the PO and stakeholders quickly and easily – and make changes “on the fly” - since we design and build in the same tool Roles Scrum Master Product Owner Team Artifacts Product backlog Sprint backlog Increment Ceremonies Sprint planning Daily scrum Sprint review Sprint retrospective

Building Block: Product Backlog Grooming
Key activities Write user stories (continuously or during one or more sessions) Break down epics, or user stories that are too big to implement during a sprint Improve user stories that are poorly written Estimate backlog items Add acceptance criteria Groom stories continuously Host frequent product backlog grooming sessions throughout the sprint Product Owner should have ~2 sprints’ worth of stories ready to review before the start of each sprint

Source: Google images

Two Models Integrated Sprint team conducts backlog grooming sessions during sprint; usually two hours per week of sprint Goal: have at least two sprints of user stories groomed by end of each sprint Staggered Backlog team conducts grooming sprints ahead of implementation sprints Ensures high quality user stories ready for sprint planning Time commitment 80% - Staggered team grooms backlog 20% - Staggered team supports implementation

Sprint Planning Begins with a product backlog review
overview Begins with a product backlog review Time-boxed to two hours x number of weeks in the sprint Includes an agreement on how to capture details in Pega and Scrum management tool Objective: Scrum Team understands what the business wants, and why Attendees: Product Owner, Scrum Master, Scrum Team

Sprint Planning Key Activities Product Owner and Team review user stories in product backlog that are targeted for the sprint Product Owner and Team agrees to a “definition of done” (DoD) for the sprint The Team determines what they can accomplish during the sprint by Determining resource capacity for each team member Assessing probable velocity Estimating story points The Team decides what work to take on – the Product Owner doesn’t tell them

Sprint Planning Estimation: Story Points An abstract point system that represents relative user story complexity Relative complexity allows estimating effort without assigning actual hours Common systems of user story scale Linear (1,2,3,4...) Fibonacci (1,2,3,5,8,13,21,34...) Powers of 2 (1,2,4,8...) Clothes size (XS, S, M, L, XL…) Not intended to reflect hours of effort

Sprint Planning Estimation: Velocity Rate at which a Scrum Team completes work within a sprint Measured in story points (more on this later) Unique for each team Helps team predict how much work they can complete within a sprint Benchmark for improvement goals

Sprint Planning Team velocity (historic) = 52 points
PRPC 5.4 Sprint Planning Estimation: using Story points and velocity Team velocity (historic) = 52 points Team selects stories from the backlog to create a “target” during sprint planning +20 = 58 * 4 Priority +13 = 51 5 = 38 3 2 1 Product Backlog User Story 5 20 User Story 4 40 User Story 3 User Story 2 13 User Story 6 User Story 1 User Story 7 7 6 Story Pts Detail 38 points 58 points 51 points * could also be broken into smaller stories COMPANY CONFIDENTIAL AND PROPRIETARY INFORMATION — DUPLICATION IS PROHIBITED

Sprint Planning Estimation: Planning Poker Product Owner presents a story and attendees discuss details Team members vote on the story using numbered cards Values on cards represent the number of story points Estimates are private until each participant has chosen a card

Sprint Planning Estimation: Planning Poker, continued All team members revealed their estimates and discuss them Someone (can be anyone!) records estimates in Scrum management tool after team gets consensus

Sprint Planning Creating tasks The team assigns tasks to user stories and estimates hours Team members volunteer for tasks Any resource can enter tasks into the Scrum management tool

Sprint Planning Estimation: Velocity Rate at which a Scrum Team completes work within a sprint Measured in story points (more on this later) Unique for each team Helps team predict how much work they can complete within a sprint Benchmark for improvement goals

Daily Scrum Daily Scrum (for each team) Scrum of Scrums
AKA “Stand up” Daily Scrum (for each team) Occurs every day of the sprint at the same time and place Time-boxed to 15 minutes Inspect the previous day’s work and discuss today’s work using three questions: What did you do since our last meeting? What are you going to accomplish today? Are you experiencing any blockers (impediments)? Scrum of Scrums Identify impediments that affect cross-functional teams Focus on areas of overlap and integration A designated person from each Scrum team attends

Daily Scrum Display task board
Best practices Display task board Helps ensure that task board is up to date Enhances participation by remote teams Consider an additional question: “Have you learned anything that the team should know about?” Expose problems to allow improvement, but control tendency to work issues during the meeting Track impediments At end of release, can appreciate all of the things that the project participants had to navigate Can serve as input to risk assessments for future projects

Playback Sessions Informal and formal Conduct informal “show and tells” as early as possible Review application with the business to ensure that the team is headed in the right direction Reduces risk of missed requirements and number of issues found in testing Does not require a lot of preparation! Host formal playback sessions at least weekly Goal: get acceptance and conclude development on a set of specifications Increases likelihood of acceptance by end users Run the process in draft mode – OK to use dummy data

Product Owner Acceptance
Pega 9/15/2018 7:02 PM Playback Sessions Recommendations for success Product Owner Acceptance End of Sprint Demo Use DCO: make changes directly into Pega in real- or near-real time to demonstrate how quickly changes can be made Manage change: At end of session, ask PO to affirm that he/she accepts the story Set the context for stakeholders by connecting the content to the overall business process or the iteration’s scope Demonstrate changes made since previous playbacks Manage change: Set expectations for attendees re: how stakeholders should provide feedback, and how the PO will prioritize it The team only takes action on priorities set by the PO – they do not necessarily address all stakeholder feedback

Sprint Review Inspect and adapt An “inspect and adapt” activity for the product that occurs at the end of sprint The Team and Product Owner inspect what was done during the Sprint, discuss the work, and determine what to do next Serves as an input into the next sprint’s planning Team presents the Increment by demonstrating the software built during the sprint to elicit feedback and foster conversation and collaboration Meeting not limited to the Product Owner, Scrum Master, and Team: audience is all interested parties

Sprint Review Manage attendee expectations
Best Practices Manage attendee expectations Share agenda in advance, especially if work product is technical foundation and no UI is available Ask a user to demonstrate the product, to show how easy it is to use Set the context by connecting the work product to the overall business process or release scope Don’t show work that hasn’t met the definition of done: say it’s “coming soon” Control change: the development team should only implement feedback originating with – or agreed by - the Product Owner Set expectations for attendees re: how non-decision makers should provide feedback Enter feedback into product backlog in the form of user stories and prioritize the stories Discuss chronic or systemic impediments encountered during the sprint to lobby stakeholders for assistance

Sprint Retrospective Follows the sprint review
Inspect and adapt Follows the sprint review Team discusses activities for continuous improvement What went well / what should we continue to do? What could be improved / what should we start doing? What should we stop doing? Meeting between the Scrum Master and team; Product Owner is optional

Sprint Retrospective Best practices Scrum uncovers things: what the team does with what they learn demonstrates how well Scrum will work “Scrum is not a silver bullet; Scrum is a silver mirror!” – Mike Dwyer, Scrum Coach Examples: Daily stand-ups take up too much time, so we will only host them weekly Retrospectives don’t uncover new information, so let’s omit them Not testing until development complete Focus on solving the problem rather than changing processes Take full advantage of learnings, rather than modifying Scrum (known as “ScrumBut”) Embrace the solutions to problems that Scrum exposes, rather than changing Scrum processes to hide problems

Sprint Retrospective Best Practices, continued For first meeting, send sample categories so the team can prepare a list of improvements If team is co-located, hold meeting in a place where the team can relax If team is remote, use online meeting capabilities and record input in real-time Conduct the retrospective every sprint, regardless of sprint length Identify themes, prioritize the actions, display them in a prominent place, and follow up

Sample Sprint Calendar
The rhythm of a two week sprint Sun Mon Tues Wed Thurs Fri Sat Sprint planning Review & Retrospective Daily stand-up Playback Scrum of Scrums PO acceptance

Sample Sprint Calendar
The rhythm of a three week sprint Sun Mon Tues Wed Thurs Fri Sat 1 Sprint planning 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Review & Retrospective 20 Daily stand-up Playback Scrum of Scrums Product Owner acceptance

Ending a Sprint Normal completion Abnormal termination
Normal vs abnormal termination Normal completion A sprint completes when the sprint duration ends, independent of user story acceptance Abnormal termination The Product Owner may cancel a sprint if external circumstances negate the value of the sprint goal If a sprint is abnormally terminated: Conduct a retrospective Start a new sprint User stories in a cancelled sprint are returned to the product backlog

Open discussion

Scrum Execution Models

Two Models Integrated Team Staggered Teams *
Implementation and backlog grooming occur together Team and PO refine stories before first sprint Typically performs backlog grooming two hours per week of sprint At end of sprint, team should have two sprints’ worth of backlog groomed at end of sprint AND completed, fully shippable stories built Separate business definition and implementation teams working in staggered model Team remains ahead of implementation team(s) that it supports Business definition activities 80% - Business grooms backlog 20% - Business supports implementation team * also known as Scrum Squared 80% - Backlog grooming, focusing on stories targeted for next sprint 20% - Development team support (clarifications, playbacks, PO acceptance)

Integrated Model Product Owner Scrum Master Skill Sets
Team Composition Product Owner Scrum Master Skill Sets Business Architecture (AKA Lead Business Architect) System Architecture (AKA Lead & Senior System Architects) Subject Matter Experts (optional) Quality Assurance

Integrated Model Follows Scrum standard
Pros Cons Follows Scrum standard The same team that grooms the stories commits to the stories during sprint planning and builds them Grooming is built into the sprint, not done by a separate team Limited time to address analysis, build, and test, especially if team is learning Pega After initial backlog building, team can get behind on grooming Backlog grooming activity is not part of implementation and requires significant discipline to accomplish consistently 80% - Backlog grooming, focusing on stories targeted for next sprint 20% - Development team support (clarifications, playbacks, PO acceptance)

Staggered Model Product Owner (also supports Implementation team)
Includes Additional Business Definition team Product Owner (also supports Implementation team) Scrum Master (can be shared resource) Skill Sets Business Architecture (AKA Lead Business Architect) System Architecture (AKA Lead & Senior System Architects) Subject Matter Experts (optional) Quality Assurance Model consists of this team PLUS the Implementation team

What’s Different About the Staggered Model?
Two sprints’ worth of stories are groomed to full completion BEFORE the implementation sprint starts Stories are estimated by System Architect and QA tester at high level during program planning; estimates are refined by the implementation team before committing to sprint During story grooming, System Architect provides design and technical consultation and ensures conformity with out-of-the-box functions Team reviews stories with development team during sprint planning Clarifications and tweaks are expected during the sprint, but significant changes are not

Staggered Model Pros Cons Often results in better defined user stories since the team specializes in grooming user stories Reduces churn around unclear or ambiguous requirements Supports release planning / enterprise agile coordination Not strictly Scrum since team is not truly cross-functional and no shippable product It sets up a possible disconnect between teams that plan and teams that implement Story points estimated by one SA and one QA; team must re- estimate during sprint planning Disconnect – some teams report no issues; actually appreciate being removed from the churn around user stories and requirements. Others have felt like the stories were being thrown “over the wall” and that they lacked insight into them before having to commit.

What Does this Model Look Like?
Pega 9/15/2018 7:02 PM What Does this Model Look Like? Sample Program Increments RELEASE Business Definition Sprint 1 Business Definition Sprint 4 Business Definition Sprint 5 Business Definition Sprint 6 Business Definition Sprint 2 Business Definition Sprint 3 Implemen-tation Sprint 1 Implemen-tation Sprint 2 Implemen-tation Sprint 3 Implemen-tation Sprint 4 Implemen-tation Sprint 5 … and so on…

Miscellaneous slides

Definition of ready & done

Pega 9/15/2018 7:02 PM Definition of Ready = ready for Development Helps ensure that the stories at the top of the Product Backlog are ready for estimation during sprint planning Best practices: Avoid including rules that require something be 100 percent done before a story is allowed into the sprint: can lead to a waterfall-like process Exception: dependencies on certain teams or vendors Favor guidelines rather than rules All team members shape and agree on the DoD Start with a simple, minimally acceptable version Take your product’s requirements and your team’s abilities and expectations into account Consider non-functional requirements (scalability, portability, security, maintainability) Review and adjust at the end of each sprint

Definition of Ready Story is prioritized in product backlog
Pega 9/15/2018 7:02 PM Definition of Ready examples Story is prioritized in product backlog Team understands acceptance criteria / conditions of satisfaction General task categories are entered in PMF for each story All requirements – including fields, validation complexity, localization, and business logic – have been documented All external dependencies have been identified and team has agreed on the risk that they will accept Acceptance criteria will specify interface simulations or acceptable workarounds Test data is available (other than new cases) The story has a preliminary estimate in PMF and is under a certain size Guideline: maximum size is around half of the team’s velocity Team will revisit initial estimate during sprint planning If story involves new screens, there is a draft UI in Pega with enough detail so the team only needs to finalize screens during the sprint Pick a number of points and only allow stories of that size or smaller into the iteration Can revisit initial estimate during sprint planning

Pega 9/15/2018 7:02 PM Definition of Done = ready for PO acceptance The exit criteria, or a governing agreement that guides all development activities Defines potentially implementable functionality, so must include QA testing Defined by each team; may vary among teams May also differ from one sprint to another depending on the type and scope of the sprint Can have different DoDs for user stories, tasks, and releases While acceptance criteria applies to a single story, DoD applies to the entire sprint or release All team members shape and agree on the DoD Start with a simple, minimally acceptable version Take your product’s requirements and your team’s abilities and expectations into account Consider non-functional requirements (scalability, portability, security, maintainability) Review and adjust at the end of each sprint

User Story (during sprint)
Definition of Done EXamples User Story (during sprint) Release Unit- and regression-tested when applicable, and tests pass All code for release deployed to production Test scripts executed; no blockers or critical defects exist Smoke tests passed Code is peer-reviewed Product Owner has accepted release contents All rules are documented Release notes updated Specifications are attached to rules and are marked as complete End to end, or global, validation performed to ensure rules can coexist in production Rule is checked into release ruleset End-user documentation written and reviewed Technical documentation updated if appropriate Product rule updated when applicable No unjustified warnings Design review performed

Team agreements

Team agreements Meetings will not start before xx or after yy
Pega 9/15/2018 7:02 PM Team agreements Examples – meetings & ceremonies Meetings will not start before xx or after yy Formal meetings have an agenda, have focused participation and begin/end on time (unless all agree to change it). Rotate meeting tasks among team members Team members will come to the meetings prepared Discuss agenda items for the next meeting at the end of each meeting Capture ‘off-the-subject’ ideas and concerns in a “parking lot” Add unresolved issues to an Issues log, with a responsible person and target date

Team agreements Tell the truth and be transparent
Pega 9/15/2018 7:02 PM Team agreements Examples - communication Tell the truth and be transparent Treat all team members with respect and value each other’s time When in the team room, put cell phones on low tone and take calls outside of the room. During meetings, cell phones set to silent. No conversations via speakerphone in open work area Have one conversation at a time, especially during conference calls Work issues internally before escalating to management Keep discussions on track Use drawings, charts, and tables to facilitate discussions when possible

Pega 9/15/2018 7:02 PM Team agreements Examples – self-management Enter our task estimates in PMF daily, before the next stand-up meeting – the Scrum Master does not do it for us! Be dependable. If you say you are going to do something make it happen – don’t make someone remind you! Try to stretch every sprint: take on more responsibility or try a new skill that you haven’t tried before Respond to requests in a timely manner Work on one story at a time and complete it before moving onto the next

Pega 9/15/2018 7:02 PM Team agreements Examples - commitments Only agree to do work that we are qualified and capable of doing Be honest and realistic in planning and reporting project scope, schedule, staffing and cost Be proactive: anticipate potential problems and prevent them from happening Promptly notify Product Owner and leadership of any change that could affect them – but coordinate the communication first Keep other team members informed Keep proprietary information about our customers in strict confidence Focus on what is best for the project as a whole

Pega 9/15/2018 7:02 PM Team agreements Examples – problem solving Encourage all ideas (no criticism), since new concepts come from outside of our normal perceptions Build on each other's ideas Use team tools when appropriate to facilitate problem solving Whenever possible, use data to assist in problem solving Remember that solving problems is a creative process—new ideas and new understandings often result

Pega 9/15/2018 7:02 PM Team agreements Examples – decision making Make decisions based on data whenever feasible, and be proactive about finding the needed data Discuss criteria (cost, time, impact, etc.) for making a decision before choosing an option Encourage and explore different interpretations of data Discuss concerns with other team members during the team meetings or privately rather than with non-team members in inappropriate ways Ask all team members if they can support a decision before the decision is made

Pega 9/15/2018 7:02 PM Team agreements Examples – handling conflict or disappointment Regard conflict as normal and as an opportunity for growth Seek to understand the interests and desires of each party involved before arriving at answers or solutions Keep issues that arise in meetings confidential unless we agree otherwise Choose an appropriate time and place to discuss and explore the conflict Seek to find some common ground for agreement Avoid placing blame when things go wrong: instead, discuss the process and explore how it can be improved

Team agreements If working remotely, be available by cell phone
Pega 9/15/2018 7:02 PM Team agreements Examples – miscellaneous If working remotely, be available by cell phone Provide early notice of time off or other conflicts Use the user story template for story creation

TransitionING to Scrum

Critical Success Factors
Pega 9/15/2018 7:02 PM Critical Success Factors … for a transition to scrum Attitude over aptitude! Commitment to ceremonies Commitment to core principles like transparency, inspect & adapt Selecting people based on qualities, rather than qualifications, and empower them to be self-managing and self-directing Embracing discomfort: solving the solutions to problems that Scrum exposes, rather than changing Scrum processes to hide problems Finding executive champions to support organizational change, help break down barriers to agile culture, and insulate the team from consequences when things go wrong

Laying the Foundation for Scrum
Sample High-level Activities and timeline Activity Owner Timing Determine number of Scrum team(s) Choose staggered or integrated model Determine hiring and staffing needs (in-house, consultants) Engage or hire new Scrum coaches (full time role) Select Product Owner(s), Scrum Master(s) and team Agree on terminology Ensure participants have Scrum training Ensure participants have Scrum management tool training Identify organizational champions to lead cultural change Gather lessons learned from other Scrum teams Identify organizational champions Create communications plan and set expectations

Sample High-level Activities and timeline Activity Owner Timing Identify readiness criteria Determine adoption strategy & public or quiet transition Identify new and/or refine existing business outcomes Create features and epics that support business outcomes Identify Minimum Viable Product for each project Build product backlog: map user stories to epics/features and prioritize them Begin story grooming and enter future phase (non-MVP) user stories in Scrum management tool Agree on Sprint 0 (preparation sprint) tasks for program and projects, and assign owners

Sample High-level Activities and timeline Activity Owner Timing Set expectations for delivery teams, and orient stakeholders and sponsors to sprint and release metrics Build stakeholder understanding of success measures for the Scrum rollout Set expectations for agile estimating in a not-so-agile culture Create team-based incentives for demonstrating Scrum disciplines or attitudes Review estimates for upcoming work, with an eye toward establishing and maintaining a sustainable pace Share examples of sprint-ready specifications

Sample High-level Activities and timeline Activity Owner Timing Introduce three of the Scrum ceremonies (daily stand-up, retrospectives, weekly formal playback / stakeholder review) Introduce regular iteration length – though this requires strong subject matter experts that represent the user community and are also able to make decisions on their behalf Reduce focus on velocity, having QA complete, and delivering something Perform readiness assessment & choose start date

Sample High-level Activities and timeline Activity Owner Timing Encourage skills transfer (BAs do more front-end development, everyone tests) Promote self-management and self-direction within the team (versus having a project manager tell the team what to do and how to do it) Explore test automation Identify artifacts to help managers help themselves to status information

Pega Delivery Excellence Workshop Master slide set, January 2017

Similar presentations

Presentation on theme: "Pega Delivery Excellence Workshop Master slide set, January 2017"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Pega Delivery Excellence Workshop Master slide set, January 2017

Similar presentations

Presentation on theme: "Pega Delivery Excellence Workshop Master slide set, January 2017"— Presentation transcript:

Similar presentations

About project

Feedback