IT Software - Release cycle & Delivery roadmap

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


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 AverageLeadtime

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


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 AverageLeadtime

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)


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


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


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


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


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


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


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 0203

030

215

1

30

20

1 1215

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):


• 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


Appendix 2

the key points: team work, workload, leadtime, waiting time

Post Mortem to compare your worst project and a successful one



Production

ReleaseDelay 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

IT Software - Release cycle & Delivery roadmap

Technology

Transcript of IT Software - Release cycle & Delivery roadmap