A proposed framework for Agile Roadmap Design and Maintenance

1
© Jerome Kehrli @ niceideas.ch
A proposed framework for
Agile Roadmap Design and Maintenance

3
We are not going to end up with this…
(I
am
not
saying
this
doesn’t
work,
but
it
definitely
doesn’t
work
for
us)

4
Aligns with company strategy, rallies all around this and steers us towards
delivering on this strategy
Focuses on delivering customer value & articulating benefits
Excites our customers about our company & product direction
Reflects what we have learned, over time, as an organisation
Does not pretend to have all the answers, or indeed need to
Characteristics of a Good Roadmap
Done well, a roadmap is a strategic communication tool,
a statement of intent and direction
© Roy Belchamber @ NetGuardians

5
Excessive granularity – too much focus on detail and dates means it will
inevitably soon be inaccurate or even obsolete!
Mistakenly thinking every item in the roadmap demands upfront design and
estimation – this is impossible & wasteful
Believing each stakeholders must personally value every item
Ensuring our roadmap is not conflated with our product release plan!
Potential Pitfalls
It is possible to set clear direction & simultaneously
embrace uncertainty inherent in product development
© Roy Belchamber @ NetGuardians

6
The Roadmap as a Strategic Tool
Elements
Product Vision
Timeframes
Themes
Business Objectives
* Disclaimer
Focus on
outcomes
(strategic)
not on
outputs
(tactical)
A good roadmap starts
with a vision of where we
are going, guides us there
and explains the stops
along the way… Outcomes
Roadmap
Now Next Later
Backlog
Outputs
Backlog
Backlog
Backlog
Inspired from Roy Belchamber @ NetGuardians

7
The Roadmap Illustrated
Elements
Product Vision
Timeframes
Themes
Business Objectives
* Disclaimer
PRODUCT VISION
RIA Organizer providing UX of Desktop applications
Our product vision is our
guiding principle

8
Elements
Business Objectives
Timeframes
Product Vision
Themes
* Disclaimer
PRODUCT VISION
H1/2021 H2/2021 2022 Future
Broad timeframes avoid
overcommitment -
It is the sequence that
matters (now, next,
future)

9
Elements
Product Vision
Timeframes
* Disclaimer
PRODUCT VISION
H1/2021 H2/2021 2022 Future
Email CRUD
Focus on outcomes not
outputs. Themes are not
granular features and
functions
Email Search Attachment
Management
RTF Emails and
appointments
description
HTML Emails
and
appointments
Scheduler
Genius
Cal. Search
Contact Search
Contact CRUD
Calendar CRUD
Business Objectives
Themes
Outlook
compatibility

10
Elements
Product Vision
Timeframes
Themes
Business Objectives
* Disclaimer
PRODUCT VISION
H1/2021 H2/2021 2022 Future
What goals will our
product accomplish?
What outcomes?
Email CRUD
Email
Management
MVP
Email Search
Google-like
experience on
emails
Cal. Search
Google-like
experience on
appointments
Contact Search
Advanced
Contacts
Management
Contact CRUD
Contact
Management
MVP
Calendar CRUD
Calendar
Management
MVP
Attachment
Management
RTF Emails and
appointments
description
HTML Emails
and
appointments
Scheduler
Genius
Outlook
compatibility

11
PRODUCT VISION
H1/2021 H2/2021 2022 Future
Protects against claims of
broken promises by
explaining that changes
can happen
Email CRUD
Email
Management
MVP
Email Search
Google-like
experience on
emails
Cal. Search
Google-like
experience on
appointments
Contact Search
Advanced
Contacts
Management
Contact CRUD
Contact
Management
MVP
Calendar CRUD
Calendar
Management
MVP
Attachment
Management
RTF Emails and
appointments
description
HTML Emails
and
appointments
Scheduler
Genius
Outlook
compatibility
Elements
Product Vision
Timeframes
Themes
Business Objectives
* Disclaimer
* Updated 30 April 2021, subject to change without notice

12
R&D
The Hierarchy…
What
Why How
Why we are doing this?
Why it aligns
with our strategy
What customer problems
will we solve?
Finally, how should
we solve it?
Roadmap
Now
Need
Next Later
Product Mgmt
Backlog
Backlog
Backlog

13
Let’s have a look at something more realistic

