1. Agile Adoption GMAS Product / Practice Teams PMO Meeting – May 2014

2. The process evolved over several release cycles GMAS Release 34 – April 2013 - “At worst, we will have really good team communication!” Didn’t really have a dedicated Scrum Master We thought the tool (Greenhopper in JIRA) would make is easy Struggled with sprint tracking & planning GMAS Release 35 – August 2013 - Uncomfortable, but starting to take shape Availability of Agile Coach Worked through process needs of the team Grooming a Scrum Master Product Owner pulled away on capital project commitments GMAS Release 36 – December 2013 - “In the groove!” – completely Agile Scrum Master leading process Meetings planned at start of cycle Discussions moving faster due to agreed process and experience Product Owner available 2

3. Regular Agile Meetings Sprints start on Monday and are 2 Weeks in duration Backlog Discussion – Thursday before sprint Sprint Planning – Monday morning of start of sprint Sprint Demo – Friday afternoon at the end of the sprint Sprint Retrospective – Friday afternoon at the end of the sprint Daily Stand-up – Daily at 11:45am 3

4. Resources, Availability & Sizing Our Team Assumptions Given a 40 hour work week, the maximum allowable hours for a sprint is 60 hours Individual tasks should not take more than 1 Day to complete Stories must fit in a 2 Week Sprint 4

5. Definition of “Done” 1.Assess impact to end user documentation 2.Primary testing complete 3.DB change scripts checked into CVS and tested in DEV 4.Test plan documented 5.Test plan peer reviewed 6.Technical documentation completed/updated 7.Code passed peer review –Tech team unit test case documented and reviewed 8.Tested locally by tech owner before checking code in 5 9.Functional documentation completed/updated 10.Functional requirements completed/updated 11.Change meets acceptance criteria 12.External (business and system) dependencies are identified 8.HDW dependencies are identified 13.All bugs that prevent acceptance criteria from being met are fixed 14.Required CMS text changes documented (do not need to be committed) Story Done (bugs and enhancements) If a story is “Done” it is also “Production Ready”

6. Agile Board 6 8 Story – Suite 209

7. Retrospective 7

8. Co-Testing 8

9. Agile Myth’s “No documentation !” –Documentation is still a part of the definition of “Done” “I can skip the Standup Meeting” –Communication degrades quickly when team members do not participate “We can do Agile with just a daily standup meeting” –Planning meetings are critical to the overall sprint process and success “If I’m developing in the sprint, I can’t work on anything else” –Available hours are set at the start of the sprint for each person. It is possible to reserve time for support, other systems, training, etc., that are outside of the sprint. 9

10. Success Factors Teams already had long standing working relationships and respect for each other Shared desire to do Agile A focused Scrum Master Available Product Owner An Agile Coach – we were all classroom trained, but needed experienced guidance 10

11. Overall Results / Observations Mission and Goals –Better awareness by the entire team as to what is being worked on –Better knowledge of Release Goals Results –Less bugs! –Less stress at release sign-off –Easier to re-size releases Not cheating the important things –Documentation is a part of the Definition of “done” –Research spikes – carving out time to do advance work 11

12. Questions? 12