Agile at DeLorme
Download as PPTX, PDF0 likes446 views
This document summarizes the history and evolution of the agile practices used by DeLorme's inReach Web Team. It describes how the team transitioned from a siloed structure to scrum with three week sprints. They later adjusted to one week overlapping sprints and introduced kanban elements. The team also experimented with dedicating most members to long term epics. The document provides details on their processes, metrics, challenges and plans for scaling agile practices at DeLorme.
Agile at DeLorme
- 1. © 2015-2016 DeLorme1 © 2015-2016 DeLorme Mark D. Grover, CSM, Ph.D. inReach Web Team Scrum Master Presented to: Agile Maine, Dec 8 2015 11 January 2016
- 2. © 2015-2016 DeLorme Founded in 1976 Current products: inReach communicator Digital data products Paper Atlases GPS devices and companion desktop products (consumer and GIS) 11 January 2016 2
- 3. © 2015-2016 DeLorme Web, Services, and Manufacturing Automation Team (today's subject) Mobile Firmware/Apps Team Legacy Support Efforts including GIS IT, DBAs, plus distributed QA 11 January 2016 3
- 4. © 2015-2016 DeLorme Activist integrators/managers Large projects, distant from customer feedback Sudden change orders to developers Unpredictable and slow deliveries Silos Personal projects Every day a surprise 11 January 2016 4
- 5. © 2015-2016 DeLorme Satellite 2-way text communicator Global coverage 24-hour worldwide SOS Rugged Model evolution "Home base" online support Over 50,000 active units Enterprise support 11 January 2016 5
- 6. © 2015-2016 DeLorme Source Control (c. 1997) Code-sharing discipline: multiple product versions from common core libraries Dev/Test/Prod versions of code and products (c. 2007) Restrictions on access to each level Automated Testing Code Reviews for everything, everyone Release/Deployment versioning Continuous Integration Bug reporting systems Co-located teams Stand-ups 11 January 2016 6
- 7. © 2015-2016 DeLorme inReach Web, late 2011 Message Gateway "App" tier: device/user profiles, message analysis/history, Explore site, SOS management Finance, Sales, Marketing, Billing, Administration support tier Other: APIs, Manufacturing support, Sync app, standalone gateway, data delivery and cutting C#, JavaScript, SQL 11 January 2016 7
- 8. © 2015-2016 DeLorme January, 2013 Enter a champion Establishment of roles (PO, SM, team) Buy-in from management Internal training, discussion, acceptance Stakeholder and management involvement New tools: Greenhopper/Jira, Git, Stash, TeamCity. Later: NuGet, Octopus, NewRelic 11 January 2016 8
- 9. © 2015-2016 DeLorme Agile Manifesto First model: Classic Scrum Process Principles: Team, as a whole, makes the rules. Rules can be changed. Team: Personnel level has varied but only slightly 6-8 devs, 2.5 QA, 1+ PO/UI, .5 SM Organized around existing talent Co-located here, but with third-party partners worldwide 11 January 2016 9
- 10. © 2015-2016 DeLorme 1. Embrace the Manifesto and the Principles. 2. Work as a team – involve others in decision-making. Include stakeholders. 3. Use the inReachWeb Web Team distribution list – share your questions and knowledge. 4. Our daily scrum meets at 915 AM at the Couch of Learning. When working remotely, submit a report via email to the team if you will be absent. 5. Meetings: Be on time. End on time. 6. Don't break the build. 11 January 2016 10
- 11. © 2015-2016 DeLorme 7. Update the Backlog before the daily scrum. 8. Don't leave for the day until your promoted code has built. 9. Don't take on un-estimated features or improvements (or at least get those present in the office area to generate a quick estimate when it can't be avoided). 10.Raise critical issues to the team and fix them in the current sprint whenever possible. 11.Clearly document all test steps. 12.Keep this working agreement simple and short. 11 January 2016 11
- 12. © 2015-2016 DeLorme Started with classic Scrum Gen 18 becomes Sprint 18 Three week sprints Public deployment with each sprint Variations introduced quickly: Tickets generated by QA from regression get zero story points, as well as emergencies/hotfixes Mid-sprint hotfixes are occasionally required, charged to current sprint Ticket swapping in/out for equivalent story points Introduced "Sweep Week" 11 January 2016 12
- 13. © 2015-2016 DeLorme Development 1 (two weeks) Test/Deploy 1 (one week) Development 2 Test/Deploy 2 11 January 2016 13
- 14. © 2015-2016 DeLorme Regular deliveries On-time, on-target Reasonably few hotfixes Added 24-hr support: Introduction of Engineer- on-Call (24/7 for one week at a time) 11 January 2016 14
- 15. © 2015-2016 DeLorme Sept 2013: Loss of original PO/Cheerleader Introduction of Dual POs one to focus on strategic partners, upper management, and finance one to focus on consumer/professional customers, Customer Care concerns and UI design With growing product popularity and attention… Three-week deliveries inadequate Everyone wants more responsiveness, including team 11 January 2016 15
- 16. © 2015-2016 DeLorme Introduced the one-week overlapping sprint, with mid-week deployments Team initially had a tendency to under-commit, and then became more aggressive by adding "swapping rule" Result: Many tickets get postponed and swapped out for more important items Most important gets done Some items get postponed 11 January 2016 16
- 17. © 2015-2016 DeLorme Identified problem: Team distractions, requests, emergencies that require technical intervention and research Technical requests sent to the team, Engineer- On-Call triages Feature requests to the POs Bug reports to JIRA if possible API questions directed to forum 11 January 2016 17
- 18. © 2015-2016 DeLorme Began experiment with epics. Dedicate most of team to one long-term project. Eventually, down to one or two staff on a long-term epic. Introduced pull-oriented (Kanban-like) approach. Changes from "sprint-oriented" to "ticket-oriented" No specific commitments PO can/add remove new items, marking highest priorities Team members take new items as they become free At cutoff time: no regrets 11 January 2016 18
- 19. © 2015-2016 DeLorme 6/10/2015 2015Day 1 2 3 4 5 6 7 8 9 10 11 12 PO/SM Ticket Review 6/10/2015 Gen 85 Deployment to Test Estimation Meeting 6/11/2015 Gen 84/85 Demo 6/17/2015 Gen 85 Production Testing 6/17/2015 Gen 85 Retro and Planning 6/8/2015 Gen 85 QA Assessment of Resources 6/12/2015 PO/SM Ticket Review 6/12/2015 Gen 85 Cutoff 6/12/2015 Gen 85 QA Regression Testing 6/15/2015 Gen 85 Deployment to Production 6/17/2015 Gen 85 Closed 6/19/2015 6/8/2015 6/12/2015Gen 85 Development 6/15/2015 6/19/2015Gen 86 Development 11 January 2016 19
- 20. © 2015-2016 DeLorme11 January 2016 20 Google Analytics What’s Up NodePing Loggly PagerDuty Automated Tests NewRelic Octopus TeamCity
- 21. © 2015-2016 DeLorme (Half-time developer) Keep everything in motion. Watch for stuck processes. Anticipate. Keep the chaos at bay. Be vocal about inefficiencies. Do what others don't want to do but needs to get done. Don't make decisions: See that they get made. Don’t micromanage – you are not even a manager. Spread awareness; fill in communication gaps; keep everything visible. Don't interfere with a good thing. Don't expect glory. 11 January 2016 21
- 22. © 2015-2016 DeLorme Low walls All team members in line-of-sight Room for 16 Includes dev, QA, SM, PO/UI Mix of traditional and stand-up desks Conference areas and rooms available 11 January 2016 22
- 23. © 2015-2016 DeLorme As of June, 2015 85 generations, good records for 64 sprints Completed ticket counts: Highest: 67 (six-day sprint) Lowest: 12 (four-day sprint) Note: counts include any "free" regression tickets Story Points (normalized to one week) Average: 88 High: 228 Low: 16 Standard Deviation: 40 (!) How useful are these numbers to the PO? Tickets for the project 8700+ created since September, 2011 ~300 open ~6000 completed/fixed (69%) ~700 duplicate, unreproducible, incomplete ~900 indefinitely suspended/deferred ~800 rejected (won't fix) 11 January 2016 23
- 24. © 2015-2016 DeLorme How does a development team handle day-to- day operations issues? Engineer On Call IT On Call Train/empower: Product Owner Customer Care Technical Sales Support Tier 2 Support? Maintenance Team? 11 January 2016 24
- 25. © 2015-2016 DeLorme Distractions and interruptions Unrealistic stakeholder expectations Adding more work after sprint cutoff Non-agile contracts; custom work Making tickets too big Not letting the team know what's going on Not asking the team for help Working before PO approval Management pressure on the PO (“remote control”) Team wants to decide “what”; POs want to decide “how”; SM wants both Working without a Kanban (ticket) Rushing step to “completion” (code, review, test, deploy) Shiny Object Syndrome Everything can be newer and better (infinite refactoring syndrome) 11 January 2016 25
- 26. © 2015-2016 DeLorme System Traffic and Usage Multiplying Each Year How to Grow? Team Size vs. Customer Base Throughput, Reliability, Cloud, Agents Special project teams Should teams align with architecture? Operations vs. R&D 11 January 2016 26
- 27. © 2015-2016 DeLorme Co-location is Key Teams are self-correcting Visibility breeds assent/approval A responsive attitude is inspiring Empowered teams are awesome 11 January 2016 27