14
An Outcome-Based Roadmap – How it Could Look
PRODUCT VISION
Product Vision Statement
Outcome Roadmap - Up To 2023
Team May Jun Jul -Q3/2021 Q4/2021 H1/2022 H2/2022 2023
Research
Analytics prototype 1 Analytics Research 1 Analytics Research 2 Analytics Proto. 2 Analytics Res. 3
Software Technology Research 1 Software Technology Research 2
Dev
FT
1
H2 Evolution 1
Project C Gaps Project E Gaps
H2 Evolution 4
H1 Evolutions batch 4
Dev
FT
2
Project A Gaps H2 Evolution 3
H3 Evolution 3
H1 Evolutions Batch 1 Project D Gaps
Dev
FT
3
Project B Gaps
H3 Evolution 1
H1 Evolutions Batch 2
Dev
FT
4
H2 Evolution 2 H3 Evolution 2
H1 Evolutions Batch 3 Project E Gaps H2 Evolution 5

15
An Outcome-Based Roadmap – How it Could Look
PRODUCT VISION
Research
Dev
FT
1
H2 Evolution 1
H2 Evolution 4
Dev
FT
2
H3 Evolution 3
Dev
FT
3
Project B Gaps
H3 Evolution 1
Dev
FT
4
CERTAINTY &
CONFIDENCE
DISCOVERY /
UNSCHEDULED

16
What we will be discussing now …
•
What
are
these
teams
?
•
How
are
they
organized
?
• How is the Roadmap managed and evolved ?
• What is a good update frequency ?
• What is the level of commitment ?
• What are these items on the Roadmap
• What is H1 / H2 / H3 ?
• How are epics estimated ?
D
A
B
C

18
2.A - Agile Software Development Teams

19
Reliable forecasting …
The whole game is :
How to build a team with
- A culture
- An organization
- set of practices and principles
that makes estimations and forecasting reliable ?

20
Agile Prerequisites
Maturity
/
Difficulty
Agile Development
(e.g. Scrum)
DevOps
Lean Startup Company-wide
Kanban / Kaizen
Scaling Agile /
Agile corporation
XP Practices
Digital
Transformation
Dependency

21
Where you should be
Maturity
/
Difficulty
Agile Development
(e.g. Scrum)
DevOps
Lean Startup Company-wide
Kanban / Kaizen
Scaling Agile /
Agile corporation
XP Practices
Digital
Transformation
Dependency

22
Periodic Table of Agile Principles and Practices
https://www.niceideas.ch/roller2/badtrash/entry/periodic-table-of-agile-principles

23
Direct relationship with planning / road-mapping abilities

24
Well actually you need them all
➔ Even only within XP, they all depend on each others
XP Practices dependency Graph

25
“If it hurts, do it more often”
Firstly most of these tasks
become much more difficult as
the amount of work to be done
increases, but when broken up
into smaller chunks they
compose easily.
The second reason
is Feedback. Much of agile
thinking is about setting up
feedback loops so that we can
learn more quickly.
The third reason is practice.
With any activity, we improve
as we do it more often
Small releases / Deploy More Often

26
Tests are not optional. There is no continuous delivery without tests. There is no easy
release process without continuous delivery. There is no reliable forecasting with stop the
world releases.
80% is not an appropriate target anymore, the target is 100% !
Tests, tests and more tests
Commit
Build
Nightly
Build

27
Why TDD ?
This can be
estimated (SP)
We need to be able to predict the time things will take. Story Points and the whole Scrum approach are terrific for this.
However none of it works if most of the development workload is fundamentally unpredictable
Here comes TDD !
This can be
estimated (SP)
https://www.niceideas.ch/roller2/badtrash/entry/tdd-test-driven-development-is

28
Product Owner = onsite customer
Don’t rely on external teams / processes for specification and prioritization
➔ Independent and Autonomous teams
Get access to business expertise immediately
Streamline and flatten Acceptance Testing
Get feedback immediately
The Product Owner is able to definitely close a task without any dependency outside of the team.
No “stop-the-world” pre-release Acceptance Test campaign
Planning Game with Story Points (no man / days !)
Transform a difficult estimation process – What is the weight of this stone ?
Into an easier comparison process – Is this stone lighter or heavier than this
other stone?
Planning Poker : consensus-based, gamified technique for estimating
effort (relative size) of development goals
force people to think independently and propose their numbers
simultaneously
Onsite customer and Planning Game

