Enterprise Frameworks

(1)

Lean & Agile

For Managing Large U.S. Gov’t

Cloud Computing Projects

Dr. David F. Rico,

PMP

,

CSEP

,

ACP

,

CSM

,

SAFe

Twitter

:

@dr_david_f_rico

Website:

http://www.davidfrico.com

:

http://www.linkedin.com/in/davidfrico

Facebook

:

http://www.facebook.com/david.f.rico.9

Agile Capabilities

:

http://davidfrico.com/rico-capability-agile.pdf

Agile Resources

:

http://www.davidfrico.com/daves-agile-resources.htm

(2)

Author Background



Gov’t contractor with

32+ years

of

IT experience



B.S.

Comp

.

Sci

., M.S.

Soft

.

Eng

., & D.M.

Info

.

Sys

.



Large gov’t projects

in U.S., Far/Mid-East, & Europe

2



Career systems & software engineering methodologist



Lean-Agile, Six Sigma, CMMI, ISO 9001, DoD 5000



NASA, USAF, Navy, Army, DISA, & DARPA projects



Published seven books & numerous journal articles



Intn’l keynote speaker, 100+ talks to 11,000 people



Adjunct at GWU, UMBC, UMUC, Argosy, & NDMU



Specializes in metrics, models, & cost engineering



Cloud Computing, SOA, Web Services, FOSS, etc.

(3)

Today’s Whirlwind Environment

3



Overruns



Attrition



Escalation



Runaways



Cancellation

Global

Competition

Demanding

Customers

Organization

Downsizing

System

Complexity

Technology

Change

Vague

Requirements

Work Life

Imbalance



Inefficiency



High O&M



Lower DoQ



Vulnerable



N-M Breach

Reduced

IT Budgets

81 Month

Cycle Times

Redundant

Data Centers

Lack of

Interoperability

Poor

IT Security

Overburdening

Legacy Systems

Obsolete

Technology & Skills

Pine, B. J. (1993). Mass customization: The new frontier in business competition. Boston, MA: Harvard Business School Press.

Pontius, R. W. (2012). Acquisition of IT: Improving efficiency and effectiveness in IT acquisition in the DoD. Second Annual AFEI/NDIA Conference on Agile in DoD, Springfield, VA, USA.

(4)

Global Project Failures

4

Standish Group. (2010). Chaos summary 2010. Boston, MA: Author.

Sessions, R. (2009). The IT complexity crisis: Danger and opportunity. Houston, TX: Object Watch.



Challenged

and

failed

projects hover at

67%



Big projects fail more often

, which is 5% to 10%



Of

$1.7T spent

on IT projects,

over $858B were lost

16%

53%

31%

27%

33%

40%

26%

46%

28%

49%

23%

34%

51%

15%

29%

53%

18%

35%

46%

19%

32%

44%

24%

33%

41%

26%

0% 20% 40% 60% 80% 100% 1994 1996 1998 2000 2002 2004 2006 2008 2010

Ye

ar

Successful

Challenged

Failed

$0.0 $0.4 $0.7 $1.1 $1.4 $1.8 2002 2003 2004 2005 2006 2007 2008 2009 2010

Trillions (US Dollars)

Expenditures

Failed Investments

(5)

Requirements Defects & Waste

5

Sheldon, F. T. et al. (1992). Reliability measurement: From theory to practice. IEEE Software, 9(4), 13-20

Johnson, J. (2002). ROI: It's your job. Extreme Programming 2002 Conference, Alghero, Sardinia, Italy.



Requirements defects

are #1 reason projects fail



Traditional projects specify

too many requirements



More than

65%

of

requirements

are

never used

at all

Other 7%

Requirements

47%

Design

28%

Implementation

18%

Defects

Always 7%

Often 13%

Sometimes

16%

Rarely

19%

Never

45%

Waste



(6)

What is Agility?



A-gil-i-ty

