Adaptive Development Methodology Steve Greene Sr. Director, Tools & Agile Development

Core Values KISS Listen to your customers Iterate

KISS

Listen to your customers

Iterate

What is ADM? ADM is a modified Scrum/XP style of product development that is specific to Salesforce. It employs Scrum project management framework, adopts certain XP practices and is based on lean principles.

What is ADM? Re-factoring Self-organizing Predictable releases Transparent Ftest - Selenium Continuous integration Debt free Just-in-time Iterative Always Potentially Releasable Time-boxed User stories Agile Lean Early feedback Code Reviews Collective Code Ownership Self-correcting

What is Scrum? An agile project management framework for developing software Simple Prioritized work Time-boxed, 30-day sprints

An agile project management framework for developing software

Simple

Prioritized work

Time-boxed, 30-day sprints

Self-organized, empowered teams Daily, verbal communication Potentially “production quality” every 30 days What is Scrum?

Self-organized, empowered teams

Daily, verbal communication

Potentially “production quality” every 30 days

Eliminates waste Increases throughput Provides transparency What is Scrum?

Eliminates waste

Increases throughput

Provides transparency

Scrum Lifecycle Daily Scrum Meeting Sprint Review: Demo Potentially Releasable New Functionality Product Backlog Sprint Backlog Retrospective 24 Hours 2 - 4 Weeks

The Scrum Team QE Engineer Developer Developer QE Engineer Developer Tech Writer UE Designer Product Owner

Roles: Product Owner Single throat to choke Fully accountable for the success or failure of the scrum team Owns and prioritizes Product Backlog

Single throat to choke

Fully accountable for the success or failure of the scrum team

Owns and prioritizes Product Backlog

Roles: Product Owner Leverages team to break down Product Backlog Creates Release Backlog by targeting priority Product Backlog Directly drives development Fully engaged

Leverages team to break down Product Backlog

Creates Release Backlog by targeting priority Product Backlog

Directly drives development

Fully engaged

Roles: ScrumMaster Ensures Scrum Team lives by the principles and practices of Scrum Removes obstacles Coach

Ensures Scrum Team lives by the principles and practices of Scrum

Removes obstacles

Coach

Roles: Scrum Team Cross-functional team Has tasks on the Sprint Backlog Self organizing, Self correcting. Teams decide best way to deliver Makes their own commitment with the resources available, decides how best to distribute tasks to team members Members are dedicated resources (as much as possible) Optimally 6-10 people

Cross-functional team

Has tasks on the Sprint Backlog

Self organizing, Self correcting. Teams decide best way to deliver

Makes their own commitment with the resources available, decides how best to distribute tasks to team members

Members are dedicated resources (as much as possible)

Optimally 6-10 people

Product Backlog Key to success of Scrum Master list of functional and non-functional items desired in the product (features, bugs, re-factoring) Anyone can add to Product Backlog Product Owner is the only person that prioritizes Product Backlog Includes relative estimate of size of features (design, code, test, automate, refactor, doc, fix bugs)

Key to success of Scrum

Master list of functional and non-functional items desired in the product (features, bugs, re-factoring)

Anyone can add to Product Backlog

Product Owner is the only person that prioritizes Product Backlog

Includes relative estimate of size of features (design, code, test, automate, refactor, doc, fix bugs)

Product Backlog Sample

Release Planning Communicate a common vision for the release Initial Design Align team on proposed functionality Determine target functionality for the release

Communicate a common vision for the release

Initial Design

Align team on proposed functionality

Determine target functionality for the release

Sprint Backlog Tasks necessary to complete user stories Many-to-one relationship with user stories Coding, testing, automation, specs, doc, design, etc.

Tasks necessary to complete user stories

Many-to-one relationship with user stories

Coding, testing, automation, specs, doc, design, etc.

Sprint Planning Determine the Sprint Goal Determine work necessary to complete the goal (with time estimates) Make commitments for the Sprint

Determine the Sprint Goal

Determine work necessary to complete the goal (with time estimates)

Make commitments for the Sprint

Sprint Planning Meeting Team “dog piles” on user stories Team figures out how to deliver Sprint Goal even without a resource on the team who normally does a particular type of work Product Owner may negotiate but Team always determines what they can complete during the sprint

Team “dog piles” on user stories

Team figures out how to deliver Sprint Goal even without a resource on the team who normally does a particular type of work

Product Owner may negotiate but Team always determines what they can complete during the sprint

The standards by which we define "done" for sprint functionality is key to the success of iterative, incremental development. Functionality that meets these standards at the end of a sprint will be considered potentially release-able and demoed at the Sprint Review. Definition of “Done”

