This document discusses release cycles and delivery roadmaps. It provides guidance on designing well-balanced release cycles that consider constraints. Key points include defining a catalog of release cycles for different user story families, qualifying development steps as value-added or non-value added, assessing current cycles based on workload and lead time, and leveraging techniques like parallelization, continuous integration, and continuous improvement to reduce lead times. The goal is to balance steps for an acceptable ROI and define SLAs for each user story family's release cycle.

1. Release cycle
(development process)
&
Delivery roadmap
the Goal:
• Design a well balanced Release Cycle in regard of your constraints
• Define your catalog of release cycles (one per User Story family) and your SLA

2. Release cycle (development process)& delivery roadmap
the key points: the development process, the different type of Test
Key Basics:
• A release cycle is a development macro process
• it’s build around the major steps: Business Requirement/Spec/Dev/Test/Prod setup
• Some steps are ‘Value Added’ for the End User, others are not
• The goal is
• to continuously reduce your constraints to an acceptable level (e.g. reduce your non
regression phase from 1 week to 1 day, …)
• to balance the steps to have an acceptable global ROI
• The base is your average ratio Spec/Dev/Test (in workload, in lead-time)
• This ratio is defined by family of User Story you find in your Backlog
• Each new request should match a family, follow its associated process
Case Study:
We propose to simulate a simplified case study where we’ll mix
• 3 different families of User Stories defined around the criteria of urgency & complexity
• Different levers of improvement: eliminate, improve, reorganise
Hypothesis regarding the Test:
• to simplify the exercise, we take only regression & UAT. Others (Unitary, Functional,
Integration,…) are not taken into account here but should be in the real world
• we also suppose Functional tests are done just after the dev and not only in UAT (too late)
the Goal:
• Design a well balanced Release Cycle in regard of your constraints
• Define your catalog of release cycles (one per User Story family) and your SLA

3. Release cycle (development process)& delivery roadmap
the key points: Value added for the client/End User
Key Understandings:
• Qualify the 3 steps (Spec/Dev/Test) in ‘Value Added’/’Non Value Added’ for the End User
Hypothesis simplified for the case study:
• Let’s say your backlog is composed by 3 families: standard urgent, standard non urgent and
complex
the Goal:
• Understand the dev process step in terms of ‘Value Added’, ‘Non Value Added’ for the User
Spec Dev Test
VA VA Non VA
Average workload Average
Leadtime
Spec Dev Reg UAT
Standard urgent 25%
2.5MD
50%
5MD
10%
1MD
15%
1.5MD
2 weeks
Standard non urgent 25%
2.5MD
50%
5MD
10%
1MD
15%
1.5MD
4 weeks
Complex 25%
10MD
25%
10MD
25%
10 MD
25%
10MD
8 weeks

4. Release cycle (development process)& delivery roadmap
the key points: workload, leadtime, ratio ROI
Key understanding
• Current situation: the 3 release cycles are totally sequential
• Assess the quality of each release cycle in terms of workload & leadtime
• (1): ratio just balanced 1MD of VA for 1MD of NVA. Instead for standard 3MD for 1MD
• (2): any steps can be done in parallel?
the Goal:
• Assess the current Release Cycles in terms of ROI regarding the workload, the leadtime
• For the leadtime, it’s key to get the Voice Of the Customer
Average workload Assessment Average
Leadtime
Assessment
Spec
(VA)
Dev
(VA)
Reg
(NVA)
UAT
(NVA)
VA/NVA
Standard urgent 25%
2.5MD
50%
5MD
10%
1MD
15%
1.5MD
OK 7.5/2.5 2 weeks KO (2)
Standard non urgent 25%
2.5MD
50%
5MD
10%
1MD
15%
1.5MD
OK 7.5/2.5 4 weeks KO (2)
Complex 25%
10MD
25%
10MD
25%
10 MD
25%
10 MD
KO
(1)
1/1 8 weeks KO (2)

5. Release cycle (development process)& delivery roadmap
the key points: User Story family
the Goal:
• Assess the current Release Cycles in terms of ROI regarding the workload, the leadtime
 Current situation
 Key understanding: what can be improved?
2 weeks
4 weeks
8 weeks

