Transforming Your Engineering Team: YouVersion's Journey into Agile Development

2014 was a transformational year for YouVersion. The team went from shipping two releases in a single year to 22. This presentation walks through the state of the YouVersion team at the beginning of 2014 and shares practical advice that helped YouVersion begin releasing high quality software at a high frequency.

Transcript

1. Transforming Your Engineering Team YouVersion’s Journey into Agile Development @zachschmid
2. Bible App Updates 2014 22 2013 2
3. About The Bible App 175+ Million Installs 1092 Bible Versions 779 Languages 10 Engineers 3,200,000:1 Verified User to Engineer Ratio
4. The Lifecycle of an Organization Credit: Adizes Corporate Lifecycle
5. HOW DO WE GET TO PRIME? We need a scalable process that supports the current and future growth of our team
6. THE DECISION
7. WHY AGILE? We need to be nimble, provide frequent feedback to our stakeholders, and adapt quickly to changing priorities
8. THE JOURNEY
9. GETTING PEOPLE ON BOARD Your best chance for long-term success is when the desire for change comes from the bottom-up
10. - We find ourselves in routines/patterns because that’s the routine we fell into to get something done. - I need shielding from shifting priorities. - Our estimations vs. actuals are way off. - We need more focus around project planning and scoping. - I need help with prioritizing what I should be working on and learning. Engineering Team Feedback
11. Change is Hard In software, we typically avoid change not because we are afraid of it, but because we have been conditioned to provide the right thing the first time. - Change == Bugs || Missed Features - Any change requests suggest we’ve failed in some way because we didn’t get it right
12. CHANGE IS INEVITABLE AND WE MUST EMBRACE IT
13. Understanding Change INTEGRATION AND PRACTICE NEW STATUS QUO CHAOS LATE STATUS QUO TRANSFORMING IDEAS ARRIVE FOREIGN ELEMENTS ARRIVE TIME PERFORMANCE Satir Change Model
14. THE PROCESS
15. What is Scrum? Scrum (n): An agile framework for completing complex projects, while productively and creatively delivering the products of the highest possible value. Scrum is: Lightweight Simple to understand Extremely difficult to master
16. COPYRIGHT 2008-2010 MITCH LACEY Scrum Process
17. Product Requirements - Every new feature starts in a product requirement document - A few critical components: - What are the goals for this feature? - What metrics should we be tracking? - How do we measure success? (Key Performance Indicators) - MVP requirements (initial design, copy, etc) to begin iterating with Atlasssian Confluence
19. Feature Forecasting
20. Sprint Planning Meeting Review of Product Backlog - Product team describes what features will ideally be worked on during the next two week cycle - Engineering team describes engineering specific priority items
 Outcome of these discussions help to set the sprint goal.
21. Sprint 26 - Almostathon: - Complete MVP of image share based on feedback from sprint review - Ship Bible 5.8 iOS and Bible 5.7 Android - Complete Phase 1 of Apple Watch Prototype - Develop Trending Verses API - Moments Migration: Migrate comment data - Ship Reading Plan Image Upload functionality to Cassi Example Sprint Goal
22. Sprint Planning Meeting
24. - Story points help to measure the complexity, effort and uncertainty of a task - Points are assigned relative to each other - We rate tasks as a team - Point Values: 0, 1, 2, 3, 5, 8, 13, 20 - We want to be accurate but not precise - Breaking issues down into smaller components has been key to our success Planning Poker Resources : www.planningpoker.com ; www.pointingpoker.com Estimating Issues Planning Poker
25. How Much Can We Work On? - 10 Day Sprint Cycle != 10 Days of Sprint Execution - Plan for the unknown - Give yourself margin - Account for sprint related meetings/tasks Sprint Buffer Sprint Execution Time Off Support/Maintenance Sprint Meetings
26. Determining Velocity - Getting an accurate read on team velocity will take time as your team adapts to a new process - We use average velocity from the previous four sprints as a reference for current velocity - There will always be some variability Story Points Iteration INTEGRATION AND PRACTICE NEW STATUS QUO LATE STATUS QUO TRANSFORMING IDEAS ARRIVE FOREIGN ELEMENTS ARRIVE CHAOS
27. Sprint Planning Meeting
28. Sprint Execution In Review • Tests Written/Passing • Pull Request Submitted Done: • Approved Pull Request • Merged • Documented • Deployed
29. Sprint Execution - Make the status of your sprint highly visible to the entire team - There should be no surprises as to how a sprint is progressing
30. Daily Standup Every Day: Written standup before 9:30 AM Tuesday/Friday: Video Standup (15 min max) Standup tool: Flock- heyflock.com
31. Sprint Review - Overview / milestones hit - Demo of completed items - Summary of any scope changes
32. Sprint Retrospective - What did we do well? - What should we have done better? - Action Items
33. KEYS TO SUCCESS
34. - Change is inevitable and we must embrace it - Your team must learn the mechanics of the process you’re implementing - DO NOT adopt a new process in the middle of a development cycle - Give it time - Setting aside time for continuous learning is absolutely critical Keys to Success
35. youversion.com/jobs