29
XP – Take Aways
The Product Owner - on-site customer - enables the
team to be autonomous and work without interruption
by answering questions (refined specifications)
immediately and running acceptance tests continuously
Acceptance tests / Feedback
Refined specifications
(DevOps) Continuous Delivery – small releases -
enables to avoid Stop-the-world Releases breaking
teams autonomy and forcing killing synchronization
events
Stop
the
world
Release
N
Stop
the
world
Release
N
+
1
TDD enables to have reliable forecasts by bringing most
of the development team workload to actual
development time that can be estimated (vs.
unpredictable nasty debugging session, patches and
fixed round trips, etc.)
The Planning Poker Estimation Game – planning game – enables to have reliable
estimations and forecasting abilities (surprisingly much more that traditional waterfall)
X
X

30
The Lean Startup
1
Customer
Discovery
2
Customer
Validation
3
Get new
Customers
4
Company
creation
Identify
a problem
Generate
demand
Design / Implement the
Minimum Viable product
Re-adapt the product
Problem
Interview
Solution
Interview
A/B
Testing
Measure
Obsession
Pizza
teams
Build
Vs.
Buy
Feature
Teams
Get out
of the
Building
Scaling
Agile
MVP
Fail Fast
Growth Hacking
Gamification / Viral
Marketing
...
Pivot
Get out
of the Building
Product-
Market
Fit
https://www.niceideas.ch/roller2/badtrash/entry/lean-startup-a-focus-on

31
Small Teams
As team size grows, the number of one-on-one communication
channels explodes, following the formula to compute number of
links between people which is n ( n - 1) / 2 .
This is O(n2) (Hello Engineers) and is really a combinatorial explosion.

