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

2. 2 ni.com 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. 3 ni.com Agile Development

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

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

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

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

8. 8 ni.com 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. 9 ni.com Scrum vs. Waterfall Waterfall: Scrum: Design All Features DevelopDeploy Feature A *Design *Dev *Deploy Feature B *Design *Dev *Deploy Feature C …

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

11. 11 ni.com Scrum at a Glance

12. 12 ni.com 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. 13 ni.com Distributed Scrum Team Challenges 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) Product Owner ScrumMaster Developers Austin, TXHungary NI Calibration Team

14. 14 ni.com 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. 15 ni.com 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. 16 ni.com Example: Splitting Feature into User Stories Product Development & Testing 8 weeks Integration / Release Testing 2 to 12 weeks Sub feature Development & Testing Final Development Testing 2 wks “Finished” Ready for Integration “Finished” 2 wks Sprint #1Sprint #2

17. 17 ni.com 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. 18 ni.com Other Related Concepts Test Driven Development (TDD) Unit test code and use case coverage should be thorough and complete All unit tests should be automated. All unit tests should be executed automatically with each new build. Continuous Integration (CI) Builds should be frequent and also automated. Fail Fast. Integration issues should be identified as soon as possible in order to enable quick resolution. Commitment Based Project Management (CPBM) Negotiate clear agreements. Keep communications going during the delivery stage. Present the deliverable explicitly.

19. 19 ni.com TDD (Test-Driven Development) & CI (Continuous Integration) High-level principles promote efficient & effective testing Objective of releasing software continuously by making test coverage 100% and automating all tests All Tests should be Automated o Manually tests are a resource time-sink and accumulate over time o Automating all tests enables all features to be tested as often as testing infrastructure will allow – product can be released as soon as all tests pass Build process should be frequent and automated o Team members should be able to test code against final build frequently Fail Fast o Find and Fix issues sooner rather than later o Team should share same development code base

20. 20 ni.com Commitment Based Project Management (CPBM) Framework for developer / manager interactions in Agile environment Guidelines: Make requests, not assignments. Negotiate clear agreements. Keep communications going during the delivery stage. Present the deliverable explicitly. When the requester, always acknowledge and assess the delivery.

21. 21 ni.com 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