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
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
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
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)
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
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
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
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
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
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
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?
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 …
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
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
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

More Related Content

PPTX
Release Management: Successful Software Releases Start with a Plan
PDF
Release Management Plan
PPTX
Agile Release Planning
PDF
Display Link Release Management
PDF
Taking Release Management to the Next Level
PPTX
Release Planning. For Agile Teams. A Quick Overview
PPT
HeartofAgile_Presentation_v3
PPTX
Tour de DART July 2009: Volunteer Expectations
Release Management: Successful Software Releases Start with a Plan
Release Management Plan
Agile Release Planning
Display Link Release Management
Taking Release Management to the Next Level
Release Planning. For Agile Teams. A Quick Overview
HeartofAgile_Presentation_v3
Tour de DART July 2009: Volunteer Expectations

What's hot (20)

DOC
Software Development Tips
PPTX
SDLC
PPTX
Phases of the Software Development Process - Meerakics
PPTX
PPTX
software project management Software development life cycle
PPTX
Agile software development process
PPTX
Deciphering Product Management Lingo
PDF
Waterfall Model Life Cycle
DOCX
Example_ProjectPlan.docx
PPTX
Azure dev ops
PPT
Rad model
PDF
Process and methodolgy followed @ Top Guru Assistants
PPTX
Better project deployment follow up’s
PPTX
PPTX
V model presentation
PPTX
Agile methodology
PPTX
2. project initiation
PPTX
Diagramming Product Management #1 - Requirements and Reality
PPTX
Multimedia project life cycle - wsolvt
PPTX
Software Product Engineering Life-cycle
Software Development Tips
SDLC
Phases of the Software Development Process - Meerakics
software project management Software development life cycle
Agile software development process
Deciphering Product Management Lingo
Waterfall Model Life Cycle
Example_ProjectPlan.docx
Azure dev ops
Rad model
Process and methodolgy followed @ Top Guru Assistants
Better project deployment follow up’s
V model presentation
Agile methodology
2. project initiation
Diagramming Product Management #1 - Requirements and Reality
Multimedia project life cycle - wsolvt
Software Product Engineering Life-cycle
Ad

Viewers also liked (20)

PPT
Roadmap template
PDF
How to Become a Thought Leader in Your Niche
PPTX
The Impact of Switching to a Rapid Release Cycle on Integration Delay of Addr...
PPTX
Avea Release Management IBM Innovate 2012
PDF
Release Manager Data sheet
PDF
Apereo OAE development and release process
PDF
Importance of connecting CRM with ERP
PPTX
IT Service Management Concepts for Project Managers
PPT
Service-Oriented Project Management (SOPM)
PDF
Firmware Improvement Roadmap
PDF
Roadmap For Improving Performance
PDF
Measuring The Service Provided By Project Management - Whitepaper
PDF
Securing the Digital Enterprise
PPTX
Pro's and Con's of Project Management as a Service
PDF
BDD in Java using Cucumber
PDF
Release Cycle Management Updates - Liberty Edition
PPT
How To Plan a Software Project
PPTX
Plm as a platform for smb companies
PPTX
Release process for a project
PPTX
Professional Services Roadmap 2011 and beyond
Roadmap template
How to Become a Thought Leader in Your Niche
The Impact of Switching to a Rapid Release Cycle on Integration Delay of Addr...
Avea Release Management IBM Innovate 2012
Release Manager Data sheet
Apereo OAE development and release process
Importance of connecting CRM with ERP
IT Service Management Concepts for Project Managers
Service-Oriented Project Management (SOPM)
Firmware Improvement Roadmap
Roadmap For Improving Performance
Measuring The Service Provided By Project Management - Whitepaper
Securing the Digital Enterprise
Pro's and Con's of Project Management as a Service
BDD in Java using Cucumber
Release Cycle Management Updates - Liberty Edition
How To Plan a Software Project
Plm as a platform for smb companies
Release process for a project
Professional Services Roadmap 2011 and beyond
Ad

Similar to IT Software - Release cycle & Delivery roadmap (20)

PPTX
Agile Product Owner
PPTX
Eliminate Bottlenecks in Software Development & Delivery
PPT
Agile Project Management.ppt
PPTX
Upstream: Shifting-left towards organization agility
PPTX
DOES14 - John Kosco - Blue Agility - Discover How to Improve Productivity by ...
ODP
Agile methods training
PPTX
Agile Practice Workshop at Eye Care Leaders
PDF
ETCA_8
PDF
Agile (Goal Oriented) Roadmaps
PPTX
Agile Methodology
PDF
Agile for Project Managers
PPTX
LeSS Like Adoption @ SAP
PPTX
WinSmart Technologies
PPT
ThoughtWorks Approach 2009
PPTX
Agile planning
PPTX
Lean & Agile Value Streams
PDF
Enterprise Agile - Hybrid of Methods
PPTX
Shift Left and Lean techniques for Agile Software Development
PPT
Product management class rookie to pro
Agile Product Owner
Eliminate Bottlenecks in Software Development & Delivery
Agile Project Management.ppt
Upstream: Shifting-left towards organization agility
DOES14 - John Kosco - Blue Agility - Discover How to Improve Productivity by ...
Agile methods training
Agile Practice Workshop at Eye Care Leaders
ETCA_8
Agile (Goal Oriented) Roadmaps
Agile Methodology
Agile for Project Managers
LeSS Like Adoption @ SAP
WinSmart Technologies
ThoughtWorks Approach 2009
Agile planning
Lean & Agile Value Streams
Enterprise Agile - Hybrid of Methods
Shift Left and Lean techniques for Agile Software Development
Product management class rookie to pro

