An Agile Journey
How we evolved our Agile organization
from a Feature Factory to Business Teams driven by OKR
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.
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
• Iterative evolution.
• Learning as we grow.
• Adapt to our needs and scale.
• Various states of maturity.
Move to Agile.
Scrum by the Book.
Goals / OKR
* As quoted from Felipe Castro
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
• 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
• 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.
Lean overall approach
Agile production cycle
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.
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.
• How to build an Agile Strategy?
• How do we move to Full-Stack Agility?
• Move away from waterfall / top-down goals.
• Introducing OKR…
Goals / OKR
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
• 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!
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.
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).
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.
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
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.
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
• During the Quarter teams report on their OKR in a standardized way at each sprint review
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.
Legacy Platform Teams
• Originally, platform teams:
• Desktop, iOs, Android, Web Product, Server,
• Works well for small teams. With one line
• Starts hurting as you grow the team and as
• Synchronization issues between platforms
• Inconsistency in product
• Technical focus > Business focus
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
• 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…
• 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
• Changing the way we think about resource allocation and roadmap
Mobility, Flexibility and Taskforces
• Mobility: allow for developers to change teams from time to time.
• Flexibility: adapt resource allocation based on needs.
• 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.
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.
• 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
• Nothing planned yet, but interested in looking into:
• Design Sprint
• Holacracy and other different types of organizations
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.