6. Release cycle (development process)& delivery roadmap
key point: pull the Flow, paralellisation
the Goal:
• To reduce your leadtime, you can reduce steps, do some steps in parallel
• Let’s try first to parallelize dev and spec when you can
 Lever: parallelisation (pull the flow)
 Key understanding: start the dev as soon as the spec is ready (don’t wait artificially). Do it
for any step.
< 2 weeks
< 4 weeks
< 8 weeks

7. Release cycle (development process)& delivery roadmap
key point: continuous integration, code factory (code for the code), Test Driven Development
the Goal:
• Let’s try now to parallelize regression and dev
• you need to reduce the effort & time doing build & regression. Can you automate?
 Lever: Continuous integration (Test Driven)
 Key understanding:
• Continuous Integration is regular build & regression test all along the dev process. The
coder code to automate the build & regression test (code factory).
• Discover problem early in the process cost less (less root cause analysis, less effort to solve)
< 2 weeks
3 weeks
6 weeks

8. Release cycle (development process)& delivery roadmap
key point: continuous improvement, Test methodology, Over Quality when not required
the Goal:
• Improve your most heavy steps with No Value Added (e.g. UAT for complex User Story)
• Test methodology is question of taking a Risk: Which tests are required, which are not?
 Lever: Continuous Improvement on UAT for complex User Stories
 Key understanding: in the continuous improvement activity, optimise the UAT process. Some
ideas: Test expert can bring you best practices to optimise your strategy, the data used, etc …
< 2 weeks
3 weeks
5 weeks

9. Release cycle (development process)& delivery roadmap
key point: continuous improvement, dynamic Team capacity management, Visual management
the Goal:
• build your delivery roadmap using your catalog of release cycles
• Define the best strategy (regular deliveries variable content, fix content ad-hoc deliveries, …)
 Best case: your flow of User Story is quite homogeneous, predictable & activities quite
independent. You’re able to build & present to your client a stable delivery roadmap for the
next months. Regular deliveries with variable content is more ‘Agile’ & ensure process stability.
Easier to define & apply a SLA. Your team capacity management is capacity planning.
Example: 4 team members working on 3 applications
 Key understanding: your reality is particular. Based on best practices/methodology, build
your own model.
 Worst case: your flow of User Story is heterogeneous, unpredictable & activities dependant.
You can’t build a stable delivery roadmap in advance. You build dynamically & regularly
depending of your new User request. Your team capacity management is also highly dynamic
and is eased by visual management. Think about what is best for you regarding your
constraints: ad-hoc/regular deliveries, fix/variable release content

10. Release cycle (development process)& delivery roadmap
key point: daily & weekly meeting should be complementary not redundant
the Goal:
• How to use a release cycle?
• Check your team capacity, build your weekly meeting agenda, ….
 Build your release cycle per activity/project
 Key understanding:
Check your team capacity:
• Team members are not developing at the same time on Appli2 and Appli3
• Book time for your team to do continuous improvement
Read on the roadmap the weekly team meeting agenda
• Depending on where the team is on the release cycle, the agenda can cover subjects
like post mortem, performance monitoring, Best Practice sharing, …
• If not adapted to your context, weekly might be fortnightly or monthly
2
1
4
3

11. Release cycle (development process)& delivery roadmap
the key points: Project management, methodologies, technical tools … should do a ONE consistent
the Goal:
• List of key topics to assess to improve your release cycle & delivery roadmap
• Assess your team, your development process, your code management, your test, …
Code factory
• Create transversal/product team (Spotify)
• Review the development process from the request initiation to production
• onshore-offshore & RA(CI)
• Review roles:
• Team lead, Tech Lead, Scrum master & Product Owner
• others on offshore side
Review project & team management with Agile & Scrum key concepts (events & roles)
• work with MVP (Minimum Viable Product)
• build your final product incrementally through short iterations (PDCA cycle)
• adjust the meeting cascade (hoshin-kanri) to be aligned with TOP management vision
• Implement an electronic dashboard for splitted team to visualize & ease the communication
Review development factory with Lean key concepts
• easily control your code: code management & coder community (GitHub)
• easily deploy technical environment (PaaS/IaaS)
• easily deploy the code: automated package building & deployment (DevOps)
• prove your code is working (Google):
• test methodology & strategy
• continuous integration (build & automated test)
• improve continuously your Code & Factory: architecture & refactoring (SaaS)
1. Build the team: do you empower people?
2. Build the Agile iteration: do you try & adapt in short iteration?
3. Build the Code Factory: do you ensure code quality & fluidity in the process?