(ә-'ji-lә-tē) Property consisting of

quickness

,

lightness

, and

ease of movement

;

To be very nimble



The ability to create and

respond to change

in order to

profit in a turbulent global business environment



The ability to

quickly reprioritize

use of resources when

requirements, technology, and knowledge shift



A very

fast response

to sudden market changes and

emerging threats by intensive

customer interaction



Use of

evolutionary

,

incremental

, and

iterative

delivery

to converge on an optimal customer solution



Maximizing

BUSINESS VALUE

with right sized,

just-enough, and just-in-time processes and documentation

Highsmith, J. A. (2002). Agile software development ecosystems. Boston, MA: Addison-Wesley.

6

(7)

What are Agile Methods?

7



People-centric

way to create innovative solutions



Product-centric

alternative to documents/process



Market-centric

model to maximize business value

Agile Manifesto. (2001). Manifesto for agile software development. Retrieved September 3, 2008, from http://www.agilemanifesto.org

Rico, D. F., Sayani, H. H., & Sone, S. (2009). The business value of agile software methods. Ft. Lauderdale, FL: J. Ross Publishing.

Rico, D. F. (2012). Agile conceptual model. Retrieved February 6, 2012, from http://davidfrico.com/agile-concept-model-1.pdf

Customer Collaboration

Working Systems & Software

Individuals & Interactions

Responding to Change

valued

more than

valued

more than

valued

more than

valued

more than

Contracts

Documentation

Processes

Project Plans



Frequent comm.



Close proximity



Regular meetings



Multiple comm. channels



Frequent feedback



Relationship strength



Leadership



Boundaries



Empowerment



Competence



Structure



Manageability/Motivation



Clear objectives



Small/feasible scope



Acceptance criteria



Timeboxed iterations



Valid operational results



Regular cadence/intervals



Org. flexibility



Mgt. flexibility



Process flexibility



System flexibility



Technology flexibility



Infrastructure flexibility



Contract compliance



Contract deliverables



Contract change orders



Lifecycle compliance



Process Maturity Level



Regulatory compliance



Document deliveries



Document comments



Document compliance



Cost Compliance



Scope Compliance



Schedule Compliance



Courage



(8)

Network

Computer

Operating System

Middleware

Applications

APIs

GUI

How Agile Works



Agile

requirements implemented

in

slices vs. layers



User needs

with

higher business value

are done first



Reduces

cost & risk

while increasing

business success

8

Shore, J. (2011). Evolutionary design illustrated. Norwegian Developers Conference, Oslo, Norway.

Agile

Traditional

1

2 3



Faster



Early ROI



Lower Costs



Fewer Defects



Manageable Risk



Better Performance



Smaller Attack Surface

Late



No Value



Cost Overruns



Very Poor Quality



Uncontrollable Risk



Slowest Performance



More Security Incidents



Seven Wastes 1. Rework 2. Motion 3. Waiting 4. Inventory 5. Transportation 6. Overprocessing 7. Overproduction

MINIMIZES

MAXIMIZES

 JIT, Just-enough architecture

 Early, in-process system V&V

 Fast continuous improvement

 Scalable to systems of systems

 Maximizes successful outcomes

 Myth of perfect architecture

 Late big-bang integration tests

 Year long improvement cycles

 Breaks down on large projects

 Undermines business success

(9)

9

Capability/MMF #1 ●Feature 1 ●Feature 2 ●Feature 3 ●Feature 4 ●Feature 5 ●Feature 6 ●Feature 7 Capability/MMF #2 ●Feature 8 ●Feature 9 ●Feature 10 ●Feature 11 ●Feature 12 ●Feature 13 ●Feature 14 Capability/MMF #3 ●Feature 15 ●Feature 16 ●Feature 17 ●Feature 18 ●Feature 19 ●Feature 20 ●Feature 21 Capability/MMF #4 ●Feature 22 ●Feature 23 ●Feature 24 ●Feature 25 ●Feature 26 ●Feature 27 ●Feature 28 Capability/MMF #5 ●Feature 29 ●Feature 30 ●Feature 31 ●Feature 32 ●Feature 33 ●Feature 34 ●Feature 35 Capability/MMF #6 ●Feature 36 ●Feature 37 ●Feature 38 ●Feature 39 ●Feature 40 ●Feature 41 ●Feature 42 Capability/MMF #7 ●Feature 43 ●Feature 44 ●Feature 45 ●Feature 46 ●Feature 47 ●Feature 48 ●Feature 49

1

2

3

4

5

6

7

8

9

10

11 12

13

14 15

16

17 18

19

20 21

Evolving “Unified/Integrated” Enterprise Data Model

“

Disparate

” L

EGACY

S

YSTEM

D

ATABASES

(

AND

D

ATA

M

ODELS

)

ETL A A B C D E F G H I J K A B C D E F A B C D E A B C D A B C A B

“Legacy” MS SQL Server Stovepipes “Inter-Departmental” Linux Blade/Oracle/Java/WebSphere Server

“Leased” DWA/HPC/Cloud Services

Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7

Release

Release Release

Release

ETL ETL ETL ETL ETL ETL

Bente, S., Bombosch, U., & Langade, S. (2012). Collaborative enterprise architecture: Enriching EA with lean, agile, and enterprise 2.0 practices. Waltham, MA: Elsevier.

Agile Development In-the-Large

“

Incremental Business Value

”

(

for example, assume 25 user stories per feature, 175 user stories per capability/MMF, and 1,225 user stories total

)



Organize needs into capabilities, features, and stories



Prioritize features, group releases, and initiate sprints



Develop

minimum set of features

with

highest value

(10)

Agile for

E

MBEDDED

S

YSTEMS



1st-generation systems used hardwired logic



2nd-generation systems used PROMS & FPGAs



3rd-generation

systems use

APP. SW

&

COTS HW

10

Pries, K. H., & Quigley, J. M. (2010). Scrum project management. Boca Raton, FL: CRC Press.

Pries, K. H., & Quigley, J. M. (2009). Project management of complex and embedded systems. Boca Raton, FL: Auerbach Publications.

Thomke, S. (2003). Experimentation matters: Unlocking the potential of new technologies for innovation. Boston, MA: Harvard Business School Press.



●

Short Lead

●

Least Cost

●

Lowest Risk

●

90% Software

●

COTS Hardware

●

Early, Iterative Dev.

●

Continuous V&V

●

Moderate Lead

●

Moderate Cost

●

Moderate Risk

●

50% Hardware

●

COTS Components

●

Midpoint Testing

●

“Some” Early V&V

●

Long Lead

●

Highest Cost

●

Highest Risk

●

90% Hardware

●

Custom Hardware

●

Linear, Staged Dev.

●

Late Big-Bang I&T

A

GILE

“

Software Model

”

- M

OST

F

LEXIBLE

-N

EO

-T

RADITIONAL

“

FPGA Model

”

- M

ALLEABLE

-T

RADITIONAL

“

Hardwired Model

”

- L

EAST

F

LEXIBLE

-G

OAL

– S

HIFT FROM

L

ATE

H

ARDWARE TO

E

ARLIER

S

OFTWARE

S

OLUTION

R

ISK

Embedded

Systems

More HW

Than SW

S

TOP

Competing

With HW

S

TART

Competing

With SW





(11)

11

Kovacs, K. (2015). Comparison of nosql databases. Retrieved on January 9, 2015, from http://kkovacs.eu

Sahai, S. (2013). Nosql database comparison chart. Retrieved on January 9, 2015, from http://www.infoivy.com

DB-Engines (2014). System properties comparison of nosql databases. Retrieved on January 9, 2015, from http://db-engines.com



Rank Database Year Creator

Firm

Goal

Model Lang I/F

Focus

Example

User Rate KPro

2007 Steve

Francia 10gen

Gener-ality Document C++ BSON

Large-scale

Web Apps CRM Expedia

45%

48

2008 Avinash Lakshman Facebook Relia-bility Wide Column Java CQL Fault-tolerant Data Stores Mission

Critical Data iTunes

20%

15

2009 Salvatore

Sanfilippo Pivotal Speed Key Value C Binary

Real-time Messaging

Instant

Messaging Twitter

20%

14

2007 Mike

Carafella Powerset Scale

Wide

Column Java REST

Petabyte-size Data Stores

Image

Repository Ebay

10%

8

2004 Shay

Banon Compass Search Document Java REST

Full-text Search Information Portals Wiki-media

5%

7

Real-time, Distributed, Multi-tenant, Document-based, Schema-free, Persistence, Availability, etc.

8

Redis

10

HBase

14

Rapid-prototyping, Queries, Indexes, Replication, Availability, Load-balancing, Auto-Sharding, etc.

Distributed, Scalable, Performance, Durable, Caching, Operations, Transactions, Consistency

Real-time, Memory-cached, Performance, Persistence, Replication, Data structures, Age-off, etc.

Scalable, Performance, Data-replication, Flexible, Consistency, Auto-sharding, Metrics, etc.

16

Search

Elastic

MongoDB

5

Cassandra

3 - $10M • Gen App • Reliable • Low Cplx 2 - $100M • Schema • Dist P2P • Med Cplx 1 - $1B • Limited • Sin PoF • High Cplx



Agile for

C

LOUD

C

OMPUTING



1st-generation systems used HPCs & Hadoop



2nd-generation systems used COTS HW & P2P

(12)

Scrum

Schwaber, K., & Beedle, M. (2001). Agile software development with scrum. Upper Saddle River, NJ: Prentice-Hall.



Created by Jeff Sutherland at Easel in 1993



Product backlog comprised of needed features



Sprint-to-sprint, iterative, adaptive emergent model

(13)

Scrum-XP Hybrid

Augustine, S. (2008). Certified scrum master training: Not just how, buy why. Herndon, VA: LitheSpeed.



Created by Sanjiv Augustine of Lithespeed in 2008



Release planning used to create product backlog



Extends Scrum beyond Sprint-to-sprint planning

Initial Planning Sprint Cycle

Discovery Session Agile Training Project Discovery Process Discovery Team Discovery Initial Backlog Release Planning Business Case Desired Backlog Hi-Level Estimates Prioritize Backlog Finalize Backlog Product Backlog Prioritized Requirements Sprint Planning

Set Sprint Capacity

Identify Tasks

Estimate Tasks

Sprint Review

Present Backlog Items

Record Feedback

Adjust Backlog

Daily Scrum

Completed Backlog Items

Planned Backlog Items

Impediments to Progress

Sprint Backlog

List of Technical Tasks Assigned to a Sprint

Potentially Shippable Product

Working Operational Software

Sprint

Select Tasks and Create Tests

Create Simple Designs

Code and Test Software Units

Perform Integration Testing

Maintain Daily Burndown Chart

Update Sprint Backlog

Sprint Retrospective



(14)

Agile Project Management

Highsmith, J. A. (2010). Agile project management: Creating innovative products. Boston, MA: Pearson Education.



Created by Jim Highsmith of Cutter in 2010



Front-end visions and architectures and final QA



Light project model wrapped around agile practices

Innovation Lifecycle Envision Product Vision Product Architecture Project Objectives Project Community Delivery Approach Speculate Gather Requirements Product Backlog Release Planning Risk Planning Cost Estimation Explore Iteration Management Technical Practices Team Development Team Decisions Collaboration Launch Final Review Final Acceptance Final QA Final Documentation Final Deployment Close Clean Up Open Items

Support Material Final Retrospective Final Reports Project Celebration Iterative Delivery Technical Planning Story Analysis Task Development Task Estimation Task Splitting Task Planning

Standups, Architecture, Design, Build, Integration, Documentation, Change, Migration, and Integration Story Deployment

Adapt Focus Groups Technical Reviews Team Evaluations Project Reporting Adaptive Action Operational Testing Integration Testing System Testing Operational Testing Usability Testing Acceptance Testing

Development, Test, & Evaluation

Development Pairing

Unit Test Development

Simple Designs

Coding and Refactoring

Unit and Component Testing

Continuous

(15)

Layton, M. C., & Maurer, R. (2011). Agile project management for dummies. Hoboken, NJ: Wiley Publishing.



Created by Mark Layton at PlatinumEdge in 2012



Mix of new product development, XP, and Scrum



Simple codification of common XP-Scrum hybrid

15

Agile Project Management

(16)

16

Agile Performance Measurement

Work (Story , Point, Task) or Effort (Week, Day , H our)

Time Unit (Roadmap, Release, Iteration, Month, Week, Day, Hour, etc.)

Burndown

Cumulative Flow

Earned Value Management - EVM

CPI SPI PPC APC Work (Story , Point, Task) or Effort (Week, Day , H our)

(17)

Agile Summary



Agile methods

DON’T

mean deliver it now & fix it later



Lightweight, yet disciplined approach to development



Reduced

cost

,

risk

, &

waste

while

improving quality

17

Rico, D. F. (2012). What’s really happening in agile methods: Its principles revisited? Retrieved June 6, 2012, from http://davidfrico.com/agile-principles.pdf

Rico, D. F. (2012). The promises and pitfalls of agile methods. Retrieved February 6, 2013 from, http://davidfrico.com/agile-pros-cons.pdf

Rico, D. F. (2012). How do lean & agile intersect? Retrieved February 6, 2013, from http://davidfrico.com/agile-concept-model-3.pdf

What

How

Result

Flexibility

Use lightweight, yet disciplined processes and artifacts

Low work-in-process

Customer

Involve customers early and often throughout development

Early feedback

Prioritize

Identify highest-priority, value-adding business needs

Focus resources

Descope

Descope complex programs by an order of magnitude

Simplify problem

Decompose

Divide the remaining scope into smaller batches

Manageable pieces

Iterate

Implement pieces one at a time over long periods of time

Diffuse risk

Leanness

Architect and design the system one iteration at a time

JIT waste-free design

Swarm

Implement each component in small cross-functional teams

Knowledge transfer

Collaborate

Use frequent informal communications as often as possible

Efficient data transfer

Test Early

Incrementally test each component as it is developed

Early verification

Test Often

Perform system-level regression testing every few minutes

Early validation

Adapt

Frequently identify optimal process and product solutions

Improve performance





(18)

Agile Enterprise Frameworks

18



Dozens of Agile project management models emerged



Many stem from principles of Extreme Programming



All include

product

,

project

, &

team

management

Schwaber, K. (2007). The enterprise and scrum. Redmond, WA: Microsoft Press.

Leffingwell, D. (2007). Scaling software agility: Best practices for large enterprises. Boston, MA: Pearson Education.

Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley.

Ambler, S. W., & Lines, M. (2012). Disciplined agile delivery: A practitioner's guide to agile software delivery in the enterprise. Boston, MA: Pearson Education.

Thompson, K. (2013). cPrime’s R.A.G.E. is unleashed: Agile leaders rejoice! Retrieved March 28, 2014, from http://www.cprime.com/tag/agile-governance

eScrum

-

2007

-

2007

SAFe

-

2007

LeSS

-

2012

DaD

-

2013

RAGE

-

Product Mgt



Program Mgt



Project Mgt



Process Mgt



Business Mgt



Market Mgt



Strategic Mgt



Portfolio Mgt



Program Mgt



Team Mgt



Quality Mgt



Delivery Mgt



Business Mgt



Portfolio Mgt



Product Mgt



Area Mgt



Sprint Mgt



Release Mgt



Business Mgt



Portfolio Mgt



Inception



Construction



Iterations



Transition



Business



Governance



Portfolio



Program



Project



Delivery



(19)

Enterprise Scrum (eScrum)

Schwaber, K. (2007). The enterprise and scrum. Redmond, WA: Microsoft Press.



Created by Ken Schwaber of Scrum Alliance in 2007



Application of Scrum at any place in the enterprise



Basic Scrum

with extensive

backlog grooming

19

(20)

Scaled Agile Framework (SAFe)



Created by Dean Leffingwell of Rally in 2007



Knowledge to scale agile practices to enterprise



Hybrid

of

Kanban

,

XP release planning

, and

Scrum

20

(21)

Large Scale Scrum (LESS)



Created by Craig Larman of Valtech in 2008



Scrum for larger projects of 500 to 1,500 people



Model to

nest product owners

,

backlogs

, and

teams

21

Larman, C., & Vodde, B. (2008). Scaling lean and agile development: Thinking and organizational tools for large-scale scrum. Boston, MA: Addison-Wesley. Product Owner

Product Backlog Product BacklogProduct OwnerAreaArea

Sprint Backlog

Daily Scrum

15 minutes

Product Backlog Refinement

5 - 10% of Sprint 2 - 4 Week Sprint 1 Day Feature Team + Scrum Master Sprint Planning II 2 - 4 hours Sprint Planning I 2 - 4 hours Potentially Shippable Product Increment Sprint

Review SprintJoint Review Sprint Retrospective

(22)

Disciplined Agile Delivery (DaD)



Created by Scott Ambler of IBM in 2012



People, learning-centric hybrid agile IT delivery



Scrum mapping

to a

model-driven RUP framework

22

Ambler, S. W., & Lines, M. (2012). Disciplined agile delivery: A practitioner's guide to agile software delivery in the enterprise. Boston, MA: Pearson Education.

(23)

Recipes for Agile Governance (RAGE)



Created by Kevin Thompson of cPrime in 2013



Agile governance model for large Scrum projects



Traditional-agile hybrid

of portfolio-project planning

23

Thompson, K. (2013). cPrime’s R.A.G.E. is unleashed: Agile leaders rejoice!Retrieved March 28, 2014, from http://www.cprime.com/tag/agile-governance

(24)

Comparison of Frameworks



Numerous lean-agile enterprise frameworks emerging



eScrum & LeSS were 1st (but SAFe & DaD dominate)



SAFe

is the most

widely-used

(with ample resources)

24

Rico, D. F. (2014). Scaled agile framework (SAFe) comparison. Retrieved June 4, 1024 from http://davidfrico.com/safe-comparison.xls

Factor

eScrum

SAFe

LeSS

DaD

RAGE

Simple



Well-Defined



Web Portal



Books



Measurable



Results



Training & Cert



Consultants



Tools



Popularity



International



Fortune 500



Government



Lean-Kanban





(25)

SAFe Revisited



Proven, public well-defined F/W for scaling Lean-Agile



Synchronizes alignment, collaboration, and deliveries



Quality

,

execution

,

alignment

, &

transparency

focus

25

Leffingwell, D. (2014). Scaled agile framework (SAFe). Retrieved June 2, 1024 from http://www.scaledagileframework.com



Portfolio

Team

Program

(26)

SAFe—Scaling at

P

ORTFOLIO

Level



Vision, central strategy, and decentralized control



Investment themes, Kanban, and objective metrics



Value delivery

via

epics

,

streams

, and

release trains

26

A

GILE

P

ORTFOLIO

M

ANAGEMENT

●

Decentralized decision making

●

Demand-based continuous flow

●

Lightweight epic business cases

●

Decentralized rolling wave planning

●

Objective measures & milestones

●

Agile estimating and planning

Strategy

Investment

Funding

Governance

Management

Program







(27)

SAFe—Scaling at

P

ROGRAM

Level



Product and release management team-of-team



Common mission, backlog, estimates, and sprints



Value delivery

via program-level

epics

and

features

27

A

GILE

R

ELEASE

T

RAINS

●

Driven by vision and roadmap

●

Lean, economic prioritization

●

Frequent, quality deliveries

●

Fast customer feedback

●

Fixed, reliable cadence

●

Regular inspect & adapt CI

Alignment

Collaboration

Synchronization

Delivery

Value







(28)

SAFe—Scaling at

T

EAM

Level



Empowered, self-organizing cross-functional teams



Hybrid of Scrum PM & XP technical best practices



Value delivery

via

empowerment

,

quality

,

and

CI

28

A

GILE

C

ODE

Q

UALITY

●

Pair development

●

Emergent design

●

Test-first

●

Refactoring

●

Continuous integration

●

Collective ownership

Product

Quality

Satisfaction

Customer

Predictability

Speed







(29)

SAFe Benefits

29

Leffingwell, D. (2014). Scaled agile framework (SAFe) case studies. Denver, CO: Leffingwell, LLC.

Rico, D. F. (2014). Scaled agile framework (SAFe) benefits. Retrieved June 2, 2014, from http://davidfrico.com/safe-benefits.txt



Cycle time and quality are most notable improvement



Productivity on par with Scrum at 10X above normal



Data shows

SAFe scales

to teams of

1,000+ people

Benefit Nokia SEI Telstra BMC Trade Station

Discount

Tire Valpak Mitchell

John

Deere Spotify Comcast Average App Maps Trading DW IT Trading Retail Market Insurance Agricult. Cable PoS

Weeks 95.3 2 52 52 52 52 51 People 520 400 75 300 100 90 300 800 150 120 286 Teams 66 30 9 10 10 9 60 80 15 12 30 Satis 25% 29% 15% 23% Costs 50% 10% 30% Product 2000% 25% 10% 678% Quality 95% 44% 50% 50% 60% Cycle 600% 600% 300% 50% 300% 370% ROI 2500% 200% 1350% Morale 43% 63% 10% 39%



(30)

SAFe Case Studies



Most U.S. Fortune 500 companies adopting SAFe



Goal to integrate enterprise, portfolios, and systems



Capital One going through

end-to-end SAFe adoption

30

John Deere

Spotify

Comcast

•

Agricultural automation

•

800 developers on 80 teams

•

Rolled out SAFe in one year

•

Transitioned to open spaces

•

Field issue resolution up 42%

•

Quality improvement up 50%

•

Warranty expense down 50%

•

Time to production down 20%

•

Time to market down 20%

•

Job engagement up 10%

•

Television cable/DVR boxes

•

Embedded & server-side

•

Cycle time - 12 to 4 months

•

Support 11 million+ DVRs

•

Design features vs. layers

•

Releases delivered on-time

•

100% capabilities delivered

•

95% requirements delivered

•

Fully automated sprint tests

•

GUI-based point of sale sys

•

Switched from CMMI to SAFe

•

QA to new feature focus

•

Used Rally adoption model

•

10% productivity improvement

•

10% cost of quality reduction

•

200% improved defect density

•

Production defects down 50%

•

Value vs. compliance focus

Leffingwell, D. (2014). Scaled agile framework (SAFe) case studies. Denver, CO: Leffingwell, LLC.

Rico, D. F. (2014). Scaled agile framework (SAFe) benefits. Retrieved June 2, 2014, from http://davidfrico.com/safe-benefits.txt

(31)

SAFe Summary



Lean-agile frameworks & tools emerging in droves



Focus on scaling agility to enterprises & portfolios



SAFe emerging as the

clear international leader

31

Rico, D. F. (2014). Dave's Notes: For Scaling with SAFe, DaD, LeSS, RAGE, ScrumPLoP, Enterprise Scrum, etc. Retrieved March 28, 2014 from http://davidfrico.com



SAFe is extremely

well-defined

in books and Internet



SAFe has ample

training

,

certification

,

consulting,

etc.



SAFe leads to increased

productivity

and

quality



SAFe is scalable to teams of up to

1,000+

developers



SAFe is preferred agile approach of

Global 500

firms



SAFe is agile choice for

public sector IT acquisitions



SAFe

cases

and

performance data

rapidly emerging

(32)

Enterprise Continuous Delivery



Created by Jez Humble of ThoughtWorks in 2011



Includes CM, build, testing, integration, release, etc.



Goal is

one-touch

automation of

deployment pipeline

32

Humble, J., & Farley, D. (2011). Continuous delivery. Boston, MA: Pearson Education.

Duvall, P., Matyas, S., & Glover, A. (2006). Continuous integration. Boston, MA: Addison-Wesley.

Ohara, D. (2012). Continuous delivery and the world of devops. San Francisco, CA: GigaOM Pro.



CoQ

• 80% MS Tst • 8/10 No Val • $24B in 90s • Rep by CD • Not Add MLK

(33)

Continuous Integration



Fewer integrations leave in higher bug counts



Frequent, early integrations eliminate most defects



Goal is to have as many

early integrations as possible

33

Lacoste, F. J. (2009). Killing the gatekeeper: Introducing a continuous integration system. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA, 387-392.





Number of

Integrations

Less Defects

•

More Integrations

•

Early Integrations

More Defects

•

Few Integrations

•

Late Integrations



(34)

Continuous Delivery (Assembla)



Goal of continuous delivery is releases vs. build/tests



Market-driven releases creates rapid business value



Assembla went from

2

to

45 monthly releases

w/CD

34

Singleton, A. (2014). Unblock: A guide to the new continuous agile. Needham, MA: Assembla, Inc.



62x Faster

U.S. DoD

IT Project

3,645x Faster

U.S. DoD

IT Project



(35)

Agile Scaling at Google



Google early adopter of agile methods and Scrum



Google also uses agile testing at enterprise scale



15,000 developers

run

120 million tests

per day

35

Micco, J. (2013). Continuous integration at google scale. Eclipse Con, Boston, MA.

Whittaker, J., Arbon, J., & Carollo, J. (2012). How google tests software. Upper Saddle River, NJ: Pearson Education.



440 billion unique users run 37 trillion searches each year



Single monolithic code tree with mixed language code



Submissions at head – One branch – All from source



20+ code changes/minute – 50% code change/month



5,500+ submissions/day – 120 million tests per day



80,000 builds per day – 20 million builds per year



Auto code inspections – For low defect density



10X programming productivity improvement



$150 million in annual labor savings

(ROI as a result)



(36)

Agile Scaling at Amazon



Amazon adopted agile in 1999 and Scrum in 2004



Using enterprise-scale continuous delivery by 2010



30,000+ developers

deploy over

8,600 releases

a day

36

Atlas, A. (2009). Accidental adoption: The story of scrum at amazon.com. Proceedings of the Agile 2009 Conference, Chicago, Illinois, USA, 135-140.

Jenkins, J. (2011). Velocity culture at amazon.com. Proceedings of the Velocity 2011 Conference, Santa Clara, California, USA.

Elisha, S. (2013). Continuous deployment with amazon web services. Proceedings of the AWS Summit 2013, Sydney, New South Wales, Australia.



Software deployment every 11.6 seconds

(as of 2011)



24,828

to

86,320

releases

per Iteration



161,379

to

561,080

releases

per Quarter



645,517

to

2,244,320

releases

per Year



Automatic, split-second roll-forward & backward



75-90% reduction in release-caused outages (0.001%)



Millions of times faster

(than traditional methods)



4,357,241 to 15,149,160 per traditional release



Thousands of times faster

(

than manual agility)



161,379 to 561,080 per Scrum/SAFe release



Used agile methods long before U.S. government

(1999)





(37)

Agile Scaling w/Amazon Web Svcs



AWS is most popular cloud computing platform



Scalable service with end-to-end security & privacy



AWS is

compliant

&

certified

to

30+

indiv.

S&P stds.

37

Barr, J. (2014). AWS achieves DoD provisional authorization. Retrieved January 12, 2015, from http://aws.amazon.com

Dignan, L. (2014). Amazon web services lands DoD security authorization. Retrieved January 12, 2015, from http://www.zdnet.com

Amazon.com (2015). AWS govcloud earns DoD CSM Levsl 3-5 provisional authorization. Retrieved January 12, 2015, from http://aws.amazon.com

Analytics

Database

SSAE

Cross

Service

Networking

Compute &

SOC

Application

Services

Content Del.

Storage &

Deployment &

Management

DoD CSM DIACAP FedRAMP

FIPS

COBIT

CSA

AICPA

FISMA

GLBA

HITECH

SAS

ITAR

ISO/IEC

ISAE

HIPAA

NIST

MPAA

PCI





NoSQL Sols

• MongoDB

• Cassandra

• HBase



(38)

Agile Leadership

Rico, D. F. (2013). Agile coaching in high-conflict environments. Retrieved April 11, 2013 from http://davidfrico.com/agile-conflict-mgt.pdf

Rico, D. F. (2013). Agile project management for virtual distributed teams. Retrieved July 29, 2013 from http://www.davidfrico.com/rico13m.pdf

Rico, D. F. (2013). Agile vs. traditional contract manifesto. Retrieved March 28, 2013 from http://www.davidfrico.com/agile-vs-trad-contract-manifesto.pdf

38

Personal

Project

Enterprise

•

Don't Be a Know-it-All

•

Be Open & Willing to Learn

• Treat People Respectfully

•

Be Gracious, Humble, & Kind

•

Listen & Be Slow-to-Speak

•

Be Patient & Longsuffering

•

Be Objective & Dispassionate

• Don't Micromanage & Direct

•

Exhibit Maturity & Composure

•

Don't Escalate or Exacerbate

•

Don't Gossip or be Negative

• Delegate, Empower, & Trust

•

Gently Coach, Guide, & Lead

•

Customer Communication

• Product Visioning

•

Distribution Strategy

• Team Development

•

Standards & Practices

•

Telecom Infrastructure

•

Development Tools

• High-Context Meetings

•

Coordination & Governance

•

F2F Communications

• Consensus Based Decisions

•

Performance Management

• Personal Development

• Business Value vs. Scope

•

Interactions vs. Contracts

• Relationship vs. Regulation

•

Conversation vs. Negotiation

•

Consensus vs. Dictatorship

• Collaboration vs. Control

•

Openness vs. Adversarialism

•

Exploration vs. Planning

• Incremental vs. All Inclusive

•

Entrepreneurial vs. Managerial

•

Creativity vs. Constraints

•

Satisfaction vs. Compliance

• Quality vs. Quantity



Power & authority delegated to the lowest level



Tap into the creative nuclear power of team’s talent



Coaching

,

communication

, and

relationships

key skills

(39)

Organizational Change Models

Heath, C., & Heath, D. (2010). Switch: How to change things when change is hard. New York, NY: Random House.

Patterson, K., et al. (2008). Influencer: The power to change anything: New York, NY: McGraw-Hill.

Pink, D. H. (2009). Drive: The surprising truth about what motivates us. New York, NY: Riverhead Books.

Heath, C., & Heath, D. (2013). Decisive: How to make better choices in life and work. New York, NY: Random House.



Change, no matter how small or large, is difficult



Smaller focused changes help to cross the chasm



Shrinking

,

simplifying

, and

motivation

key factors

39

SWITCH

_{Follow the bright spots} Script the critical moves

Point to the destination

Find the feeling

Shrink the change

Grow your people

Tweak the environment

Build habits

Rally the herd

Direct the Rider

Motivate the Elephant

Shape the Path

INFLUENCER

Create new experiences

Create new motives

Perfect complex skills

Build emotional skills

Recruit public personalities

Recruit influential leaders

Utilize teamwork

Enlist the power of social capital

Use incentives wisely

Use punishment sparingly

_{Make it easy} Make it unavoidable

Make it Desirable

Surpass your Limits

Harness Peer Pressure

Find Strength in Numbers

Design Rewards Change Environment

DRIVE

Purpose Autonomy Mastery

Purpose and profit equality Business and societal benefit

Share control of profits Delegate implementation

Culture and goal alignment

Remake society and globe

Be accountable to someone

Self-selected work tasks Self-directed work tasks

Self-selected timelines

Self-selected teams

Self-selected implementation

Experimentation and innovation Align tasks to abilities

Continuously improve abilities

Elevate learning over profits Create challenging tasks

Establish high expectations

DECISIVE

Villains of Good Decisions

Narrowframing

Confirmation bias Short term emotion Over confidence

Widen Your Options

Avoid a narrow frame Multi-track

Find someone who solved problem

Reality Test Assumptions

Consider the opposite Zoom out & zoom in

Ooch

Attain Distance

Overcome short-term emotion Gather more info & shift perspective

Self-directed work tasks

Prepare to be Wrong

Bookend the future Set a tripwire

Trust the process

(40)

Conclusion



One must

think and act small

to

accomplish big things



Slow down to speed up

,

speed up ‘til wheels come off



Scaling up

lowers

productivity

,

quality

, &

business value

40

Rico, D. F. (2014). Dave's Notes: For Scaling with SAFe, DaD, LeSS, RAGE, ScrumPLoP, Enterprise Scrum, etc. Retrieved March 28, 2014 from http://davidfrico.com



E

MPOWER

W

ORKFORCE

- Allow workers to help establish enterprise business goals and objectives.



A

LIGN

B

USINESS

V

ALUE

- Align and focus agile teams on delivering business value to the enterprise.



P

ERFORM

V

ISIONING

- Frequently communicate portfolio, project, and team vision on continuous basis.



R

EDUCE

S

IZE

- Reduce sizes of agile portfolios, acquisitions, products, programs, projects, and teams.



A

CT

S

MALL

- Get large agile teams to act, behave, collaborate, communicate, and perform like small ones.



B

E

S

MALL

- Get small projects to act, behave, and collaborate like small ones instead of trying to act larger.



A

CT

C

OLLOCATED

- Get virtual distributed teams to act, behave, communicate and perform like collocated ones.



U

SE

S

MALL

A

CQUISITION

B

ATCHES

- Organize suppliers to rapidly deliver new capabilities and quickly reprioritize.



U

SE

L

EAN

-A

GILE

C

ONTRACTS

- Use collaborative contracts to share responsibility instead of adversarial legal ones.



U

SE

E

NTERPRISE

A

UTOMATION

- Automate everything with Continuous Integration, Continuous Delivery, & DevOps.



(41)

Dave’s Professional Capabilities

41

Software

Quality

Mgt.

Technical

Project

Mgt.

Software

Development

Methods

Organization

Change

Systems

Engineering

Cost

Estimating

Government

Contracting

Government

Acquisitions

Lean

Kanban

Big Data,

Cloud, NoSQL

Workflow

Automation

Metrics,

Models, & SPC

Six

Sigma

BPR, IDEF0,

& DoDAF

DoD 5000,

TRA, & SRA

PSP, TSP, &

Code Reviews

CMMI &

ISO 9001

Innovation

Management

Statistics, CFA,

EFA, & SEM

Research

Methods

Evolutionary

Design

Valuation

— Cost-Benefit Analysis, B/CR, ROI, NPV, BEP, Real Options, etc.

Lean-Agile

— Scrum, SAFe, Continuous Integration & Delivery, DevOps, etc.

STRENGTHS

– Data Mining



Gathering & Reporting Performance Data



Strategic Planning



Executive &

Manage-ment Briefs



Brownbags & Webinars



White Papers



Tiger-Teams



Short-Fuse Tasking



Audits & Reviews



Etc.

●

Action-oriented

. Do first (

talk about it later

).

●

Data-mining/analysis

. Collect facts (

then report findings

).

●

Simplification

. Communicating complex ideas (

in simple terms

).

●

Git-r-done

. Prefer short, high-priority tasks (

vs. long bureaucratic projects

).

●

Team player

. Consensus-oriented collaboration (

vs. top-down autocratic control

).

P

MP

, C

SEP

,

A

CP

, C

SM

,

& S

AFE

32 Y

EARS

IN

IT

I

NDUSTRY

(42)

Books on ROI of SW Methods



Guides

to

software methods

for business leaders



Communicates

the

business value

of IT approaches



Rosetta stones

to unlocking

ROI

of

software methods



http://davidfrico.com/agile-book.htm

(

Description

)



http://davidfrico.com/roi-book.htm

(

Description

)

42