Hide Notes 

Slide 1: Adaptive Development Methodology Steve Greene Sr. Director, Tools & Agile Development
Slide 2: Core Values  KISS  Listen to your customers  Iterate
Slide 3: 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.
Slide 4: What is ADM? Lean Agile Self-organizing Time-boxed Continuous integration Self-correcting Re-factoring User stories Just-in-time Debt free Ftest - Selenium Transparent Code Reviews Early feedback Collective Code Ownership Iterative Predictable releases Always Potentially Releasable
Slide 5: What is Scrum? An agile project management framework for developing software  Simple  Prioritized work  Time-boxed, 30-day sprints
Slide 6: What is Scrum?  Self-organized, empowered teams  Daily, verbal communication  Potentially “production quality” every 30 days
Slide 7: What is Scrum?  Eliminates waste  Increases throughput  Provides transparency
Slide 8: Scrum Lifecycle Daily Scrum Meeting Product Backlog Sprint Backlog 24 Hours Sprint Review: Demo Potentially Releasable New Functionality 2 - 4 Weeks Retrospective
Slide 9: The Scrum Team Developer QE Engineer Developer Tech Writer Product Owner QE Engineer UE Designer Developer
Slide 10: Roles: Product Owner  Single throat to choke  Fully accountable for the success or failure of the scrum team  Owns and prioritizes Product Backlog
Slide 11: Roles: Product Owner  Leverages team to break down Product Backlog  Creates Release Backlog by targeting priority Product Backlog  Directly drives development  Fully engaged
Slide 12: Roles: ScrumMaster  Ensures Scrum Team lives by the principles and practices of Scrum  Removes obstacles  Coach
Slide 13: 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
Slide 14: Product Backlog  Key to success of Scrum  Master list of functional and nonfunctional 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)
Slide 15: Product Backlog Sample
Slide 16: Release Planning  Communicate a common vision for the release  Initial Design  Align team on proposed functionality  Determine target functionality for the release
Slide 17: Sprint Backlog  Tasks necessary to complete user stories  Many-to-one relationship with user stories  Coding, testing, automation, specs, doc, design, etc.
Slide 18: Sprint Planning  Determine the Sprint Goal  Determine work necessary to complete the goal (with time estimates)  Make commitments for the Sprint
Slide 19: 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
Slide 21: 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 releaseable and demoed at the Sprint Review.
Slide 22: 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.
Slide 23: 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.
Slide 24: Autobuild Page
Slide 25: 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  
Slide 26: Sprint Review User Story Doneness Checklist Done Criteria Code checked in and follows department standards. No open regressions. Automated tests written and reviewed for all regressions. No open P1 & P2 bugs Code Coverage of 70% (or as agreed with team) 100% of test cases logged in QA Tracker and executed in a QA environment, and all P1/P2 cases passing. All resolved bugs verified and closed. Performance/scalability impact ascertained and sys testing scheduled if required. UE has reviewed any new features; P1 and P2 UI bugs fixed. Usability testing scheduled when necessary, and feedback incorporated into backlog. All UI labels ready for localization vendors. Handshake POC Setup Page BT & Profile Perm
Slide 27: 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?
Slide 28: ADM Principles 1. 2. 3. 4. 5. 6. 7. 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
Slide 29: 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