32
Introducing Feature Teams
(Source : Large Scale Scrum : http://less.works/)

33
The characteristics of a feature team are :
long-lived—the team stays together so that they can ‘jell’ for higher performance; they take
on new features over time
autonomous and independent – no friction with other team
complete - support, UI/UX, DevOps
cross-functional and cross-component
ideally, co-located
work on a complete customer-centric
feature, across all components and
disciplines (analysis, programming,
testing, …)
Multi-competencies
in Scrum, typically 7 ± 2 people
Feature Teams

35
Component Teams vs Feature Teams
Component Team Feature Team
optimized for delivering the maximum number of lines of code optimized for delivering the maximum customer value
focus on increased individual productivity by implementing ‘easy’ lower-
value features
focus on high-value features and system productivity (value throughput)
responsible for only part of a customer-centric feature responsible for complete customer-centric feature
traditional way of organizing teams — follows Conway’s law ‘modern’ way of organizing teams — avoids Conway’s law
leads to ‘invented’ work and a forever-growing organization leads to customer focus, visibility, and smaller organizations
dependencies between teams leads to additional planning minimizes dependencies between teams to increase flexibility
focus on single specialization focus on multiple specializations
individual/team code ownership shared product code ownership
clear individual responsibilities shared team responsibilities
results in ‘waterfall’ development supports iterative development
exploits existing expertise; lower level of learning new skills exploits flexibility; continuous and broad learning
works with sloppy engineering practices—effects are localized requires skilled engineering practices—effects are broadly visible
contrary to belief, often leads to low-quality code in component provides a motivation to make code easy to maintain and test
seemingly easy to implement seemingly difficult to implement

36
Product 3
Product 1 Product 2
Component Team vs Product Teams ?
Feature teams work tremendously good … within a product !
Having different set of teams for different set of products is mandatory
(business vs. technical specialization)
Product Teams
UI / UX
Java backend
Data Science / Research
Java backend
UI / UX
Java backend
Data / DB
Data Science
Operators
Component Teams Model
Product 3
Product 1 Product 2
FT1
Data Science / Research
FT1
FT2
FT3
FT4
Feature Teams Model
FT2
FT3
Data Science

37
Squads
Equivalent to a Scrum
Team
As Autonomous as possible
Tribes
Same office < 100 FTE
Common area of the system
(product)
Organized for minimum
interdependency
Chapters
Skills community
(community of practices)
Chapter lead is line
manager
Guilds
Community of interest
Cross tribe groups
Guild unconferences
The Spotify Way
Squad Squad Squad Squad Squad Squad Squad Squad

38
Lean Startup – Take Aways
One
wants
as
many
independent
teams
as
required
to
run
independent
topics
in
parallel
Dev Teams should never ever be exposed to customers directly, they do 3rd level support
only
Custo-
mer
Deploy.
Refined
design
Most of the time, a team should have 1 or 2 core focus at a time,
typically a long term focus and some more short term fillers.
Support Functions : Customer 1st level support, 2nd level support, HR, Management, etc.
A feature being given to 1 autonomous team, and that team being able to
work without interruption, Team Sprint Velocity enables to do forecasting.
A Feature Team implements a Feature from A to Z, where Z is release / deployment to the customer,
independently and autonomously.
The rule is : as soon as a team has any dependency on another team, estimations and forecasts are not
reliable anymore ! (multi-team consolidated planning and forecasting is a much more difficult game !)
A to Z includes everything: 3rd level support, documentation, automated tests, code review, IT testing,
Acceptance Testing, Release, Deploy, Deployment automation, etc. ➔ EVERYTHING (… DoD)
Because the team is autonomous and independent, it’s own planning and forecasts are reliable.

39
DevOps
https://www.niceideas.ch/roller2/badtrash/entry/devops-explained
Developer Operator

40
DevOps in a nutshell
Key
For
Planning

41
Infrastructure as Code
Cloud,
Container or
VM
Instantiation
OS
Installation
System
Installation / Configuration
Application / Service
Deployment / Orchestration
• Capistrano
• Scripts / Python
• Jenkins
• Maven
• Specific tools
• Chef
• Puppet
• Ansible
• Red Hat Satellite
• Vagrant
• OpenStack
• VMWare Vcloud
• Docker
• OpenShift
• ExaLogic
• Kubernetes
CMDB
-
Configuration
Management
Database
(All
of
this
is
versionned
under
SVN,
git,
…)
Application Deployment
Deploy application code
… and rollback
Configure resources (RDBMS,
etc.)
Start applications
Join clusters
System Configuration
JVM, app servers …
Middlewares …
Service configuration (logs,
ports, user / groups, etc.
Registration to supervision
Machine Installation
Virtualization
Self-Service environments

42
The more often you deploy, the more you master the deployment process and the better you
automate it. If you have to do something 3 times a day, you will make it bullet proof and reliable
soon enough, when you will be fed up of fixing the same issues over and over again.
The more often you deploy, the smallest will be the changesets you deploy and hence the smallest
will be the risk of something going wrong, or the chances of losing control over the changesets
The more often you deploy, the best
will be your TTR (Time to Repair /
Resolution)
Key for Planning !
You don’t want to loose time on Deployment
You want deployment to be automated
You want deployment and production release to
happen without you even noticing
Key to avoid multiple team synchronization
Continuous Delivery – “If it hurts, do it more often”
(Source : Ops Meta-Metrics: The Currency You Pay For Change -
http://fr.slideshare.net/jallspaw/ops-metametrics-the-currency-
you-pay-for-change-4608108)

43
Continuous integration of both the software components development as well
as the platform provisioning and setup.
TDD - Test Driven Development. This is questionable ... But in the end let's face
it: TDD is really the single and only way to have an acceptable coverage of the
code and branches with unit tests (and unit tests makes is so much easier to fix
issues than integration or functional tests).
Code reviews ! At least code reviews ... pair programming would be better of
course.
Continuous auditing software - such as Sonar.
Functional testing automation on production-level environment
Strong non-functional testing automation (performance, availability, etc.)
Automated packaging and deployment, independent of target environment
Continuous Delivery requirements

44
"Zero Downtime Deployment (ZDD) consists in deploying a new version of a system without any
interruption of service.“
ZDD consists in deploying an application without interruption of service
in such a way that one introduces a new version of an application to production without making the
user see that the application went down in the meantime.
From the user's and the company's point of view it's the best possible scenario of deployment since
new features can be introduced and bugs can be eliminated without any outage.
I'll mention 3 techniques:
Feature Flipping ➔ Key for Continuous Deployment
Shippable version at the end of every sprint
Multi-sprint developments become possible without harming Continuous delivery
Blue/Green Deployments
Canari release
Zero Downtime Deployments

45
Feature flipping allows to enable / disable features while the software is running. It's
really straightforward to understand and put in place: simply use a configuration properly
to entirely disable a feature from production and only activate it when its completely
polished and working well.
For instance to disable or activate a feature globally for a whole application:
Or if one wants to do it on a per-user basis:
Feature flipping

46
Blue/Green Deployments consists in building a second complete line of production for
version N + 1.
Both development and operation teams can peacefully build up version N + 1 on this second
production line.
Whenever the version N + 1 is ready to be used, the configuration is changed on the load balancer
and users are automatically and transparently redirected to the new version N + 1.
At this moment, the production line for version N is recovered and used to peacefully build version
N + 2.
And so on.
Blue/Green Deployments
(Source : Les Patterns des Géants du Web – Zero Downtime
Deployment - http://blog.octo.com/zero-downtime-
deployment/)

47
Canari release is very similar in nature to Blue/Green Deployments but it addresses the
problem to have multiple complete production lines.
The idea is to switch users to the new version in an incremental fashion : as more servers are
migrated from the version N line to the version N + 1 line, an equivalent proportion of users are
migrated as well.
At first, only a few servers are migrated to version N + 1 along with a small subset of the users. This
also allows to test the new release without risking an impact on all users.
When all servers have eventually been migrated from line N to line N + 1, the release is finished and
everything can start all over again for release N + 2.
Canari Release
(Source : Les Patterns des Géants du Web – Zero
Downtime Deployment - http://blog.octo.com/zero-
downtime-deployment/)

48
DevOps – Take Aways
Custo-
mer
Deploy.
Automated tests – End-to-End tests – on
integration and tests environment are
key to avoid debugging sessions and
production regressions.
Infrastructure as Code enables to
streamline and automated end-to-end
tests on production-like test
environments and is key to Continuous
Delivery.
Finally, Automated tests should validate
non-functional requirements.
Stop
the
world
Release
N
Stop
the
world
Release
N
+
1
Releasing / Deploying to customer has to be a marginal, one-day, push-a-button event.
Continuous Delivery techniques are absolutely key to avoid stop-the-world releases / deployments
which breaks the team independence and autonomy, which, again, is absolutely key to have accurate
forecasts.
Just as TDD eliminates unpredictable development-related tasks, Continuous Delivery and ZDD
techniques enable to eliminate unpredictable deployment-related tasks.
X
X

49
2.B – The 3 Horizon Framework

50
Business Economics
The need for innovation
Technological
Progress
Cumulative
Effort
Technology S-curve
Technology Profit Curve
Profit
Time

51
The 3 Horizon model (McKinsey)
The 3 horizons model is a growth strategy framework by McKinsey that you can use to
think about the future of your company.
Value
Time / Effort
H1
1-2 years
H2
2-4 years
H3
3-5 years
Technology
S-curve
Technology
Profit
Curve
Horizon 1
Maintain & strengthen
core business
Horizon 2
Explore & discover emerging
expansions / opportunities
Horizon 3
Create genuinely new businesses
/ competencies / possibilities

52
The 3 Horizon model (McKinsey)
Value
Time
H1
H2
H3
Horizon 1
Maintenance, functional
evolutions, Project Gaps
The first horizon involves
implementing innovations
that improve current
operations
Horizon 2
Product & Technology
Evolutions
Horizon 2 innovations are
those that extend your
current competencies into
new, related markets.
Horizon 3
Disruption, new
technologies, new product
Horizon 3 innovations are
the ones that would change
the nature of your industry
and generate new
competencies
NG : now – 18 months
NG : 6 – 24 months
NG : 1 – 3 years

53
A sound approach to Product Management
Value
Time
H1
H2
H3
NG : now – 18 months
NG : 6 – 24 months
NG : 1 – 3 years
Current
Backlog
H1
H1
H1
H1
H1
H1
H1
H1
H1
H1
H1
H1
H2
H2
H2
H2
H2
H2
H2
H2
H2
H3
H3
H3
H3
H3
H3

54
3 Horizon Framework – Take Aways
Multiple
Teams
enable
to
spread
workload
among
the
3
horizons
(fair
share)
Some epics / stories - often related to projects - can
sometimes not be estimated properly because the scope is
blurry. In this case we take reserve.
Some backlog fillers - small tasks - are used to fill in the gaps
Type of Stories / Epics on the roadmap
- Product evolutions (PMC)
- Functional evolutions (PMC, BA, PO)
- Technology evolutions and maintenance (CTO)
- Projects Gaps (Delivery)
- Evolution / Improvement batches (Delivery, Sales,
R&D, etc.)
➔ Granularity has to be "large topics" or "important
topic" or customer / delivery commitments
Multiple small tasks in H1 – delivery wishes, minor bug corrections,
cosmetic changes, UX improvements, small evolutions – etc, are grouped
together by theme and scope in an Evolution batch.
The Evolution batch is then prioritized and scheduled as a consistent unit.
Have the Teams switch / rotate between H1 / H2 /
H3 to avoid frustration

55
2.C – The Estimation Process

56
Key Product-related Roles
Product Manager(s)
➔ Marketing / Corporate Function
• Product Marketing / Market
studies
• Voice of customers / market
• Animates PMC
• Roadmap Maintenance
• Story Map
Product Owner(s)
➔ Dev Team Function
• Represents / Liaise with PMC
• Business Analysis
• Acceptance Tests
• Release Management
• Backlog prioritization
• Release Notes
• Development Story Specification
Team Leader(s)
• Liaise with Product Owner
• Fill-in Team Sprint backlog
• Animates team rituals
• Dev Team Management
(People Management)
Architect(s) / UX / Data Science
• Functional / Application Architecture
• Technical / System Architecture
• User Experience
• Data Architecture
• Epic Specification
• Epic Breakdown in Dev Tasks
• Tasks Estimation
Tech Lead
• Application / Technical Design
• Developer support
• Epic Specification
• Epic Breakdown in Tasks
• Tasks Estimation
Developers…
• Full-stack development
• Operation Automation
• Deployment Automation
• Documentation
• Support
CTO
- Architecture Lead
- Voice of technology
- Software Development
Methodology guarantor
- Cloud Operations Management
- Animates ARCHCOM
+ of course 1st Level support / 2nd Level support / Scrum Master / Perhaps Cloud Operations / etc.

57
Key Rituals
Product Management Committee - PMC
Product
Manager(s)
Product
Owner(s)
Head of
Sales
CTO
Preparation: PM collects opportunities and needs
Walkthrough:
Promote / Eliminate / Prioritize
Evolutions
Offline: PM prepares User stories
Offline: later, continuously, collect estimations then
update roadmap
Architecture Committee - ARCHCOM
Preparation: CTO and Product Owner creates Epics
corresponding to stories
Walkthrough:
N: Dispatch epics to be specified
Offline: review specifications and comment / challenge
N + 1: discuss comments and amend
Offline: breakdown in tasks, tasks estimation
Product
Owner(s)
Team
Leader(s)
CTO Architect(s)
Tech
Lead
+ of course TechCom / Sprint planning / Sprint retro / Daily scrum / Delivery Rituals / Management Rituals (O3s) / etc.

58
A typical development month
Monday Tuesday Wednesday Thursday Friday Sat Sun
Sprint planning
Sprint Retro
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Daily Scrum
Sprint planning
Sprint Retro
Test Deployment
Sprint
N
Sprint
N+1
ARCHCOM
ARCHCOM
ARCHCOM
ARCHCOM
PMC
Test Deployment
Integration Depl. Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl. Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl.
Integration Depl.
UX Committee
UX Committee
Tech Committee
Tech Committee
Integration Depl.
Integration Depl.
ARCHCOM
PMC
UX
Committee
Tech Com.
Cross-team meetings (company wide):
All these rituals are prepared in advanced by all participants!
Rituals are clearly and consistently scheduled / no unforeseen interruption of sprint
Delivery Project Gaps
Review
Proj. Gaps Rev.

59
The Estimation Process
Story
Lorem ipsum dolor
sit amet, consectetur
adipiscing elit,
sed …
Detailed Story
Lorem ipsum dolor
adipiscing elit, sed
do eiusmod tempor
incididunt ut labore
et dolore magna
aliqua. Ut enim …
Development Epic
Lorem ipsum dolor sit amet,
consectetur adipiscing elit, sed
do eiusmod tempor incididunt ut
labore et dolore magna aliqua.
Ut enim ad minim veniam, quis
nostrud exercitation ullamco
laboris nisi ut aliquip ex ea
commodo consequat. Duis aute
irure dolor in reprehenderit in
voluptate velit esse cillum dolore
eu fugiat nulla pariatur.
Excepteur sint occaecat
cupidatat non proident, sunt in
culpa qui officia deserunt mollit
anim id est laborum.
Task
Lorem ipsum dolor
adipiscing elit,
sed …
Task
Lorem ipsum dolor
adipiscing elit,
sed …
Task
Lorem ipsum dolor
adipiscing elit,
sed …
Specification
&
Design
Process
Estimation
Process
PMC
PM PO
CTO
/ /
PM PO
/
Roadmap
Tm. L
PO
CTO
/
Archi.
/ /
CTO
ARCHCOM
Tm. L
Archi.
CTO
Tk. L
Delivery
wishes
Task
Task
Task
Development Epic
Story
ARCHCOM
Specification
Design
Estimations
Planning
21
34
55
110
110
Product Management R&D
Tk. L
Developers
PM
PM
PO
CTO
/
PO
CTO /
UPDATES!

60
Picking-up the extremes makes only little sense : people are sick, leaves on holidays,
some big task gets finished the next sprint, etc
➔ So we should pick up the second and last-but-one.
This gives us a lower range and an upper range
➔ Using a range addresses uncertainty
(REMINDER) Team Sprint Velocity


Uncertainty
138
128
Story Points
Sprint

61
Range is used this way:
In case of fixed time, when we
have a fixed delivery date, the
lower and upper values give us the
minimum or maximum set of
features we can have
implemented at that date.
In case of fixed scope, when we
have to release a version of the
software with a given set of
features, the lower and upper
values are used to compute earliest or latest release date
We now have everything we need for accurate estimations
(REMINDER) Forecasting
Story Points
Months
Team. L
PO
/

62
Estimation game – Take Aways
We
can
compute
the
Team
Sprint
Velocity
In this model, Project Gaps are the only items with hard
commitment.
A Delivery project being planned and with a Go-Live date, the related
deliverables due date has to be respected.
When designing the roadmap, these are put first and can’t be moved
afterwards (frozen items)
120
150
110
180
170
The estimation game tells us the total story points
for this Story. With the team capacity, it can be
planned in terms of number of sprints, assuming 2
sprints per month.
The keyword here is reserve, reserve and more
reserve.
D D
D
D
D
D
These batches are where we have some flexibility for urgent stuff popping up!
Fixed scope: keep all tasks in the batch and add new stuff.
Fixed date (fixed roadmap): add new stuff and remove an equal amount of SP

64
Now about the timeline
PRODUCT VISION
Research
Dev
FT
1
H2 Evolution 1
H2 Evolution 4
Dev
FT
2
H3 Evolution 3
Dev
FT
3
Project B Gaps
H3 Evolution 1
Dev
FT
4

65
Short-term vs. Long-term commitments
• Hard commitment - no slippage
should occur
• due dates are respected / fixed
• Scope can evolve (support,
critical bug fixes, etc.), in which
case tasks of lesser priority can
be postponed
• Transparent communication to
delivery, sales, customers, etc.
• Strong
commitment –
slippage should
support business
opportunities
• Opaque
communication
• Soft commitment –
this can really
change entirely if
required
• Cautious
communication
• Internal
only
• No
commit-
ment
• No
commu-
nication
Month
Granularity
Quarter Semester Year

66
Timeline evolution
April Roadmap
May Roadmap
Team Jun Jul Aug Sep Q4/2021 H1/2022 H2/2022 2023
Jun Roadmap
Team Jul Aug Sep Q4/2021 Q1/2022 Q2/2022 H2/2022 2023
M+1
M+1
Oct Roadmap
Team Nov Dec Jan/2022 -Q1/2022 Q2/2022 H2/2022 H1/2023 H2/2023 – H1/2024
M+4

67
“Stop the world” refactoring or technology evolutions ?
Feature flipping, API versioning, library versioning, etc.
If a “stop-the-world” refactoring or evolution can’t be avoided, it needs to be planned and accounted
in the roadmap (big vertical box)
Kaizen burst
Every end of quarter PMC starts with a Quarter retrospective
Challenge everything !
Delivery
SaaS : continuous deployment
On-premise deployment
continuous delivery, periodic end customer releases. Migration is a concern.
Specific rituals are required between PM and Delivery Teams
➔ Doesn’t change a whole lot of things for planning
Other aspects

68
SaaS / Cloud / Web deployment
Amazon
- Continuous Deployment in production
- Code is being deployed in production
every 11.7 seconds on average.
- Devs push code to production thousands
of times per day!
- Develop for failure - Chaos monkeys
randomly kills services and machines
continuously
Facebook
- Before 2016,
- Up to 3 release trains a day
- Cherry pick (manual) / periodic resync
- Since 2016
- Release train every few hours
- Push from master

69
On premise deployments
8.3-SN.
14329
8.3-SN.
14361
8.3-SN.
14398
R
8.3
8.4-SN.
14475
R
8.4
B B R
8.5
R
8.6
R
9
B B B B B B
End of Sprint Release - Internal Release / Automated deployment on Test Env.
Customer Release - Official Release / Deployable and versioned package with release notes, etc.

70
3. Take Aways and other models

71
Take Aways
XP
• TDD / Tests
Coverage
• On-site customer
(Product Owner )
• Code Reviews
• Sustainable Pace
• Small Releases
(Continuous
Delivery)
• Acceptance tests
• Planning Game
Scrum
• DoD - Definition of
Done
• Sprint planning /
Spring Retro
• Daily Scrum
• Product Increment
(Continuous Delivery)
• Estimation Game /
Planning Poker / SP
• Product Backlog
• Team Velocity
• Product Owner
Lean Startup
• Pizza Teams
• Feature Teams
• Feedback Loop
DevOps
• Automated
Provisioning
• ZDD
• Feature
Flipping
• Automated
Releases
• Continuous
Delivery
Product
Management
• Story Mapping
• PMC
• Product
Vision
• Roadmap
Maintenance
Reliable Roadmap

72
Required Tools
Need Tool Description
Collaborative source code
development
git
Need to be able to have a large number of concurrent branches and convenience for
managing them.
Feature Branches and Code
reviews
Gitlab (or gitbucket, etc.)
Enforcing code reviews Merge request / Pull requests. Comments arbitration, conflicts
resolution, etc.
Continuous Integration and
automated tests
Gitlab CI (or jenkins, etc.)
Integration test suite on every branch at every commit, full automated tests twice a day.
Deployment Automation
Integration deployment twice a day, test deployment end of every sprint, environment
promotion, etc.
Sprint backlog management
Jira
Sprint Kanban board, Sprint burndown chart, etc.
Product Backlog Management
Product backlog, Stories, Epics and task specification and relations, priorities
management, etc.
Documentation as Code ASCIIDoc Version-able documentation and editing integrated in development processes
End-to-End tests Selenium (or Protractor, etc.) Production-like environment non-regression tests
Infrastructure as Code Ansible (or Chef, Puppet) Environment provisioning, automated installation and deployment.
Database migration Liquibase Automated DB updates
Code quality Sonar Code Quality guarantee
Development Manifesto Wiki (e.g. confluence, etc.) Document your culture, values, organization, principles and practices (light !)
Planning Poker www.pointingpoker.com Distributed planning poker app
Kanban / Visual Board Trello (or MS Planner, etc.) ARCHCOM Topics, discussion topics, prioritization games, etc.
Agenda Outlook Rituals over processes
Roadmap Powerpoint / Excel
If you need more than excel or Powerpoint to draw your roadmap, then your roadmap is not
the right one.
Plenty of others …

73
Other Model : Holacracy
Every Team is a Project team - Circle (ultimate Feature Team); there are transverse projects
Every Team – Circle - has its own culture, organization, processes, rituals, tools, etc. as require to fulfill
its objectives and purpose
Governance – where dependencies and streams between Teams – Circles – are defined is key (and tricky)
(from https://www.tealschool.se/2019/07/12/holacracy-for-schools/)

74
Other models
Fixed time – fixed release dates roadmap
Flexible / variable scope
Commitment comes from identifying the subset of stories we have to stick to and the ones
that are fillers
Fixed scope – fixed content releases
Flexible release dates
Other aspects …
Management 3.0
Google-like Office space
Scaling Agile
Other aspects / final notes

A proposed framework for Agile Roadmap Design and Maintenance

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à A proposed framework for Agile Roadmap Design and Maintenance

Similaire à A proposed framework for Agile Roadmap Design and Maintenance (20)

Plus de Jérôme Kehrli

Plus de Jérôme Kehrli (18)

Dernier

Dernier (20)

A proposed framework for Agile Roadmap Design and Maintenance