12. Appendix
the key points: all tools available in the Lean tool kit
A few examples of analyses you can do to improve your process:
To help your team understand where is inefficiency
1. Workflow mapping combined with RA(CI)
2. Post Mortem to compare your worst project and a successful one
3. And many others in the Lean tool kit …

13. Appendix 1
the key points: team work, all tools available in the Lean tool kit
Workflow mapping combined with RA(CI):
• Be careful not to mix several families
Waste of
time
D0
leadtime
processing time
1 02
03
0
3
0
2
15
1
3
0
2
0
1 12
15
3
in %
in days
processing time
vs
leadtime
step
11
1
step
10
0
step
9
2
step
8
3
step
7
50
step
6
10
step
5
3
step
4
5
step
3
50
step
2
25
step
1
60
D29D10 D20
~ 33 % ~ 33 % ~33 %
80
20
waiting
time
processing
• Too many stakeholders
• 1 request is dependent on 2 decisions levels
• Lack of coordination to avoid waiting time
• Waiting time (~80%) vs Processing (~20%)
• Steps 6, 9 with stakeholder X, 5, 8 (CC), 1 may be the first to focus on but feasibility requires to be checked
 Team X – workflow mapping – process Y

14. Appendix 1
the key points: team work, workload, leatime, waiting time
Workflow mapping combined with RA(CI):
• Be careful not to mix several families
• Step C: one person is doing, 4 other people are validating. This split generates 70% of waiting time (14 working days)
• Step D: meeting, writing minutes and make all sign generates 97% of waiting time (7 working days)
• Questions:
• Is the split required?
• If the split is required, is it possible to reduce the waiting time?
process step
0 1 2 3 4
role Step A Step B Step C Step D Step E
Stakeholder 1 RA
Stakeholder 2 RA A RA
Stakeholder 3 R R RA
Stakeholder 4 A R
Stakeholder 5 A RA
Stakeholder 6 A RA
Processing time
(in days) 5.7 0.155 0.005
leadtime
(in days) 20 8 1
waiting time
(in days) 14.3 7.845 0.995
1 2
Lean Best Practice
• To avoid waiting time, R and A should be in the same box to
avoid potential waiting time
• To better visualise the problem, don’t put the C & I of the RACI
Legend:
R: Responsible. The person who is doing the action
A: Accountable. The person who is accountable for the action
1
2
 Team X – workflow mapping – process Y

15. Appendix 2
the key points: team work, workload, leadtime, waiting time
Post Mortem to compare your worst project and a successful one
• Be careful not to mix several families
 Team X – workflow mapping – process Y
Production
Release
Delay due to
technical operation
25 Feb 2011
Specs & Estimates Dev Prep UAT
17 Jan 2011
6
Amendment
Release Estimate
0,1
Project Start with
Release Content:
05 Jan 2011
0,1
2 6
0,2
2
71,4
1
Change Content
Release:
03 Feb 2011
Freeze Content
07 Feb 2011
3
2
17,3
4
1
6
0,5 6,5
3 2
1,5 1,5
15
23 April 2011
9,7
27
5,218
Bugs Fixing
Initial Prod Release:
09 April 2011
8 Mars 2011
UAT
38%
62%45%55%
Processing Time: 59 days
Lead Time: 108 days
Waiting time: 49 days
Workload: 113 md
Rework: 43,5 md
▪ Ratio processing vs total lead time = 55% | % Rework: 38 %
• Important Rework
• Delay in Release Date
• Several Bugs fixing
• Risk to release after shorter UAT to compensate delay
 lower quality of the release / bugs in prod
• Important Change in Release Content
• Missing Test Cases at specification time
• Development prior to Freeze Content to anticipate heavy
workload
• Late Freeze Content