The FedEx Way

2

3

4

If you are involved in the process that ends with loading software to production and you work for Fred Smith then you are expected to follow RAPID.
5

-
Sirota surveys. "Too much process". Process space is bigger than just GDP.
-
Over time, GDP expanded. RAPID relates only to SDLC. Not all of GDP
-
We completed analysis based on feedback to narrow in on what was causing the frustration from a software development perspective.
6

The team as part of a waste-walk recorded what actually happens when a software change is made. We walked through a simple fix from beginning to end. We were able to complete the change in 95 minutes by not having any wait times (represented by the clocks). All of our resources were ready.
We learned a great deal about how our current GDP design (even the ‘EZ’ version of
GDP). This set our baseline.
7

-
These are messages you have given us as we explored what could be improved with GDP.
-
Note: GDP Guidance: 2 ¼" binder, 74 docs, 503 pages, (13x more words than the Declaration of Independence and US
Constitution combined!)
8

Many of the steps in the video are in place because they make sense in some situations. We had to come up with a repeatable, scalable way to get to the right amount of overhead in a given scenario.
We considered factors like: the likelihood of costing $, damaging the brand, etc.
This led us to look at risk as the driver
9

These are the attributes we consider when looking at risk for a project and for a system change relating to a given project.
10

We just spent time understanding why we embarked on the
RAPID journey and the approach we took to make a difference
(risk).
Let’s spend some time understanding exactly what the changes we made are all about.
11

Note: This slide has animation and may not appear correctly in a printed format.
Also the comparison is based on “V1” of RAPID.
We compare GDP and RAPID from a step and work product perspective. With GDP there were two variations, not based on risk. With RAPID there are 4 variations based on risk. By completing the waste-walk, we were able to reduce the top level process overhead significantly. The maximum for RAPID and the maximum for GDP are different.
Purple blocks represent a step that is included. The Yellow blocks with Red X’s indicate a step that is not included in that scenario.
By risk rating we can create a stair-step reduction in process overhead.
12

13

We looked at which work products had to be formally reviewed and approved in RAPID.
Some work products are important enough to be done, shared and used, but they do not benefit greatly from formal review and approval (process overhead). Some work products now have this as their rule through out the risk levels, and other work products have this rule in specific risk levels.
14

We had to be very specific when some work products have to be approved (inverse of
“golden arrow” rule). In RAPID, when a work product has to be approved, it must be approved by two managers (these should represent Business and IT roles when the work relates to business changes).
15

Nearly every developer we talked to found the current GDP code review steps to be wasteful. In today’s world a developer follows a two step process to complete their code review: 1. Peer review and attestation to information security guidelines, 2. approval of the code review (often by the exact same people as the peer reviewers).
RAPID changed this to one step. The peer review and attestation satisfy compliance requirements.
16

RAPID has sequences and dependencies, these were introduced with GEODE and have been adjusted based on risk for RAPID.
17

RAPID includes all of the SOX/PCI/HIPAA software development controls covered by
GEODE. Where they are accomplished shifts based on risk (in low risk scenarios, the
Go/No-Go satisfies many of the controls).
Control-17, Post Load Integrity Check is handled in a different way with RAPID. It is no longer necessary to produce compliance documentation and store it with the release tracker as with GEODE. An attestation when completing the work request satisfies this control. As we have build and deploy systems in place with custodial control of our software, then this control will be automated.
Post Load Integrity Check is still important (the software tested should be the software in production). Also teams are performing post load validations (E.g., software checkout, post load monitoring, etc..) , these are still important too. GDP did not formally document those types of checks, RAPID doesn’t either.
18

It is possible to add a work product to a lower risk path when appropriate.
It is possible to opt-out of specific work products with a written justification in a higher risk path when the work product is not adding value to the project.
19

When the risk is lower, there are fewer work products. When the risk is higher, there are more work products.
20

When we begin to look at these features on the RAPID diagram, you can see how they play together to give variations on what has to be completed.
At the start of the process we are asking you to make a simple determination. Is this a production problem? (Production problem means the system was designed to run a particular way and now for some reason it is not functioning within that design. Some call this break-fix. – there can not be new or modified requirements for this to qualify).
If it isn’t a production problem, then we require a work request to capture the demand and to relate any other work together.
21

There are two places to risk rate in RAPID (levels). At the Work Request and at the
Change Tracker. You must risk rate at the work request (standard or elevated) it is optional to risk rate at the change tracker.
At the change tracker you are determining if you are eligible for a lower risk path.
22

