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
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
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
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
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.
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
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
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!
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
program
• 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,
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
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
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…
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.
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.
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.
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.
Future experiments
• 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.