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

• 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 available2

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

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

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”

Agile Board

68 Story – Suite 209

Retrospective

7

Co-Testing

8

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

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

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

Questions?

12