More from Jean-François Nguyen (20)

PDF
Methodology: to build your product build your team your agile iteration your ...
PDF
Methodology: agile@scale what is a 'PI Zero'
PDF
Management 3 0: tip to guide manager to delegate and coach
PDF
Methodology: feature epic and user story
PDF
Methodology - Agile@Scale
PDF
Rex Sprint 0 - how build the data model with 2 BA and 3 IT architects
PDF
Rex - How User Stories can help you manage standard components of an IT project
PDF
Key items for a digital enterprise
PDF
Methodology - Design Sprint
PDF
Methodology - design thinking
PDF
Scrum product owner: how build a project charter & frame the project?
PDF
Develop a good product - 3 phases 3 methodologies - detail
PDF
How develop a GOOD product: 3 phases, 3 methodologies
PDF
Methodology: Agile introduction for deciders
PDF
Tool digital meeting room solutions for efficient cross border meeting v1....
PDF
Case: apply Agile principles to front office credit analyst activity
PDF
Methodology dimension voice of customer
PDF
Methodology lean IT transformation mission
PDF
Case: build an IT pool
PDF
Methodology: IT test
Methodology: to build your product build your team your agile iteration your ...
Methodology: agile@scale what is a 'PI Zero'
Management 3 0: tip to guide manager to delegate and coach
Methodology: feature epic and user story
Methodology - Agile@Scale
Rex Sprint 0 - how build the data model with 2 BA and 3 IT architects
Rex - How User Stories can help you manage standard components of an IT project
Key items for a digital enterprise
Methodology - Design Sprint
Methodology - design thinking
Scrum product owner: how build a project charter & frame the project?
Develop a good product - 3 phases 3 methodologies - detail
How develop a GOOD product: 3 phases, 3 methodologies
Methodology: Agile introduction for deciders
Tool digital meeting room solutions for efficient cross border meeting v1....
Case: apply Agile principles to front office credit analyst activity
Methodology dimension voice of customer
Methodology lean IT transformation mission
Case: build an IT pool
Methodology: IT test

Recently uploaded (20)

PPT
What is a Computer? Input Devices /output devices
PDF
Credit Without Borders: AI and Financial Inclusion in Bangladesh
PPTX
Chapter 5: Probability Theory and Statistics
PDF
Abstractive summarization using multilingual text-to-text transfer transforme...
PDF
1 - Historical Antecedents, Social Consideration.pdf
PDF
Consumable AI The What, Why & How for Small Teams.pdf
PPTX
Benefits of Physical activity for teenagers.pptx
PDF
A Late Bloomer's Guide to GenAI: Ethics, Bias, and Effective Prompting - Boha...
PPTX
Microsoft Excel 365/2024 Beginner's training
PDF
ENT215_Completing-a-large-scale-migration-and-modernization-with-AWS.pdf
DOCX
search engine optimization ppt fir known well about this
PDF
Architecture types and enterprise applications.pdf
PDF
A proposed approach for plagiarism detection in Myanmar Unicode text
PDF
NewMind AI Weekly Chronicles – August ’25 Week III
PPTX
Custom Battery Pack Design Considerations for Performance and Safety
PDF
Getting started with AI Agents and Multi-Agent Systems
PPTX
Configure Apache Mutual Authentication
PPTX
MicrosoftCybserSecurityReferenceArchitecture-April-2025.pptx
PDF
From MVP to Full-Scale Product A Startup’s Software Journey.pdf
PDF
Developing a website for English-speaking practice to English as a foreign la...
What is a Computer? Input Devices /output devices
Credit Without Borders: AI and Financial Inclusion in Bangladesh
Chapter 5: Probability Theory and Statistics
Abstractive summarization using multilingual text-to-text transfer transforme...
1 - Historical Antecedents, Social Consideration.pdf
Consumable AI The What, Why & How for Small Teams.pdf
Benefits of Physical activity for teenagers.pptx
A Late Bloomer's Guide to GenAI: Ethics, Bias, and Effective Prompting - Boha...
Microsoft Excel 365/2024 Beginner's training
ENT215_Completing-a-large-scale-migration-and-modernization-with-AWS.pdf
search engine optimization ppt fir known well about this
Architecture types and enterprise applications.pdf
A proposed approach for plagiarism detection in Myanmar Unicode text
NewMind AI Weekly Chronicles – August ’25 Week III
Custom Battery Pack Design Considerations for Performance and Safety
Getting started with AI Agents and Multi-Agent Systems
Configure Apache Mutual Authentication
MicrosoftCybserSecurityReferenceArchitecture-April-2025.pptx
From MVP to Full-Scale Product A Startup’s Software Journey.pdf
Developing a website for English-speaking practice to English as a foreign la...

IT Software - Release cycle & Delivery roadmap

  • 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