Agile Methodology

1. Agile Methodology AGILE TRAINING

2. Objectives • Introduction to the Agile Manifesto • The Unitrin Agile “philosophies” and phases • Inception Process • Envisioning Process • Collaborative Requirements Process • QA Process • Development and Deployment Processes • Agile Change Management • Next Steps

3. Agile Manifesto • Individuals and interactions over processes and tools • Working software over comprehensive documentation • Customer collaboration over contract negotiation • Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.

4. Unitrin Agile: Our Project Phases 6 project phases • Inception • Envisioning • Collaborative Requirements • Development • Quality Assurance • Deployment 1/3 of the phases involve planning

5. Inception Key Concepts • Clarifying the project scope and objectives • Getting enough information to confirm that the project should proceed - or to convince you that it should not. • Understanding the feasibility of the intended solution, and • Defining the inception plan (release level) Led by the customer

6. Inception Activities • Verify business benefit • Conduct business process review • Understand what to deliver • Identify key system functionality • Define acceptance criteria

7. Inception Activities • Identify the stakeholders and resources • Determine the high level estimate (no buffer) • Identify risks associated with the project • Identify pre-requisites • Determine at least one possible solution

8. Inception: Outputs

9. Inception Exit Criteria • Approved, prioritized work in-take item • All impacted teams identified • Project team understands the project need/purpose • Scope document with high level requirements • High level estimate (shirt size)

10. Inception FAQs “Do I have to have an inception phase?” “Can I have more than one inception phase?”

11. Envisioning Key Concepts • Highly speculative • You will only have high level information in order to plan • Plan should be realistic and include buffer for unknowns • Feature based • Plan is organized around what will be delivered • Iterative • Team should plan to regularly revisit, revise the plan as more is known • Collaborative • Representatives from all teams must be present and participate in the plan • Focused on planning • Does not involve digging into solutions, requirements • Participants must keep conversation at high/mid level

12. Envisioning Concepts The most important part of the envisioning is planning

13. Envisioning Activities • Assemble the teams • Map features to threads • Determine milestones for each thread • Refine work estimates (high level plus buffer) • Iterating through plan • Test strategy development • Retrospect

14. Resources • Define the roles and responsibilities for team members needed • Agreed to during Inception; reviewed as part of envisioning • Don’t forget the business resources needed • Contributing team members (other technical team members needed) • Include SMEs, managers, project managers and others that will be required to support the staff • Determine what constitutes a team (decided at program inception) • Core “agile” team • 1 person from each discipline • Fully (100%) allocated to the work that the team is doing • Support staff • May not be allocated at 100% • Number of teams is determined by the number of available resources that make up the team • Requisitions for additional staff are identified

15. Resources

16. What do mean by “thread?” Work breakdown structure • Program x • Project x.x • Release x.x.x • Thread x.x.x.x • Milestone x.x.x.x.x • Task Unit x.x.x.x.x.x • A thread is a system enhancement delivered by a single team

17. WBS Example Exceed (program)       Personal Auto (project)               IL Auto (release)                     Out of Sequence (thread)                            Skeletal PERS Record (milestone)                                   Unit testing (task)

18. Definition of Thread A thread includes: a. Envisioning plus any preparation the teams may require in order to get up to speed on the project (including administrative work and development of the test strategy) b. Milestones that will implement the thread (this may be synonymous with features) c. Thread testing (testing for all milestones in the thread) Essentially a thread includes all activities from planning through integration testing

19. Envisioning Case Study: Examples of Reasons to Buffer • All differences in process haven’t been driven out and addressed during the scoping process • Waiting for decisions • Over-engineering of configurable areas of Claim Center – activities, assignments, notes • Complicates upgrades increasing expense, decreasing our ability to quickly move to new releases • Changes don’t prove of value and must be backed out at some point • Cross-thread/team impacts discovered during development • Lack of consistency in user interface requiring re-work • IT projects > 12 Mos. are at significant risk for delivery delay • The unexpected: loss of staff, CATs, other disasters • Assumptions

20. Milestone Planning • For each scope, group works together to come up with the milestones that will implement the thread • Each high level feature in each scope discussed in detail: • Facilitator is knowledgeable on each feature discussed • Does not include discussion of how it will be implemented, the solution, or detailed requirements • Each milestone gets its own estimate • Duration (weeks) • Role(s) required to fulfill the milestone • MoSCoW discussion

21. What is a “milestone?” • May be a feature if individually “implementable” • Should be no larger than 4 wks in duration • Can be up to 6 wks in duration but need to determine why • Defined by the person/team who will work the milestone

22. What does a milestone include? • Collaborative analysis for only that milestone • Requirement(s) sign off • Development • Test case development • QA sign off • Test execution (this may only at the system test level in Dev) • Defect management

23. Milestone Sticky Wall

