Thrivent s Agile Transformation Journey

Size: px

Start display at page:

Download "Thrivent s Agile Transformation Journey"

Beryl Clarke
6 years ago
Views:

1 Thrivent s Agile Transformation Journey Fox Cities Operational Excellence Association October 5,

2 1 What Makes Thrivent Unique?

3 About Thrivent Financial We are: We have: We ve earned: A not-for-profit, member-owned, organization with more than 100 years of experience. Membership-owned (more than 2 million member-owners share a common bond). #316 on Fortune 500 (June 2017). $116.5 billion in assets under management/advisement (Dec. 31, 2016). $9.0 billion in total adjusted surplus (Dec. 31, 2016) million hours given by Thrivent members in $217.2 million in total outreach from Thrivent and our members in 2016 to help communities. * A.M. Best A++ (Superior) Highest of 16 ratings (May 2017).** Fitch Ratings AA+ (Very Strong) 2nd highest of 19 ratings (May 2016).** Consecutive awards as one of the World s Most Ethical Companies by Ethisphere Institute. * Funding for Thrivent s outreach comes from our tax exemption as a not-for-profit fraternal benefit society. Money we would otherwise pay in certain taxes instead goes to strengthen the communities, congregations and causes our members care about. Members are actively involved in deciding where the money goes locally. ** Ratings reflect Thrivent s overall financial strength and claims-paying ability. They do not apply to the performance of Thrivent s investment products. 2

cyclist Jeff Picken 17 Years IT Background 14 Years IT/Business Enablement Roles Certified ScrumMaster

4 Who We Are Jerry Walker Director of Enterprise Business Enablement Lead on Agile Transformation Thrivent 10 years Hartford Life 9 years ReliaStar ING Voya 8 years Husband, father of 2, runner, cyclist Jeff Picken 17 Years IT Background 14 Years IT/Business Enablement Roles Certified ScrumMaster Certified Scrum Product Owner Agile Coach Thrivent LSS Black Belt Husband, father of 2, runner, wood worker, cyclist 3

5 4 Scrum Framework

6 5 Lean Software Development

7 6 Lean Software Development

8 Lean Software Development Principle #4: Defer Commitment / Decide as Late as Possible 7

9 8 Lean Software Development

10 9 Lean Software Development

11 10 Lean Software Development

12 Forms of Waste Overproduction Unnecessary, or extra features Trans/Handling Decentralized development team, handoffs Inventory Partially done work, scope too big for sprint Waiting Delays, lack of appropriate automation Overprocessng Gold plating, maint/testing unused features Rework Defects, revising detailed project plans Motion Task switching, underutilizing toolsets or patterns 11

13 Lean Levers Standard Operating Procedures - Coding Standards, testing practices Visual Management Task boards, burn-down & burn-up charts Flow Deliver small chunks, automate common tasks Quality Ownership Automate code quality analysis and tests Load Balancing Match work to team capacity in sprint Load Leveling Cross-train team in order to share work Segmenting Complexity Minimize work in process 12

14 Scrum and Lean Plan Act Do Check Our goal is not the capital A noun Agile (like in Agile methodology), but the lowercase adjective agile, meaning fast, flexible, nimble and adapting to change. Katy Sherman 13

15 Lean vs. Scrum Lean Value Stream Lean Champion Knowledge Less Specific Events ScrumMaster Knowledge Sprints Scrum 14

16 Lean Tools to Leverage for Scrum Efforts Little s Law Voice of the Customer / Segmentation 15

17 Leveraging Scrum for Lean Efforts Sprint Concept 16

18 Approach Executive level sponsor Funding for coaching & training Clear and simple answer for why Pilot initiatives > Success stories Address challenges directly Measures to track progress Grassroots support 17

19 Investments Bus. + IT 2003 Fraternal IT Rapid Prototype 2013 Investments Agile/Scrum

20 2014 Business Buy-in 5 Pilot Teams 8 Teams Internal Training Begins 160 People Trained

Last Saved: #NAME? Scale: Use a 1-5 scale, where: 1 = We have substantial room for improvement, 5 = We hit the principle out of the park Agile Principle What does this principle mean?

Is the team producing product on Getting Portal to production was huge and was very Agile.

Too many warranty items. Id product. customer to review what was being created in light of what a lessons learned to help reduce some of our warranty issues. 3 4 4 3 4 4 4 4 4 4 3.8 6 they asked for?

Agile processes harness change for the customer's competitive advantage. 3.