The standards by which we define "done" for sprint functionality is key to the success of iterative, incremental development. Functionality that meets these standards at the end of a sprint will be considered potentially release-able and demoed at the Sprint Review.

User Stories All defined Acceptance Criteria for a user story have been met. Code Code implementing the user story functionality is checked in and follows department standards . No open regressions (you break it, you own it), with automated tests written for all regressions. No open P1 & P2 bugs for the implemented functionality in the sprint. Quality Code Coverage of 70% Test plan, cases and execution for sprint functionality, regression and cross functional test cases related to sprint functionality, need to be 100% executed, and all P1/P2 cases passing. All resolved bugs have been verified and closed for the sprint functionality. Definition of “Done”

User Stories

All defined Acceptance Criteria for a user story have been met.

Code

Code implementing the user story functionality is checked in and follows department standards .

No open regressions (you break it, you own it), with automated tests written for all regressions.

No open P1 & P2 bugs for the implemented functionality in the sprint.

Quality

Code Coverage of 70%

Test plan, cases and execution for sprint functionality, regression and cross functional test cases related to sprint functionality, need to be 100% executed, and all P1/P2 cases passing.

All resolved bugs have been verified and closed for the sprint functionality.

Performance/Scalability Performance/Scalability impact of sprint functionality understood and quantified, and systesting scheduled, if required, with the sys test team. User Experience UE reviewed new features or significant changes in the UI, feedback incorporated, all resulting P1 and P2 UI bugs fixed. Usability testing completed, feedback has been incorporated into the backlog. Localization All UI components have labels ready for localization vendors. Documentation User doc describing all aspects of sprint functionality complete / checked in. Definition of “Done”

Performance/Scalability

Performance/Scalability impact of sprint functionality understood and quantified, and systesting scheduled, if required, with the sys test team.

User Experience

UE reviewed new features or significant changes in the UI, feedback incorporated, all resulting P1 and P2 UI bugs fixed.

Usability testing completed, feedback has been incorporated into the backlog.

Localization

All UI components have labels ready for localization vendors.

Documentation

User doc describing all aspects of sprint functionality complete / checked in.

Autobuild Page

Sprint Review It’s all about feedback, visibility and course correction All teams demo done functionality to All Technology / Stakeholders Takes place after the last day of the Sprint

It’s all about feedback, visibility and course correction

All teams demo done functionality to All Technology / Stakeholders

Takes place after the last day of the Sprint

Sprint Review User Story Doneness Checklist User documentation complete and checked in. All UI labels ready for localization vendors. Usability testing scheduled when necessary, and feedback incorporated into backlog. UE has reviewed any new features; P1 and P2 UI bugs fixed. Performance/scalability impact ascertained and sys testing scheduled if required. All resolved bugs verified and closed. 100% of test cases logged in QA Tracker and executed in a QA environment, and all P1/P2 cases passing. Code Coverage of 70% (or as agreed with team) No open P1 & P2 bugs No open regressions. Automated tests written and reviewed for all regressions. Code checked in and follows department standards. BT & Profile Perm Setup Page Handshake POC Done Criteria

Looks at “how” team operates and product is built (process, tools, etc.) Occurs after every Sprint What went well? What didn’t go well? What will you do differently next time? Retrospective

Looks at “how” team operates and product is built (process, tools, etc.)

Occurs after every Sprint

What went well?

What didn’t go well?

What will you do differently next time?

ADM Principles Eliminate Waste – Optimize the delivery of customer value Build Quality In – Design and engineer quality into our products rather than ensuring quality through late-cycle manual testing Respect People – Build empowered, self-organizing, high performing teams Optimize the Whole – Overall throughput of customer value is more important than individual utilization Create Knowledge – Encourage continuous learning, improvement, and innovation Just-in-Time Decisions – Break dependencies, maintain options, and make irreversible decisions at the last responsible moment Deliver Fast – Deliver customer value early and often Based on Lean Principles

Eliminate Waste – Optimize the delivery of customer value

Build Quality In – Design and engineer quality into our products rather than ensuring quality through late-cycle manual testing

Respect People – Build empowered, self-organizing, high performing teams

Optimize the Whole – Overall throughput of customer value is more important than individual utilization

Create Knowledge – Encourage continuous learning, improvement, and innovation

Just-in-Time Decisions – Break dependencies, maintain options, and make irreversible decisions at the last responsible moment

Deliver Fast – Deliver customer value early and often

Based on Lean Principles

ADM Customer Advantage Time-to-market : Frequent value delivery Flexible, responsive & effective R&D team Predictable and reliable Customer influence : priority of features More of the right value, more often

Time-to-market : Frequent value delivery

Flexible, responsive & effective R&D team

Predictable and reliable

Customer influence : priority of features

More of the right value, more often