24. Right-Sizing a Milestone • This is where the paradigm shifts • Each milestone should result in an implementable feature that is done done • From planning through system testing • Milestones are not: • Tasks • Waterfall phases (e.g. Requirements, Coding, Testing) • Divided into horizontal layers (idea is to address a “vertical” slice of functionality

25. Right Sizing a Milestone Iterative ways to split out a milestone: • “Planned rework” • Start simple and build in complexity with subsequent milestones • Separate the functional and non-functional • E.g. Build controls before making them reusable • Remove cross-cutting concerns • E.g. Build user interface and then roll in performance optimization • Split based on mixed priority • Address higher priority needs first • Business value • Infrastructure

26. Right Sizing a Milestone Incremental ways to split out a milestone: • Split across data boundaries • Like data implemented together • Policy data then billing data, etc • Operational boundaries • C.R.U.D

27. Task Tracking • Tasks, lowest level of WBS, are tracked by the team • Defined by the person/team performing the task • Based on experience • Visible • Updated regularly (we know a little more about the project each day)

28. Task Tracking

29. Tips for Planning

30. Envisioning Outputs

31. Envisioning Exit Criteria • Milestone plan for the upcoming project • Features to be delivered per cycle • Target release date • Task list per team • Project team list (with R&R) • Refined estimate • Test strategy • Including acceptance criteria • Linked into QC Test Plan folder

32. Envisioning FAQs “Do I include planning in my plan?” “Is a project plan required?” “What if a team can’t participate in the planning?” “The approved project impacts non-USG teams. Can I start working on it anyway?” “Do teams have to participate (in planning) if they are only testing?” “How frequently do I need to update my plan?” “Who uses my plan? “Do I have to envision if my team is doing all the work?”

33. Collaborative Requirement Key Concepts • The right people involved • Everyone is prepared • Project doesn’t move forward till all issues are closed • Deep dive • Follow good meeting practices • Just-in-time analysis • Just enough documentation

34. Collaborative Requirement Activities • Perform requirements analysis/modeling for the milestone(s) • Verify/validate requirements • Add requirements to QC/Caliber • Create the test plan

35. Collaborative Requirements Process flow

36. Collaborative Requirement Outputs

37. Collaborative Requirements Exit Criteria • All issues closed before start of construction on a milestone/feature • Requirement artifact(s) loaded into QC/Caliber • Draft test plan for the milestone/feature • Detailed estimate • Validated acceptance criteria

38. Collaborative Requirements FAQs “Do you have a requirements template?” “Who should I invite to my collaborative requirements session(s)?” “Do I need to hold requirement meetings if only one team is involved in my project?” “How many attendees is too many in a collaborative meeting?”

39. Requirements Change Control • Encourage coordinated change • Added a simple change control process to CR • Change Control Log • Evaluate impact of change • Approvals • Add to requirements

40. Development Exit Criteria (Exit criteria for analysts) • Test cases documented in QC • Test cases linked to requirements in QC • Test case steps reviewed by customer • Performance guidelines (if applicable) • Performance test scripts written and ready to execute (if applicable) • Code has been unit tested and reviewed by analyst on local machine • Code is ready to be tested (per developer)

41. Quality Assurance Key Concepts • Defect prevention (rather just detection) • Test early (including the developer’s local machine) • Test often • No test performed for the first time in upper environments • Test artifacts created and stored in QC • Test cases linked to requirements, defects • Use test automation • Daily testing stand ups

42. Quality Assurance Activities • Test case development (occurs during Development) • Test execution in Dev, SysTest, INT and UAT environments • Defect management in all environments • Daily testing stand ups

43. Quality Assurance Outputs

44. QA Exit Criteria: to SysTest • Defects retested and passed in Dev • Code approvals to move to System Test environment

45. QA Exit Criteria: into Integration • Meet performance metrics in Dev or System Test (if applicable) • Testing in the development environments is complete • All Sev 1, 2, 3 defects resolved • Attend daily quality stand up to give project status • Pre-release – into INT • QA sign off on code • Info in Harvest/Endevor notes (QA Name, Heat/WR#/Change Log, Change Request Form (CRF) #)

46. QA Exit Criteria: into UAT • Meet performance metrics in INT (if applicable) • Testing in INT is complete • All Sev 1, 2, 3 defects resolved (if found) • Demoted if not resolved within 24 hrs • Attend daily quality stand up to give project status • Pre-release – into UAT • Customer sign off on code promotion • Meet the environment date

47. QA Exit Criteria: into Prod • Meet performance metrics in UAT (if applicable) • Minimum 24 hr stay in UAT • Spot check testing UAT only • All Sev 1, 2, 3 defects resolved immediately (if found) • Demoted if not resolved within 24 hrs • Attend daily quality stand up to give project status • Production-release – into UAT • Customer sign off on code promotion • Appropriate CRF/Change Mgmt documentation

48. Agile Discussion Board • Implemented the Agile Discussion Board as a mechanism for people to provide feedback, make suggestions, ask process questions, etc.

49. Next Steps • Agile requires a paradigm shift • Replacing “waterfall” thinking with “agile” thinking • Deep dives into analytical processes: Envisioning and Collaborative Requirements? • What analyst tools are needed for the agile teams? • Invite me/Rick/Sharon to observe your sessions • Virtual coaching

50. Questions & Answers Q&A