1 / 18

Introduction to Agile and Scrum

Introduction to Agile and Scrum. Speaker/Author: Paul Packebush Section Manager, Corporate Metrology Author: Logan Kunitz Staff Calibration Engineer. Process Emerges to Stop Chaos. No one loves process, but it feels good compared to the pain of chaos

pier
Download Presentation

Introduction to Agile and Scrum

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introduction to Agile and Scrum Speaker/Author: Paul Packebush Section Manager, Corporate Metrology Author: Logan Kunitz Staff Calibration Engineer

  2. Process Emerges to Stop Chaos • No one loves process, but it feels good compared to the pain of chaos • Developers are unable to adapt quickly • Developers are extremely good at following the existing process, and process adherence is the value system • Process starts to trump flexibility

  3. Agile Development

  4. Agile is not a process • You cannot do Agile, but you can be Agile

  5. Manifesto for Agile Software Development • Individuals and interactions • over processes and tools • Working software • over comprehensive documentation • Customer collaboration • over contract negotiation • Responding to change • over following a plan http://www.agilemanifesto.org

  6. 12 Principles behind the Agile Manifesto • Early and continuous delivery of valuable software • Welcome changing requirements • Deliver working software frequently • Teams work together daily • Trust motivated individuals to get the job done • Face-to-face conversation • Working software as primary measure of progress • Sustainable development • Continuous attention to technical excellence and good design • Simplicity • Self-organizing teams generate best end products • Teams reflect regularly and adjust behavior accordingly http://www.agilemanifesto.org

  7. What is Scrum? A framework to help teams work in an Agile way • Transparency • Everyone knows the project state • Inspection • Ongoing reflection on status • Adaptability • Team decides how to quickly adapts to changes Scrum is not a process it is a framework to get work done

  8. Scrum values • Commitment • Team has great control of its destiny • Focus • Fewer deliverables at a time • Openness • Express concerns and status often • Respect • Working together sharing in success and failures • Courage • Teams feel empowered to undertake greater challenges

  9. Scrum vs. Waterfall Waterfall: Design All Features Develop Deploy Scrum: Feature A *Design *Dev *Deploy Feature B *Design *Dev *Deploy Feature C …

  10. Scrum vs. Waterfall Waterfall: Design All Features Develop Deploy Scrum: Feature A.1 Feature B.1 … Feature A *Design *Dev *Deploy Feature B *Design *Dev *Deploy Feature C …

  11. Scrum at a Glance

  12. Scrum Implementation Case Study • NI Calibration Business Case • Long development cycles • Schedule slippage • Need for new HW product calibration support • Growing backlog of products requiring calibration support • Simply adding headcount is not a sustainable solution Approach • Transitioned from Waterfall development process to Agile / Scrum software development process • Challenges • Distributed Scrum Team • Defining “Finished”

  13. Distributed Scrum Team Challenges NI Calibration Team • Scrum dictates close, daily interaction of team members • Distributed teams are a reality for global companies • Primary challenges with distributed scrum team • Isolation of remote team members during meetings – lacking engagement in the meetings • Visual tools (i.e. white-board for tracking tasks) not accessible by remote team members • Team size (keeping daily meeting length short) Austin, TX Hungary ScrumMaster Developers Developers Product Owner

  14. Distributed Scrum Team Recommendations • Avoid meeting rooms • Everyone meets from their desk • Shared “cloud-based” tool for white board • Scrum team size: < 10 • Keep daily meetings <15 minutes

  15. Defining “Finished” • Scrum dictates a “finished” product or feature at the end of each sprint • What is “Finished” • The feature is complete and ready to be released • Why is this a problem? • 8 to 12 weeks to develop and test a typical feature (doesn’t include integration testing - another 2 to 8 weeks) • Scrum sprint length = 4 weeks • Our features usually can’t be split into sub-features that are individually shippable • It will take 2 to 3 sprints to demonstrate progress for most of our features

  16. Example: Splitting Feature into User Stories 2 to 12 weeks 8 weeks Product Development & Testing Integration / Release Testing 2 wks 2 wks 2 wks 2 wks Sub feature Development & Testing Sub feature Development & Testing Sub feature Development & Testing Final Development Testing “Finished”Ready for Integration “Finished” “Finished” “Finished” Sprint #1 Sprint #2

  17. Example: Calibration Procedure • Full procedure includes several verification steps • Split overall feature by verification step into smaller user stories • “Finished” for each story • Fully developed • Fully tested • Fully reviewed • Feature releases once all user stories are complete

  18. Conclusion NI Calibration Team Performance After Using Agile / Scrum • Improved time between product updates • Handled one-off customer feature request by doing a mid-cycle release with the new feature. Minimum impact to existing product release schedule. • Ability to meet release targets with improved accuracy

More Related