21 Last Saved: #NAME? Scale: Use a 1-5 scale, where: 1 = We have substantial room for improvement, 5 = We hit the principle out of the park Agile Principle What does this principle mean? Team Member Assessments: Avg Comments about Assessments Rank Team member initials ===> JS DS JS JP AB CD HK KM CV DR 1. Our highest priority is to satisfy the customer 1. Is the customer satisfied? Is the team producing product on Getting Portal to production was huge and was very Agile. Got a lot of stuff out through early and continuous delivery of valuable a regular basis, preferably each sprint, that allows the there. Satisfied part caused some of the 3 scores. Too many warranty items. Id product. customer to review what was being created in light of what a lessons learned to help reduce some of our warranty issues they asked for? This does not require delivery to production but delivery in some fashion that is usable by the product owner. 2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. 3. Deliver working product frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. 4. Business people and team members (developers) must work together daily. 2. Has the team been open to changes? Are you following a process that allows the customer to learn from early discoveries and adjust to build a better product? Has the product owner been engaged in adjusting the product backlog with new user stories, new priorities, etc.? 3. Was product actually released more than once to the customers for their use and consumption? Has this been happening within a couple of months or less? Could releases happen more often? 4. Are the developers working directly with the customers and/or business people, and is this interaction occurring on a DAILY basis? 5. Build teams around motivated individuals. Give 5. Does the team have an environment that supports building them the environment and support they need, and the deliverables? This includes the technical environment(s) trust them to get the job done. and tools as well as information radiators like whiteboards or common team spaces. In addition, does the team feel empowered by the leaders and sponsors? Is there an element of trust given to the team? 6. The most efficient and effective method of 6. Are you able to meet face-to-face with other people on the conveying information to and within a team? When the need to communicate is evident, do team development team is face-to-face conversation. members seek each other out in person? If this is not possible because of location, does the team use the next available substitute, such as video conferencing and collaborative screen sharing? 7. Working product is the primary measure of progress. 8. Agile processes promote sustainable development. The sponsors, team members (developers) and users should be able to maintain 7. Does the team measure its progress based on the completion and delivery of working product (not dates or hours or phases)? Can the team members identify the artifacts that show this measurement? Is this measurement used to communicate progress to the customers and stakeholders? 8. Do team members believe the pace of development could continue forever? Or are people being burned out and is more being demanded of them than is reasonable? Is there an element of 'fun' on this team? Portal was worked very Agile with changing requirements. Did a lot better with getting stakeholders involved in our grooming sessions. Not sure we are getting our customers involved early enough. Feel our stakeholders aren't as involved as they should be. Feel product owner needed to be more involved but it has improved alot towards the end of these six sprints. As we do the research, how do we keep that liason going. We need to be sure the stakeholders are receptive to involving them often. Some of our releases were defect fixes, but we many of them included other working products. Some team members feel we still always released good product, only small pieces had defects and we worked quickly to resolve. Feel we need to get them involved more often one idea is daily scrum but not all agree. Feel we are bringing them in more often than the past. Going forward, we want to score this based on appropriate interaction not Daily. Lost Systst for much of these six sprints. Still want to be all together. Whiteboard needs a better location Feel we meet face to face a lot but now and then we still just throw over the wall vs pairing. We are date, hour and phase heavy. Not all team members agree. Not sure we are good at showing artifiacts. We have release notes, but that's not super great. Off hour validation is getting to be alot. UCP is getting bigger. Helping others for prod validation is getting more difficult. Team has fun. Same stories over and over takes away from the fun, We don't get to do as much innovative work as we would like. The pace of the work we plan is very manageable a constant pace indefinitely. 9. Continuous attention to excellence and good 9. Is design being revised and updated throughout the life of design enhances agility. the product to deliver the best product possible? Are user stories/pbis being updated often and is testing automated to ensure quality meets or exceeds the expectations of the customers? 10. Simplicity--the art of maximizing the amount 10. Does the team have an open mind for NOT doing things of work not done--is essential. believed to have little value? Does the team ask questions of each other whether some work could be skipped or done more simply? Does the team exhibit a mindset of attention to lean or continuous improvement principles? get out form ready for our research stories. 11. The best architectures, requirements, and 11. Is the team directed and controlled by a person or a group designs emerge from self-organizing teams. of people? Does leadership entrust the team to make their own decisions and organize the work on their own? Does the same stories colored gray and let P.O. and S.M. know th d il t d i thi d d? Wh We have introduced j-unit tests which is a good improvement. Feel we are revising design when appropriate. Still lacking automated testing, We had too many defects going to product so we are finding we haven't tested all we should. Feel we should have more discussion around story priority throughout the sprint. Don't always do a good job of understanding the task to know if we are doing it efficiently or effectively. We aren't sure if we keep this principle in mind during our work. Started to push with questions when researching stories to determine if this is worth working. Do we need to work on cleaning up our backlog? Need to Not everyone is facilitating daily stand ups. Some team members feel we do not own the backlog but others feel we do contribute. Add new stories above the X X New Teams Planned 25 Teams Active Team Agility Assessment Agility Assessments 430 Trained

22 New Teams Planned IT Buy-in 40 Teams Active 630 Trained

23 New Teams Enterprise Transformation People Development Leaders Internal CSM CSPO Training Hiring more ScrumMasters

24 2017 (cont d) Launch Pad Financial Reporting People Systems 100 Teams Active Kanban Big Room Planning 82% CSM 67% CSPO 1,100 Trained

25 Continuing the Journey People Systems Financial Systems Enterprise Release Systems Areas of Focus Learning Systems Environment Systems Scaling Systems 24

26 Sustaining the Journey Communities of Practice Guilds Metrics Transparency Leader Testimonials Customer Satisfaction 25

27 Obstacles Top-Down Buy-in Training People Quickly Enough Mixed Delivery Environments Breaking Old Habits Product vs. Project Delivery 26

28 What s Next? Expanding Agile through IT Project to Product Delivery Scaling Across Organization Big Room Planning 27

29 Questions? 28

ScrumDay MN. Jump Start Your Agile/Scrum Adoption (failure is awesome) October 13, 2016

ScrumDay MN. Jump Start Your Agile/Scrum Adoption (failure is awesome) October 13, 2016 ScrumDay MN Jump Start Your Agile/Scrum Adoption (failure is awesome) October 13, 2016 0 Agenda About Thrivent Financial Who We Are Starting the Journey New Scrum Team Approach Retrospective Q&A 1 2 What