Presented by Zeineb Bouhejba (Dashlane) et Zakat Cherif (Dashlane) at Agile en Seine on September 20, 2023
Analyze the company processes.
What are the processes/initiatives/tools that are not working (pain points, blockers, bottlenecks…) what is slowing us down, and why.
Analyze what among these processes/initiatives/tools have the biggest negative impact on the company.
Find the best solution (RFC= Request for comment demonstration).
Make the final decision and communicate it (Decision Record demonstration).
Implement change (rollout process,Adoption plan, communication, training, automation, issue bot).
Measure success (Metrics, Feedback, Follow up tasks).
Use case 1: Project: Dashlane SSO
Use case 2: Policy: TAT
3. Presentation
Zeineb Bouhejba
Agile Project Manager
Zakat Cherif
Agile Project Manager
Dashlane: Dashlane offers businesses a password management solution that is as easy to
use as it is secure. Dashlane is used by 20k organizations and 18 million users. We have
offices across New York, Paris and Lisbon.
3
4. Agenda
4
● Validating the problem with data
● Exploring solutions with RFC (Request for comment)
● Taking action with Decision Record
● Implementing change
● Measuring impact
5. How change happens at Dashlane
5
Formalise
the chosen
solution
Implement
the change
Exploring
solutions
Monitor
your
success
metrics
Validate the
problem
6. 6
We are going to present our experience with change management
through a couple of stories and examples that we have done at
Dashlane.
8. 8
How did we know that we needed to solve our
tooling problem ?
● Mapped the process steps and their metrics.
● Identified bottlenecks.
● Conducted a survey to identify pain points.
● Analysed data and key indicators.
10. What is an RFC?
RFCs are used to
● guide open discussion
● stress test the design of a service
● propose a need
● establish new guidelines or processes
● document a commonly used template
● explore options for tools or technologies
10
Definition
● An RFC (Request for Comments) is a standard to gather feedback on
ideas
● RFCs start with curiosity. Where the author would like to learn something
from others
11. Why did we choose to use RFCs
● They make our decision making
easier
11
● They allow space for exploration, welcome collaboration and make our
async collaboration easier
● They improve how we engage with each other and allow crowdsource
from collective knowledge
● They are designed for our distributed
organisations that need to scale
12. Lifecycle of an RFC at Dashlane
Start by drafting
your idea
individually first.
Find experts or
invested
stakeholders to co-
author with
Gather feedback
from those
impacted and
interested in the
change
Close the RFC
once you got
what you were
looking for
12
Draft
Calling for
Authors
Closed for
comments
Open for
comments
Publish Promote Learn
13. RFC of the 30 days bugs policy
13
What I need from audience
1. Read through Problem Statement, Goals & Non-Goals and Options
2. I need you understand what knowledge I'm missing
3. Provide feedback on the options put forth
4. Provide alternative opinions, past experiences, and examples you can share
Problem Statement:
■ Policy's goals not understood by some teams.
■ What some teams hear is "you need to fix your bugs within 30 days, or close them"
■ teams are hearing "you have to do X" instead of "Here are our goals, do what you have to do to reach
those"
■ Policy doesn't work for some bugs
■ Some bugs are highly valuable but are not actionable in the short term. Sometimes teams need to
do long investigations, or wait for similar issues to be able to fix the root cause.
■ Policy leads to dark patterns making metrics unreliable
■ Sometimes, when teams see a bug that is relevant, but cannot be prioritized it in the next sprint (for
any reason), they can change the ticket type to "task" to no longer be counted as a "bug"
14. 14
Goal:
Iterate on our bug treatment strategy to make it:
■ better adopted by teams → to avoid policy shortcuts and provide more reliable metrics
■ more efficient → to identify and address root challenges teams might have.
Proposed Solution:
Focus on the goals of our strategy, not on the suggested approach. Both in terms of communication and success
measurement.
■ Clarify our bug treatment strategy in a simpler way (the current page is very long, too detailed, most
Dashlaners won't read it)
■ Find another name for this policy, to move away from the "30 days bug backlog policy" which focuses too
much on the suggested approach
■ We suggest four metrics to measure the outcome of the policy, a main pair to be used for broad
communication, and a secondary to get a deeper analysis of the backlog health.
a. Bug-backlog evolution over month.
b. Fixed vs all bugs ratio.
16. Decision Record of the Gitlab Migration
16
Context - background for why a decision has been made (1 DR page per decision)
Decision Drivers - the criteria you want to follow when comparing your solution options.
● Decision Driver 1 Operational simplicity
● Decision Driver 2 - Cost efficiency
● Decision Driver 3 - Accessible insights
● Decision Driver 4 - Improved security
Considered Options - At least 2 additional alternatives that were explored in addition to your
preferred option
Option A: moving to Jira Cloud
Option B: moving to Gitlab ultimate
Option C: staying on Jira Server
Pros and cons for each option
17. 17
Decision outcome -
simplified rationale behind the decision referring to the most relevant criteria used to this decision. Add any
important description of how the decision will be executed here (not detailed execution plan or following
tech specs).
Option B: We will be using GitLab as a work management tool as part of our upgrade to
the Ultimate tier.
Consequences - how will this decision affect the status quo.
Summary of the consequence for the decision, with a comparison between Gitlab and Jira
19. Before we begin creating the communication plan, we answered these questions to
ensure that you have all of the relevant information:
● Project stakeholders.
● Communication frequency and method.
● Goals.
● Barriers.
Communication for SSO Migration
19
20. Communication - other Example for the Gitlab
Migration
● Goal of project: Transitioning From Jira to Gitlab.
20
● We created Slack channel, specifically for the migration. Where we communicated with everyone updates
weekly and answered questions.
● Town hall - Product and Eng all hands.
21. Rollout Process for SSO migration
● Breakdown of a rollout process for SSO Migration.
○ Pre-rollout preparation.
○ Pilot testing.
■ Selection of the pilot group.
■ Training.
■ Feedback Collection.
● Importance of a rollout process.
21
22. Rollout Process - Example of the Gitlab migration
○ We created documentation like Team JIRA to Gitlab migration process
■ Where we answered these questions:
● What is being migrated.
● What is the migration plan.
● Migration timeline for each team, point of contact and detailed SQL
queries.
○ We started Pilot testing, with an engineering team and documented all migration
issues.
22
23. Adoption plan
● Breakdown of an adoption plan for SSO migration:
○ how did we understand our team.
○ We created support system made of champions.
○ Live skill preparation session.
○ Feedback loop after each session
○ Acknowledgment in SI Praise.
23
25. ● Example for Gitlab Migration: we measured the adoption rate
by counting the number of tickets were created after one Week.
○ Adoption rate.
○ User proficiency.
○ Productivity metrics.
○ Compliance metrics.
Measure success for Gitlab Migration
25
26. Let’s recap!
26
● Validating the problem with data.
● Exploring solutions with RFC (Request for comment).
● Taking action with Decision Record.
● Implementing change.
● Measuring impact.