The Dashlane Agile Journey
4 likes2,872 views
The document describes an agile journey at Dashlane from 2014-2017 as they evolved from feature-focused teams to business-focused teams driven by objectives and key results (OKRs). Initially they used scrum but later adopted more scrumban practices. They introduced roadmaps, portfolios, and OKRs to align strategy, tactics, and operations. Transitioning to business teams and OKRs was challenging but improved business focus, alignment, and delivery of value. Ongoing work includes refining OKRs and supporting processes to continuously improve.
The Dashlane Agile Journey
- 1. An Agile Journey How we evolved our Agile organization from a Feature Factory to Business Teams driven by OKR
- 2. My name is Frédéric Rivain, CTO of Dashlane. We build a Password Manager, to help you manage your identity and your payments in a simple and secure way everywhere.
- 3. A bit of context Funded in 2009 by Bernard Liautaud and 3 Centrale students 110 employees in Paris and New York • Product & Engineering in Paris • Marketing & Sales in New York 4 business lines: • Consumer product (B2C) • Enterprise offer (B2B) • Financial Partners • API and Dev Ecosystem • 7 “production” teams
- 4. Agile timeline • Iterative evolution. • Learning as we grow. • Adapt to our needs and scale. • Various states of maturity. Garage Mode 2014 Move to Agile. Scrum by the Book. Roadmap & Portfolio 2015 OKR Feature Teams 2016 2017
- 5. Half-Baked Agility* Operations Tactics Strategy Culture Agile Development Scrum, Kaban… Lean Goals / OKR 1 2 3 4 * As quoted from Felipe Castro
- 7. 1. Agile methodology at the team operational level • We started from Scrum. A lot by the book. • Today we evolved into more of a Scrumban mode in many teams. • Key shared principles between all teams: • 2-week cadence for all teams • 3 clearly identified roles • Product Owner • Scrum Master (possibly rotating among team members) • Business Stakeholders • Regular stand-ups • Review at the end of each cycle, with team + stakeholders + everybody interested
- 8. 2. Tactics • Scrum is about operational agility. A methodology for day-to-day organization. • Wrap the Scrum cycle with a Lean process, to improve Alignement and Visibility at Company level. Formalize the Project Collaborative Specifications Development Validation Release to Production Assess results Evaluate and prioritize AGILE PRODUCTION Stakeholder Lean overall approach Agile production cycle
- 9. 2. Roadmap & Portfolio • Introducing 2 tools, inspired from SAFe framework, influenced by Lean approach • A portfolio = a high-level view of all our projects at Dashlane. Live board in Jira. At any point in time, you can know everything that is being worked on by the teams. • A quarterly Roadmap = a view by team, by quarter, by objective. Linked dynamically to the Portfolio. Provides vision, consistency and alignement.
- 10. 2. The perfect Feature Factory • Build Project-driven roadmaps • Track feature delivery • Only Agile at the Operations level and partially at the Tactics level. • Strategy is based on annual goals with overall top-down planning.
- 11. 3. Strategy • How to build an Agile Strategy? • How do we move to Full-Stack Agility? • Move away from waterfall / top-down goals. • Introducing OKR… Operations Tactics Strategy Culture Agile Development Scrum, Kaban… Lean Goals / OKR 1 2 3 4
- 12. 3. OKR – Objective & Key Results • A framework of defining and tracking objectives and their outcomes • Created by Intel, in the 1970s • Made popular by John Doerr and Google • Adopted by most Silicon Valley companies
- 13. 3. OKR Components • O = Objective: • Aspirational. • Memorable – Simpler, shorter, remarkable. • Qualitative. • KR = Key Results: • 2-5 per Objective. • Quantitative & Measurable. • Metrics (recommended) or Milestones.
- 14. OKR Example • Objective: Delight our customers • Key Results: • Increase average weekly visits from 3.1 to 3.3 per active user • Improve Net Promoter Score from 46% to 52%. • Increase non paid (organic) traffic from 70% to 80%. • Increase engagement (users that complete a full profile) from 60% to 75%. • Objective: Taming the Autofill Dragon • Key Results: • Achieve successful autologin on the top 50 Chinese websites • Achieve successful autologin on the top 50 Korean websites O can be fun!
- 15. 3. Dashlane OKR • Yearly Company OKR – High-Level Strategy • KR can be reviewed and adapted every quarter or as needed. • But O should theoretically remain stable in time • Team Quarterly OKR – Tactical Short Term • Impacting Company OKR • No individual OKR, by choice.
- 16. 3. The move to OKR • It is hard, for everybody but especially for engineering. • Big change of mindset: • Focus on business impact and value first • Projects come second. • In theory, delivering a feature does not really count for success. • Need to be very data-driven. • Need to accelerate massively the cycle time and release process. • Need experimentation tooling such as strong A/B Test Engine and Feature-Flipping. • Need to shift to a more bottom-up process (~60% bottom-up, ~40% top-down).
- 17. 3. Our first Fails • Too many OKRs per team. • Way way too ambitious. Aim for roofshots, not moonshots. • Team not capable of measuring a KR. • We should decide faster in a Quarter to drop a KR. • Bottom-up is hard also for the teams. • Several quarterly cycles before it starts becoming easier. • Need to manage the feeling that OKR are bullshit.
- 18. 3. Link between OKR & Roadmap • We still have projects and features. • But they are mostly defined to achieve goals as set by OKR. • Not all projects are associated to OKR. Quarterly OKR Quarterly Roadmap
- 19. 3. Slice the Elephant • With OKR, it is even clearer that you need to split big projects. • Ship fast, Experiment, iterate. MVP / Skateboard approach. • For big projects, adapt KR to be more technical KR or learning KR.
- 20. 3. Our OKR-Roadmap process today • One month before beginning of the quarter, the Lead Stakeholder & Product Owner kick off the OKR & Roadmap process: • Get input from the team • Get input from the stakeholder(s) • Get input from the exec team • Agree on the MUST HAVE of the quarter so that specs can be ready from D1 of the quarter. • PO & Lead Stakeholder prepare high level guidelines that are validated by exec team • Last 2 weeks of the previous quarter are dedicated to OKR & Roadmap definition for each team: • PO needs to provision some sprint time to allow the teams to focus on the process • Drafting is documented on Confluence to allow iteration / back & forth with stakeholders etc. • OKR are ready at the end of the 2 weeks: • Both O & KR properly worded • Metrics baseline & target are agreed upon • Tracking & reporting enabled • Mapping with Company OKR done • Feedback from stakeholders has been taken into account • Roadmap at the end of the 2 weeks: • all teams prepare a confluence page summarizing their OKR and the related portfolio projects for the quarter • Exec team meets and goes over each team's OKR/Roadmap page to challenge teams and sign off on the Quarter's program • During the Quarter teams report on their OKR in a standardized way at each sprint review
- 21. 3. OKR learnings • Don’t be too ambitious, else teams get frustrated with unreachable goals. Roofshots rather than Moonshots. • Have fewer O and KR rather than too many. Otherwise you loose focus. • Not all projects/initiatives are related to OKR. • Allow for different types of KR: • Learning metrics • Business metrics • Possibly technical metrics • Time those KR based on the current progress and based on the outcome you are looking for. Learning first before optimizing and impacting business for instance.
- 23. Legacy Platform Teams • Originally, platform teams: • Desktop, iOs, Android, Web Product, Server, Semantic Engine • Works well for small teams. With one line of business. • Starts hurting as you grow the team and as you diversify: • Synchronization issues between platforms • Inconsistency in product • Technical focus > Business focus
- 24. Moving to Business/Feature Teams • Inspired by the Feature Teams model (a la Spotify) • Applied to the Dashlane context • Cross-functional teams including: • Product, Development, QA + Design, Analytics, Product Marketing, User Support • « Mini Startup » inside the company, with end-to-end responsibility on their business scope. Associated closely to business stakeholders. • 7 teams including • 3 focused on end-user: Acquisition, Conversion, Retention • 2 focused on B2B • 1 for Partnerships • 1 to make use of our semantic engine
- 25. Managing change • Work closely with all team members to define the target, when and how • Do it when you have enough of each skill to make it sustainable. • We decided for a Big-Bang switch between 2 quarters. 1 full week dedicated to the switch. • Take your time to prepare. • Use the opportunity for team building, training. • Communicate, communicate, communicate… • Listen, listen, listen…
- 26. Side impacts • Thinking Platforms + Teams • Manage platform organization: • Need more communication • Organizing tech work in « Platform Days » • Adaptations to the Release Process and the way all teams coordinate. • New management style for Tech Leads, with engineers distributed in various teams. • Changing the way we think about resource allocation and roadmap definition.
- 27. Mobility, Flexibility and Taskforces • Mobility: allow for developers to change teams from time to time. • Flexibility: adapt resource allocation based on needs. • Taskforces: • Some projects don’t fit in a team. • Plan it from the start as part of the process. • Create short-lived taskforces with a clear project goal.
- 28. Then what ? • The easy part is the switch. Fun and exciting time. • The hard part follows: making it work. • Changing our way of working to optimize the new organization. • Be patient. It takes time. • Inspect and adapt.
- 29. The Future
- 30. Tuning time • We are still learning as we do. • Tuning OKR to make them more efficient. • Identifying friction points. • Overcoming obstacles • Improving the foundations that support our organization • Data: stronger and more real-time analytics • Product: adapting the way we design product • Technical: strengthening and accelerating our release pipeline. Industrializing and automating.
- 31. Future experiments • Nothing planned yet, but interested in looking into: • Design Sprint • Holacracy and other different types of organizations
- 32. Final Words of Advice
- 33. Tips and Tricks • Invest time to get support from both the Top and the Bottom: from Execs to Team members. Convince before doing. • Each change is hard as it is. You need everybody to be on board. • There are strong prerequisites to all these evolutions • Data: strong analytics • Product: each change has an impact in the way you design product • Technical: having a smooth and fast release pipeline is key • Culture: be ready for change. • Learn as you go and adapt to your company maturity. • Adapt to your own context.
- 34. Questions ?
- 35. References • OKR • http://felipecastro.com/en/okr/what-is-okr/ • https://www.slideshare.net/meetfelipe/slides-agile2016-stop-using-agile-with-waterfall- goals-goal-agility-with-okr • https://medium.com/the-alignment-shop/the-okr-journey-a-guide-for-okr-adoption- beb775ca2a5a • Feature Teams • https://www.slideshare.net/JoakimSunden/agile-at-spotify • https://www.slideshare.net/ashlychrstn/full-stackagile-squads-chapters-tribes-and- guilds • https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
- 36. Thank you © 2017 Dashlane, Inc