From the 2 places to risk rate, we get 4 paths for RAPID.
23

This is the whole RAPID process picture. You can see how each of the features are integrated on this diagram. The RAPID lab class will walk through this and also through how to complete each of the steps. You will not have to memorize this diagram, it is meant to be a helpful reference. The software we have prepared will ensure you are complete each of the steps.
24

25

To support RAPID, we didn’t want to make this only paper based. As a matter of fact we ran a RAPID Alpha, we picked 4 teams and ran an earlier version of the framework. We had to “hack” Symphony to get past some of the existing controls. What we found along with some framework changes was that we had to have tool support to make this successful.
First, we need tools to risk rate – Risk Rating
Then we need a set of tools to keep up with what is required in which scenario –
Checklists.
Third we needed to update work product reviews, this function has many of the checks for the current compliance steps. We’ve updated this to reflect the new RAPID framework.
And Last, to support RAPID, the Go/No-Go has more importance than before.
Remember, if something was lower risk, the compliance control is being satisfied at the
Go/No-Go. We’ve provided tools for approvers to see more information at Go/No-Go.
26

Risk rating happens in two places.
The Work Request risk rating was released in December 2013. If you have to risk rate, you will receive an email when the work request is saved.
The Change risk rating is on the System Change Tracker, it is optional to complete this risk rating; it is used to determine if you qualify for a lower risk path.
27

Risk rating happens in two places.
The Work Request risk rating was released in December 2013. If you have to risk rate, you will receive an email when the work request is saved.
The Change risk rating is on the System Change Tracker, it is optional to complete this risk rating; it is used to determine if you qualify for a lower risk path.
28

There are 4 functions on today’s change tracker to describe when work should be done and how done it is. This is 3 functions too many!
29

The change checklist is now on a dedicated tab.
30

Zooming in, you can see we have a graphical display showing which work products are needed and the status of each of the work products.
31

When clicking on a work product picture or on the horizontal tab more information can be found relating to that work product in the current risk scenario.
1. We display the RAPID business rule for the work product in this scenario
2. We provide action buttons to complete the work product (Reuse and existing approval by connecting to it, Identifying a document in TeamForge or requirements in Caliber RM, or starting a review and approval on one or more items on the checklist)
3. There is context useful online help available
4. Any error messages or other information regarding the current state of the work product are provided
32

This function has also received a redesign.
Including the ability to capture more review feedback. When we go through the RAPID lab we’ll talk about how important that is. I don’t know if you’ve paid attention, but the current review form only allows for 100 characters. I don’t know about you, but that is less than a tweet. I’ve never had that little of feedback. We can now support at least
3000 characters. We’ve improved the feedback status quality – will be able to state work product accepted, feedback requested…
33

Check approvals are now shown on the release tracker page.
There is a new Go/No-Go form for System IT Owner and System Business Owner and any additional approvers.
34

Check approvals are now shown on the release tracker page.
There is a new Go/No-Go form for System IT Owner and System Business Owner and any additional approvers.
35

36

We shifted from 28 GDP work products to 8 RAPID work products. While there were a few work products that were not carried forward, the vast majority of the content covered under GDP was recomposed into these 8 work products. We don’t get to claim we removed 20 work products.
Some notes:
Requirements represent any level of requirements necessary to solve the problem.
RAPID does not prescribe a specific level of abstraction.
Implementation Plan is not the document you use when you move to production (load night, that is a deployment plan in GDP). The Implementation Plan is the rollout strategy and decoupling plan.
37

38

If you have questions about adoption, please contact us.
39

40

- A lot of effort to ensure RAPID reflects right balance of FedEx culture and industry standards.
- Criticism of past efforts to change process was that it was being influenced too much by "process people" and lacked representation of developers. Leveraged our developer advisory board.
- Bert Nappier, Tony Cuccia, Nik Puri Grayson McClaine
41

We are capturing metrics and monitoring the overall usage of the product.
42

Following RAPID reduces overhead steps. We are avoiding an incredible number of steps, even with the early adopters.
43

The full interview is available on keyword: “RAPID”
44

The full interview is available on keyword: “RAPID”
45

-
Leadership genuinely wants to make our internal processes easier to navigate and execute
-
RAPID won't be perfect.
-
Want your feedback to help us improve it
-
Ask Jason to join and open for Q&A
46