1 / 12

Agile Adoption GMAS Product / Practice Teams

Agile Adoption GMAS Product / Practice Teams. PMO Meeting – May 2014. 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

caraf
Download Presentation

Agile Adoption GMAS Product / Practice Teams

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. 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

  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

  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

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

  6. Agile Board 8 Story – Suite 209

  7. Retrospective

  8. Co-Testing

  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.

  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

  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

  12. Questions?

More Related