continuous delivery & devops - it value stream improvements roadmap chapter 2 v8

51
Continuous Delivery & DevOps IT Value Stream Improvements Roadmap Chapter 2 This presentation was inspired and influenced by the works of many people, and I cannot possibly list them all. It has been my sincere aim to respect all copyrights and reference the authors as appropriate. If however, you feel I have not succeeded in some aspects of my intent, please contact me at my email: [email protected] , to help me correct my errors. Thank you.

Upload: janusz-stankiewicz

Post on 11-Jan-2017

1.178 views

Category:

Technology


1 download

TRANSCRIPT

Page 1: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Continuous Deliveryamp DevOps

IT Value Stream Improvements Roadmap Chapter 2

This presentation was inspired and influenced by the works of many people and I cannot possibly list them all It has been my sincere aim to respect all copyrights and reference the authors as appropriate If however you feel I have not succeeded in some aspects of my intent please contact me at my email JanuszStankiewiczgmailcom to help me correct my errors Thank you

2015-10-02 Janusz Stankiewicz 2

How long would it take your organization to deploy a change that involves just one single line of code Do you deploy changes

at this pace on a repeatable reliable basisldquo

Mary And Tom Poppendieck

Technology is Wiping Out Companies Faster Than Everhellip At Current Churn Rate 75 of the SampP 500 will be Replaced by 2027

Innosight Creative Disruption Whips Through Corporate America 2012

3

How long would it take your organization to deploy [from code commit stage to production] a change that involves just one single line of code Do you deploy changes at this pace

on a repeatable reliable basisldquo

Mary And Tom Poppendieck

Let Me Twist Maryrsquos and Tomrsquos Quote a Bit

Secondshellip Minuteshellip Hourshellip Dayshellip Weekshellip Monthshellip Ageshellip

2015-10-02 Janusz Stankiewicz

What - Vision

We need to figure out a way to deliver software so fast that our Customers dont

have time to change their mindsldquo

Mary Poppendieck

4

Chapter 2 Focus is on Enabling Fast Flow for the IT Value Stream Segment from Development through QA to Operationshellip other Segments are being addressed separately

2015-10-02 Janusz Stankiewicz

5

Nowhellip What Options Are Available

hellip And Many Many Morehellip But Waithellip2015-10-02 Janusz Stankiewicz

6

How About Systems Thinking Theory of Constraints Lean Startup andhellip

Lean Software Development + Agile

2015-10-02 Janusz Stankiewicz

7

Systems Thinking Theory of Constraints and Lean Startup

2015-10-02 Janusz Stankiewicz

Lean Software Development + Agile

8

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2 Welcome changing requirements even late in development Agile processes harness change for the customerrsquos competitive advantage

3 Deliver working software frequently from a couple of weeks to a couple of months with a preference to shorter timescale

4 Business people and developers must work together daily throughout the project

5 Build projects around motivated individuals Give them the environment and support they need and trust them to get the job done

6 Agile processes promote sustainable development The sponsors developers

and users should be able to maintain a constant pace indefinitely

7 Working software is the primary measure of progress

8 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

9 Continuous attention to technical excellence and good design enhances agility

10 Simplicity ndash the art of maximizing the amount of work not done ndash is essential

11 The best architectures requirements and designs emerge from self-organizing teams

12 At regular intervals the team reflects on how to become more effective then tunes and adjust its behavior accordingly

12 Principles of Agile Software

1 Eliminate Wastebull Seeing Waste Value Stream Mapping

2 Amplify Learningbull Feedback Iterations Synchronization Set-Based Development

3 Decide as Late as Possiblebull Options Thinking The Last Responsible Moment Making Decisions

4 Deliver as Fast as Possiblebull Pull Systems Queuing Theory Cost of Delay

5 Empower the Teambull Self-Determination Motivation Leadership Expertise

6 Build Integrity Inbull Perceived Integrity Conceptual Integrity Refactoring Testing

7 See the Wholebull Measurements Contracts

7 Principles and 22 Practices of Lean Software Development

We are uncovering better ways of developing software by doing it and helping others do itThrough this work we have come to value

Individuals and interactions over process and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is while there is value in the items on the right we value the items on the left more

The Agile Manifesto

2015-10-02 Janusz Stankiewicz

9

Nowhellip Which Wayhellip

When we look through the lenses of Systems Thinking Theory of Constraints Lean Startup

andhellip Lean Software Development + AgilehellipContinuous Delivery combined with DevOps is

The Sound Choice

2015-10-02 Janusz Stankiewicz

10

2015 State of DevOps Report

- High-performing IT organizations deploy 30x more frequently with 200x shorter lead times they have 60x fewer failures and recover 168x faster

- Lean management and continuous delivery practices create the conditions for delivering value faster sustainably

- High performance is achievable whether your apps are greenfield brownfield or legacy

- IT managers play a critical role in any DevOps transformation

- Diversity matters

- Deployment pain can tell you a lot about your IT performance

- Burnout can be prevented and DevOps can help

2015-10-02 Janusz Stankiewicz

Puppet Labs 2015 State of DevOps Report In partnership with IT Revolution Sponsored by PwC

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 2: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

2015-10-02 Janusz Stankiewicz 2

How long would it take your organization to deploy a change that involves just one single line of code Do you deploy changes

at this pace on a repeatable reliable basisldquo

Mary And Tom Poppendieck

Technology is Wiping Out Companies Faster Than Everhellip At Current Churn Rate 75 of the SampP 500 will be Replaced by 2027

Innosight Creative Disruption Whips Through Corporate America 2012

3

How long would it take your organization to deploy [from code commit stage to production] a change that involves just one single line of code Do you deploy changes at this pace

on a repeatable reliable basisldquo

Mary And Tom Poppendieck

Let Me Twist Maryrsquos and Tomrsquos Quote a Bit

Secondshellip Minuteshellip Hourshellip Dayshellip Weekshellip Monthshellip Ageshellip

2015-10-02 Janusz Stankiewicz

What - Vision

We need to figure out a way to deliver software so fast that our Customers dont

have time to change their mindsldquo

Mary Poppendieck

4

Chapter 2 Focus is on Enabling Fast Flow for the IT Value Stream Segment from Development through QA to Operationshellip other Segments are being addressed separately

2015-10-02 Janusz Stankiewicz

5

Nowhellip What Options Are Available

hellip And Many Many Morehellip But Waithellip2015-10-02 Janusz Stankiewicz

6

How About Systems Thinking Theory of Constraints Lean Startup andhellip

Lean Software Development + Agile

2015-10-02 Janusz Stankiewicz

7

Systems Thinking Theory of Constraints and Lean Startup

2015-10-02 Janusz Stankiewicz

Lean Software Development + Agile

8

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2 Welcome changing requirements even late in development Agile processes harness change for the customerrsquos competitive advantage

3 Deliver working software frequently from a couple of weeks to a couple of months with a preference to shorter timescale

4 Business people and developers must work together daily throughout the project

5 Build projects around motivated individuals Give them the environment and support they need and trust them to get the job done

6 Agile processes promote sustainable development The sponsors developers

and users should be able to maintain a constant pace indefinitely

7 Working software is the primary measure of progress

8 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

9 Continuous attention to technical excellence and good design enhances agility

10 Simplicity ndash the art of maximizing the amount of work not done ndash is essential

11 The best architectures requirements and designs emerge from self-organizing teams

12 At regular intervals the team reflects on how to become more effective then tunes and adjust its behavior accordingly

12 Principles of Agile Software

1 Eliminate Wastebull Seeing Waste Value Stream Mapping

2 Amplify Learningbull Feedback Iterations Synchronization Set-Based Development

3 Decide as Late as Possiblebull Options Thinking The Last Responsible Moment Making Decisions

4 Deliver as Fast as Possiblebull Pull Systems Queuing Theory Cost of Delay

5 Empower the Teambull Self-Determination Motivation Leadership Expertise

6 Build Integrity Inbull Perceived Integrity Conceptual Integrity Refactoring Testing

7 See the Wholebull Measurements Contracts

7 Principles and 22 Practices of Lean Software Development

We are uncovering better ways of developing software by doing it and helping others do itThrough this work we have come to value

Individuals and interactions over process and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is while there is value in the items on the right we value the items on the left more

The Agile Manifesto

2015-10-02 Janusz Stankiewicz

9

Nowhellip Which Wayhellip

When we look through the lenses of Systems Thinking Theory of Constraints Lean Startup

andhellip Lean Software Development + AgilehellipContinuous Delivery combined with DevOps is

The Sound Choice

2015-10-02 Janusz Stankiewicz

10

2015 State of DevOps Report

- High-performing IT organizations deploy 30x more frequently with 200x shorter lead times they have 60x fewer failures and recover 168x faster

- Lean management and continuous delivery practices create the conditions for delivering value faster sustainably

- High performance is achievable whether your apps are greenfield brownfield or legacy

- IT managers play a critical role in any DevOps transformation

- Diversity matters

- Deployment pain can tell you a lot about your IT performance

- Burnout can be prevented and DevOps can help

2015-10-02 Janusz Stankiewicz

Puppet Labs 2015 State of DevOps Report In partnership with IT Revolution Sponsored by PwC

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 3: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

3

How long would it take your organization to deploy [from code commit stage to production] a change that involves just one single line of code Do you deploy changes at this pace

on a repeatable reliable basisldquo

Mary And Tom Poppendieck

Let Me Twist Maryrsquos and Tomrsquos Quote a Bit

Secondshellip Minuteshellip Hourshellip Dayshellip Weekshellip Monthshellip Ageshellip

2015-10-02 Janusz Stankiewicz

What - Vision

We need to figure out a way to deliver software so fast that our Customers dont

have time to change their mindsldquo

Mary Poppendieck

4

Chapter 2 Focus is on Enabling Fast Flow for the IT Value Stream Segment from Development through QA to Operationshellip other Segments are being addressed separately

2015-10-02 Janusz Stankiewicz

5

Nowhellip What Options Are Available

hellip And Many Many Morehellip But Waithellip2015-10-02 Janusz Stankiewicz

6

How About Systems Thinking Theory of Constraints Lean Startup andhellip

Lean Software Development + Agile

2015-10-02 Janusz Stankiewicz

7

Systems Thinking Theory of Constraints and Lean Startup

2015-10-02 Janusz Stankiewicz

Lean Software Development + Agile

8

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2 Welcome changing requirements even late in development Agile processes harness change for the customerrsquos competitive advantage

3 Deliver working software frequently from a couple of weeks to a couple of months with a preference to shorter timescale

4 Business people and developers must work together daily throughout the project

5 Build projects around motivated individuals Give them the environment and support they need and trust them to get the job done

6 Agile processes promote sustainable development The sponsors developers

and users should be able to maintain a constant pace indefinitely

7 Working software is the primary measure of progress

8 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

9 Continuous attention to technical excellence and good design enhances agility

10 Simplicity ndash the art of maximizing the amount of work not done ndash is essential

11 The best architectures requirements and designs emerge from self-organizing teams

12 At regular intervals the team reflects on how to become more effective then tunes and adjust its behavior accordingly

12 Principles of Agile Software

1 Eliminate Wastebull Seeing Waste Value Stream Mapping

2 Amplify Learningbull Feedback Iterations Synchronization Set-Based Development

3 Decide as Late as Possiblebull Options Thinking The Last Responsible Moment Making Decisions

4 Deliver as Fast as Possiblebull Pull Systems Queuing Theory Cost of Delay

5 Empower the Teambull Self-Determination Motivation Leadership Expertise

6 Build Integrity Inbull Perceived Integrity Conceptual Integrity Refactoring Testing

7 See the Wholebull Measurements Contracts

7 Principles and 22 Practices of Lean Software Development

We are uncovering better ways of developing software by doing it and helping others do itThrough this work we have come to value

Individuals and interactions over process and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is while there is value in the items on the right we value the items on the left more

The Agile Manifesto

2015-10-02 Janusz Stankiewicz

9

Nowhellip Which Wayhellip

When we look through the lenses of Systems Thinking Theory of Constraints Lean Startup

andhellip Lean Software Development + AgilehellipContinuous Delivery combined with DevOps is

The Sound Choice

2015-10-02 Janusz Stankiewicz

10

2015 State of DevOps Report

- High-performing IT organizations deploy 30x more frequently with 200x shorter lead times they have 60x fewer failures and recover 168x faster

- Lean management and continuous delivery practices create the conditions for delivering value faster sustainably

- High performance is achievable whether your apps are greenfield brownfield or legacy

- IT managers play a critical role in any DevOps transformation

- Diversity matters

- Deployment pain can tell you a lot about your IT performance

- Burnout can be prevented and DevOps can help

2015-10-02 Janusz Stankiewicz

Puppet Labs 2015 State of DevOps Report In partnership with IT Revolution Sponsored by PwC

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 4: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

What - Vision

We need to figure out a way to deliver software so fast that our Customers dont

have time to change their mindsldquo

Mary Poppendieck

4

Chapter 2 Focus is on Enabling Fast Flow for the IT Value Stream Segment from Development through QA to Operationshellip other Segments are being addressed separately

2015-10-02 Janusz Stankiewicz

5

Nowhellip What Options Are Available

hellip And Many Many Morehellip But Waithellip2015-10-02 Janusz Stankiewicz

6

How About Systems Thinking Theory of Constraints Lean Startup andhellip

Lean Software Development + Agile

2015-10-02 Janusz Stankiewicz

7

Systems Thinking Theory of Constraints and Lean Startup

2015-10-02 Janusz Stankiewicz

Lean Software Development + Agile

8

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2 Welcome changing requirements even late in development Agile processes harness change for the customerrsquos competitive advantage

3 Deliver working software frequently from a couple of weeks to a couple of months with a preference to shorter timescale

4 Business people and developers must work together daily throughout the project

5 Build projects around motivated individuals Give them the environment and support they need and trust them to get the job done

6 Agile processes promote sustainable development The sponsors developers

and users should be able to maintain a constant pace indefinitely

7 Working software is the primary measure of progress

8 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

9 Continuous attention to technical excellence and good design enhances agility

10 Simplicity ndash the art of maximizing the amount of work not done ndash is essential

11 The best architectures requirements and designs emerge from self-organizing teams

12 At regular intervals the team reflects on how to become more effective then tunes and adjust its behavior accordingly

12 Principles of Agile Software

1 Eliminate Wastebull Seeing Waste Value Stream Mapping

2 Amplify Learningbull Feedback Iterations Synchronization Set-Based Development

3 Decide as Late as Possiblebull Options Thinking The Last Responsible Moment Making Decisions

4 Deliver as Fast as Possiblebull Pull Systems Queuing Theory Cost of Delay

5 Empower the Teambull Self-Determination Motivation Leadership Expertise

6 Build Integrity Inbull Perceived Integrity Conceptual Integrity Refactoring Testing

7 See the Wholebull Measurements Contracts

7 Principles and 22 Practices of Lean Software Development

We are uncovering better ways of developing software by doing it and helping others do itThrough this work we have come to value

Individuals and interactions over process and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is while there is value in the items on the right we value the items on the left more

The Agile Manifesto

2015-10-02 Janusz Stankiewicz

9

Nowhellip Which Wayhellip

When we look through the lenses of Systems Thinking Theory of Constraints Lean Startup

andhellip Lean Software Development + AgilehellipContinuous Delivery combined with DevOps is

The Sound Choice

2015-10-02 Janusz Stankiewicz

10

2015 State of DevOps Report

- High-performing IT organizations deploy 30x more frequently with 200x shorter lead times they have 60x fewer failures and recover 168x faster

- Lean management and continuous delivery practices create the conditions for delivering value faster sustainably

- High performance is achievable whether your apps are greenfield brownfield or legacy

- IT managers play a critical role in any DevOps transformation

- Diversity matters

- Deployment pain can tell you a lot about your IT performance

- Burnout can be prevented and DevOps can help

2015-10-02 Janusz Stankiewicz

Puppet Labs 2015 State of DevOps Report In partnership with IT Revolution Sponsored by PwC

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 5: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

5

Nowhellip What Options Are Available

hellip And Many Many Morehellip But Waithellip2015-10-02 Janusz Stankiewicz

6

How About Systems Thinking Theory of Constraints Lean Startup andhellip

Lean Software Development + Agile

2015-10-02 Janusz Stankiewicz

7

Systems Thinking Theory of Constraints and Lean Startup

2015-10-02 Janusz Stankiewicz

Lean Software Development + Agile

8

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2 Welcome changing requirements even late in development Agile processes harness change for the customerrsquos competitive advantage

3 Deliver working software frequently from a couple of weeks to a couple of months with a preference to shorter timescale

4 Business people and developers must work together daily throughout the project

5 Build projects around motivated individuals Give them the environment and support they need and trust them to get the job done

6 Agile processes promote sustainable development The sponsors developers

and users should be able to maintain a constant pace indefinitely

7 Working software is the primary measure of progress

8 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

9 Continuous attention to technical excellence and good design enhances agility

10 Simplicity ndash the art of maximizing the amount of work not done ndash is essential

11 The best architectures requirements and designs emerge from self-organizing teams

12 At regular intervals the team reflects on how to become more effective then tunes and adjust its behavior accordingly

12 Principles of Agile Software

1 Eliminate Wastebull Seeing Waste Value Stream Mapping

2 Amplify Learningbull Feedback Iterations Synchronization Set-Based Development

3 Decide as Late as Possiblebull Options Thinking The Last Responsible Moment Making Decisions

4 Deliver as Fast as Possiblebull Pull Systems Queuing Theory Cost of Delay

5 Empower the Teambull Self-Determination Motivation Leadership Expertise

6 Build Integrity Inbull Perceived Integrity Conceptual Integrity Refactoring Testing

7 See the Wholebull Measurements Contracts

7 Principles and 22 Practices of Lean Software Development

We are uncovering better ways of developing software by doing it and helping others do itThrough this work we have come to value

Individuals and interactions over process and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is while there is value in the items on the right we value the items on the left more

The Agile Manifesto

2015-10-02 Janusz Stankiewicz

9

Nowhellip Which Wayhellip

When we look through the lenses of Systems Thinking Theory of Constraints Lean Startup

andhellip Lean Software Development + AgilehellipContinuous Delivery combined with DevOps is

The Sound Choice

2015-10-02 Janusz Stankiewicz

10

2015 State of DevOps Report

- High-performing IT organizations deploy 30x more frequently with 200x shorter lead times they have 60x fewer failures and recover 168x faster

- Lean management and continuous delivery practices create the conditions for delivering value faster sustainably

- High performance is achievable whether your apps are greenfield brownfield or legacy

- IT managers play a critical role in any DevOps transformation

- Diversity matters

- Deployment pain can tell you a lot about your IT performance

- Burnout can be prevented and DevOps can help

2015-10-02 Janusz Stankiewicz

Puppet Labs 2015 State of DevOps Report In partnership with IT Revolution Sponsored by PwC

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 6: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

6

How About Systems Thinking Theory of Constraints Lean Startup andhellip

Lean Software Development + Agile

2015-10-02 Janusz Stankiewicz

7

Systems Thinking Theory of Constraints and Lean Startup

2015-10-02 Janusz Stankiewicz

Lean Software Development + Agile

8

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2 Welcome changing requirements even late in development Agile processes harness change for the customerrsquos competitive advantage

3 Deliver working software frequently from a couple of weeks to a couple of months with a preference to shorter timescale

4 Business people and developers must work together daily throughout the project

5 Build projects around motivated individuals Give them the environment and support they need and trust them to get the job done

6 Agile processes promote sustainable development The sponsors developers

and users should be able to maintain a constant pace indefinitely

7 Working software is the primary measure of progress

8 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

9 Continuous attention to technical excellence and good design enhances agility

10 Simplicity ndash the art of maximizing the amount of work not done ndash is essential

11 The best architectures requirements and designs emerge from self-organizing teams

12 At regular intervals the team reflects on how to become more effective then tunes and adjust its behavior accordingly

12 Principles of Agile Software

1 Eliminate Wastebull Seeing Waste Value Stream Mapping

2 Amplify Learningbull Feedback Iterations Synchronization Set-Based Development

3 Decide as Late as Possiblebull Options Thinking The Last Responsible Moment Making Decisions

4 Deliver as Fast as Possiblebull Pull Systems Queuing Theory Cost of Delay

5 Empower the Teambull Self-Determination Motivation Leadership Expertise

6 Build Integrity Inbull Perceived Integrity Conceptual Integrity Refactoring Testing

7 See the Wholebull Measurements Contracts

7 Principles and 22 Practices of Lean Software Development

We are uncovering better ways of developing software by doing it and helping others do itThrough this work we have come to value

Individuals and interactions over process and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is while there is value in the items on the right we value the items on the left more

The Agile Manifesto

2015-10-02 Janusz Stankiewicz

9

Nowhellip Which Wayhellip

When we look through the lenses of Systems Thinking Theory of Constraints Lean Startup

andhellip Lean Software Development + AgilehellipContinuous Delivery combined with DevOps is

The Sound Choice

2015-10-02 Janusz Stankiewicz

10

2015 State of DevOps Report

- High-performing IT organizations deploy 30x more frequently with 200x shorter lead times they have 60x fewer failures and recover 168x faster

- Lean management and continuous delivery practices create the conditions for delivering value faster sustainably

- High performance is achievable whether your apps are greenfield brownfield or legacy

- IT managers play a critical role in any DevOps transformation

- Diversity matters

- Deployment pain can tell you a lot about your IT performance

- Burnout can be prevented and DevOps can help

2015-10-02 Janusz Stankiewicz

Puppet Labs 2015 State of DevOps Report In partnership with IT Revolution Sponsored by PwC

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 7: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

7

Systems Thinking Theory of Constraints and Lean Startup

2015-10-02 Janusz Stankiewicz

Lean Software Development + Agile

8

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2 Welcome changing requirements even late in development Agile processes harness change for the customerrsquos competitive advantage

3 Deliver working software frequently from a couple of weeks to a couple of months with a preference to shorter timescale

4 Business people and developers must work together daily throughout the project

5 Build projects around motivated individuals Give them the environment and support they need and trust them to get the job done

6 Agile processes promote sustainable development The sponsors developers

and users should be able to maintain a constant pace indefinitely

7 Working software is the primary measure of progress

8 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

9 Continuous attention to technical excellence and good design enhances agility

10 Simplicity ndash the art of maximizing the amount of work not done ndash is essential

11 The best architectures requirements and designs emerge from self-organizing teams

12 At regular intervals the team reflects on how to become more effective then tunes and adjust its behavior accordingly

12 Principles of Agile Software

1 Eliminate Wastebull Seeing Waste Value Stream Mapping

2 Amplify Learningbull Feedback Iterations Synchronization Set-Based Development

3 Decide as Late as Possiblebull Options Thinking The Last Responsible Moment Making Decisions

4 Deliver as Fast as Possiblebull Pull Systems Queuing Theory Cost of Delay

5 Empower the Teambull Self-Determination Motivation Leadership Expertise

6 Build Integrity Inbull Perceived Integrity Conceptual Integrity Refactoring Testing

7 See the Wholebull Measurements Contracts

7 Principles and 22 Practices of Lean Software Development

We are uncovering better ways of developing software by doing it and helping others do itThrough this work we have come to value

Individuals and interactions over process and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is while there is value in the items on the right we value the items on the left more

The Agile Manifesto

2015-10-02 Janusz Stankiewicz

9

Nowhellip Which Wayhellip

When we look through the lenses of Systems Thinking Theory of Constraints Lean Startup

andhellip Lean Software Development + AgilehellipContinuous Delivery combined with DevOps is

The Sound Choice

2015-10-02 Janusz Stankiewicz

10

2015 State of DevOps Report

- High-performing IT organizations deploy 30x more frequently with 200x shorter lead times they have 60x fewer failures and recover 168x faster

- Lean management and continuous delivery practices create the conditions for delivering value faster sustainably

- High performance is achievable whether your apps are greenfield brownfield or legacy

- IT managers play a critical role in any DevOps transformation

- Diversity matters

- Deployment pain can tell you a lot about your IT performance

- Burnout can be prevented and DevOps can help

2015-10-02 Janusz Stankiewicz

Puppet Labs 2015 State of DevOps Report In partnership with IT Revolution Sponsored by PwC

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 8: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Lean Software Development + Agile

8

1 Our highest priority is to satisfy the customer through early and continuous delivery of valuable software

2 Welcome changing requirements even late in development Agile processes harness change for the customerrsquos competitive advantage

3 Deliver working software frequently from a couple of weeks to a couple of months with a preference to shorter timescale

4 Business people and developers must work together daily throughout the project

5 Build projects around motivated individuals Give them the environment and support they need and trust them to get the job done

6 Agile processes promote sustainable development The sponsors developers

and users should be able to maintain a constant pace indefinitely

7 Working software is the primary measure of progress

8 The most efficient and effective method of conveying information to and within a development team is face-to-face conversation

9 Continuous attention to technical excellence and good design enhances agility

10 Simplicity ndash the art of maximizing the amount of work not done ndash is essential

11 The best architectures requirements and designs emerge from self-organizing teams

12 At regular intervals the team reflects on how to become more effective then tunes and adjust its behavior accordingly

12 Principles of Agile Software

1 Eliminate Wastebull Seeing Waste Value Stream Mapping

2 Amplify Learningbull Feedback Iterations Synchronization Set-Based Development

3 Decide as Late as Possiblebull Options Thinking The Last Responsible Moment Making Decisions

4 Deliver as Fast as Possiblebull Pull Systems Queuing Theory Cost of Delay

5 Empower the Teambull Self-Determination Motivation Leadership Expertise

6 Build Integrity Inbull Perceived Integrity Conceptual Integrity Refactoring Testing

7 See the Wholebull Measurements Contracts

7 Principles and 22 Practices of Lean Software Development

We are uncovering better ways of developing software by doing it and helping others do itThrough this work we have come to value

Individuals and interactions over process and toolsWorking software over comprehensive documentation

Customer collaboration over contract negotiationResponding to change over following a plan

That is while there is value in the items on the right we value the items on the left more

The Agile Manifesto

2015-10-02 Janusz Stankiewicz

9

Nowhellip Which Wayhellip

When we look through the lenses of Systems Thinking Theory of Constraints Lean Startup

andhellip Lean Software Development + AgilehellipContinuous Delivery combined with DevOps is

The Sound Choice

2015-10-02 Janusz Stankiewicz

10

2015 State of DevOps Report

- High-performing IT organizations deploy 30x more frequently with 200x shorter lead times they have 60x fewer failures and recover 168x faster

- Lean management and continuous delivery practices create the conditions for delivering value faster sustainably

- High performance is achievable whether your apps are greenfield brownfield or legacy

- IT managers play a critical role in any DevOps transformation

- Diversity matters

- Deployment pain can tell you a lot about your IT performance

- Burnout can be prevented and DevOps can help

2015-10-02 Janusz Stankiewicz

Puppet Labs 2015 State of DevOps Report In partnership with IT Revolution Sponsored by PwC

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 9: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

9

Nowhellip Which Wayhellip

When we look through the lenses of Systems Thinking Theory of Constraints Lean Startup

andhellip Lean Software Development + AgilehellipContinuous Delivery combined with DevOps is

The Sound Choice

2015-10-02 Janusz Stankiewicz

10

2015 State of DevOps Report

- High-performing IT organizations deploy 30x more frequently with 200x shorter lead times they have 60x fewer failures and recover 168x faster

- Lean management and continuous delivery practices create the conditions for delivering value faster sustainably

- High performance is achievable whether your apps are greenfield brownfield or legacy

- IT managers play a critical role in any DevOps transformation

- Diversity matters

- Deployment pain can tell you a lot about your IT performance

- Burnout can be prevented and DevOps can help

2015-10-02 Janusz Stankiewicz

Puppet Labs 2015 State of DevOps Report In partnership with IT Revolution Sponsored by PwC

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 10: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

10

2015 State of DevOps Report

- High-performing IT organizations deploy 30x more frequently with 200x shorter lead times they have 60x fewer failures and recover 168x faster

- Lean management and continuous delivery practices create the conditions for delivering value faster sustainably

- High performance is achievable whether your apps are greenfield brownfield or legacy

- IT managers play a critical role in any DevOps transformation

- Diversity matters

- Deployment pain can tell you a lot about your IT performance

- Burnout can be prevented and DevOps can help

2015-10-02 Janusz Stankiewicz

Puppet Labs 2015 State of DevOps Report In partnership with IT Revolution Sponsored by PwC

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 11: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Where Are We Today

112015-10-02 Janusz Stankiewicz

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 12: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Typical Mindset and Operating Culture In Command and Control Driven Organizations

12

Strong Waterfall Mindset Deeply Rooted in Current Operating Culture

Operating Culture High ndash Power Oppositional and Conventional

Low ndash Achievement and Self-Actualizingstyles of behavior

2015-10-02 Janusz Stankiewicz

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 13: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

PracticeBuild management and

continuous integrationEnvironments and deployment

Release management and

complianceTesting Data management

Level 3 ndash Optimizing focus on

process improvement

Teams regularly meet to discuss

integration problems and resolve

them with automation faster

feedback and better visibility

All environments managed

effectively Provisioning fully

automated Virtualisation used if

applicable

Operations and delivery teams

regularly collaborate to manage

risks and reduce cycle time

Production rollbacks rare

Defects found and fixed

immediately

Release to release feedback loop

of database performance and

deployment process

Level 2 ndash Managed Process

measured and controlled

Build metrics gathered made

visible and acted on Builds are

not left broken

Orchestrated deployments

managed Release and rollback

processes tested

Environment and application

heath monitored and proactively

managed

Quality metrics and trends

tracked Operational

requirements defined and

measured

Database upgrades and rollbacks

tested with every deployment

Database performance

monitored and optimised

Level 1 ndash Consistent Automated

processes applied across whole

lifecycle

Automated build and test cycle

every time a change is

committed Dependencies

managed Re-use of scripts and

tools

Fully automated self-service

push-button process for

deploying software Same

process to deploy to every

environment

Change management and

approvals processes defined and

enforced Regulatory and

compliance conditions met

Automated unit and acceptance

tests the latter written with

testers Testing part of

development process

Database changes performed

automatically as part of

deployment process

Level 0 ndash Repeatable Process

documented and partly

automated

Regular automated build and

testing Any build can be re-

created from source control

using automated process

Automated deployment to some

environments Creation of new

environments is cheap All

configuration is externalised

versioned

Painful and infrequent but

reliable releases Limited

traceability from requirements to

release

Automated tests written as part

of story development

Changes to databases done with

automated scripts versioned with

application

Level -1 ndash Regressive process

unrepeatable poorly controlled

and reactive

Manual processes for building

software No management of

artefacts and reports

Manual process for deploying

software Environment specific

binaries Environments are

provisioned manually

Infrequent and unreliable

releases

Manual testing after

development

Data migrations unversioned and

performed manually

Continuous Delivery Maturity Model 12

2015-10-02 Janusz Stankiewicz 13

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 14: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Practice Culture Automation Lean Measurement Sharing

Level 4 Optimising

Desired elements of the culture

are identified ingrained and

sustainable ndash ldquo the way we work

hererdquo

Continually enhancing the

employee and customer

experience

Self-service automation self-

learning using analytics and self-

remediation

Autonomous habit

Full empowerment

External learning

Measure to customer valueEffective knowledge sharing and

individual empowerment

Level 3 Adopted

Culture viewed as an asset to be

managed

Ability to adapt to changing

business needs

Collect and analyse metrics of

the automated process and

measure against business goals

Driven deployment

Majority involvement

X-process learning

Monitor using business and end-

user context

Collaboration based processes

are measured to identify

bottlenecks and inefficiencies

Level 2 Sustainable

Cultural traits that support

business strategies have been

identified

Ability to analyse trends in

culture and predict issues

Central automated processes

across the application lifecycle

Goal orientated

Selected teams

Value stream learning

Monitor resources consistentlyCollaboration shared decision

making and accountability

Level 1 In Transition

Aware of aspects in culture that

may help or hinder

Programs implemented to

address specific issues

Siloes automation no central

infrastructure

Formal structure

Only specialists

Team learning

Measure to project metricsManaged Communication some

shared decision making

Level 0 Impeded

Culture developed organically

Lack of awareness as to how

culture is impacting day-to-day

business Culture misaligned to

goals

No automation

Reactive approach

Littleno involvement

Ad-hoc learning

No monitoring or metrics

collection

Poor ad-hoc communication and

coordination

Continuous Delivery Maturity Model 22

2015-10-02 Janusz Stankiewicz 14

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 15: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Continuous Delivery amp DevOps Evolution Roadmap

15

Phase 0 - Team Setup

Phase 1 - As Is Baselining and Building the Basics

(Initiate Mindset Change)Phase 2 - To Be Progressive Development amp Roll-out Phase 3 - Team and Data Driven Continuous Improvement

Time1+ hellip hellip

DevOps

Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations

Automated Configuration Management ImprovementsAut Conf Mgmt Foundations

Lean Change Management amp Management 30

VSM amp Kaizen Quick Wins

2x2PDOT Collocation Delivery amp Imp Kanban Setup Delivery amp Improvements Kanban Operation

Continuous Delivery

Continuous Int Foundations Continuous Integration Improvements

Deployment Pipeline v1 Setup

Version Control Improvements

Deployment Pipeline Improvements

Version Control Foundations

Continuous Testing

Continuous Testing Foundations Continuous amp Automated Testing Improvements

2015-10-02 Janusz Stankiewicz

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 16: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Continuous Delivery amp DevOps Scope For Projects

16

Define Study Design Develop Close Verify

Technical Architecture High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

ArchitectureDesign

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Business Services Catalogue

Non Functional Requirements

Canonical Data Model

SOA Application Design

Test Works Schedule

Functional Test Report

Regression Test Report

Architecture Draft

Cost estimation

Updated Architecture Draft

Solution Design

Solution Architecture

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

Out Phase 0In Phase 0

In Phase 1 Out Phase 1 Out Phase 2In Phase 2 Out Phase 3

In Phase 3

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 17: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

IT Order High Level Design

Integration Design Software Code

Solution Description Integration Test Plan

Integration Test Report

Maintenance Documentation

IT Release Instruction

Software Package

Register IT Order

System Design DevelopmentIntegration

TestingSystem Testing

Deployment

Test Works Schedule

Functional Test Report

Regression Test Report

Integrated Software

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

17

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For IT Orders (Small Projects)

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 18: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

18

Problem Investigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident RequestProblem

Investigation Known Error Verify

Integration Test Plan

Integration Test Report

IT Release Instruction

Software Package

Integrated Software

Test Works Schedule

Functional Test Report

Regression Test Report

Performance Test Report

Deployment Test Report

Security Test Report

UAT Test Report

IncidentInvestigation

DevelopmentIntegration

TestingSystem Testing Deployment

Incident Request Change Request Verify

Software Code

Problem Resolution

Incident Resolution

Out Phase 0In Phase 0

In Phase 1 Out Phase 1

Out Phase 2In Phase 2

Out Phase 3In Phase 3

Continuous Delivery amp DevOps Scope For Maintenance

Governance Frameworks Principles Practices And Techniques Applied As Well As Artifacts Created Between Upstream Entry amp Downstream Exit Points For Full Mode 2 Projects Evolve Toward Agile Specific As Per Results Of Experiments From Kanban Improvement Boards

Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 19: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

19

Continuous Delivery What Is It

ldquoContinuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time Yoursquore doing continuous delivery whenbull Your software is deployable throughout its lifecyclebull Your team prioritizes keeping the software deployable over working on new featuresbull Anybody can get fast automated feedback on the production readiness of their

systems any time somebody makes a change to thembull You can perform push-button deployments of any version of the software to any

environment on demandYou achieve continuous delivery by continuously integrating the software done by the development team building executables and running automated tests on those executables to detect problems Furthermore you push the executables into increasingly production-like environments to ensure the software will work in productionrdquoMartin Fowler

ldquoMode 1 organizations will likely not be performing [full scale] continuous delivery activitieshellip Mode 1 should therefore focus on automating individual phases of the SDLC where possible While extensive automated testing may prove to be difficult to achieve these organizations should definitely plan to automate the build and deploy processldquo Gartner

2015-10-02 Janusz Stankiewicz

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 20: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Continuous Delivery Principles

20

- Create a Repeatable Reliable Process for Releasing Software

- Automate Almost Everything

- Keep Everything In Version Control

- If It Hurts Do It More Frequently and Bring the Pain Forward

- Build Quality In

- Done Means Released

- Everybody Is Responsible For Delivery

- Continuous Improvement

2015-10-02 Janusz Stankiewicz

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 21: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Continuous Delivery Practices

21

- Only Build Your Binaries Once

- Deploy the Same Way to Every Environment

- Smoke-Test Your Deployments

- Keep Your Environments Similar

- Each Change Should Propagate through the Pipeline Instantly

- If Any Part of the Pipeline Fails Stop the Line

2015-10-02 Janusz Stankiewicz

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 22: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Version Control

Artifact Repository

Source Code

Commit StageCompile the Code

Run a Set of Commit TestsCreate Binaries

Perform Code AnalysisPrepare Test Databaseshellip

UATConfigure Environment

Deploy Binaries

Smoke Test

Capacity StageConfigure Environment

Deploy BinariesSmoke Test

Run Capacity Tests

ProductionConfigure Environment

Deploy BinariesSmoke Test

TestersSelf-service

Deployments

OperationsPerform

Push-button Releases

DevelopersSee Code Metrics and Test Failures

Env amp App Config

Env amp App Config

ReportsBinaries

Metadata BinariesReports

Metadata BinariesReports

Metadata

Acceptance StageConfigure Environment

Deploy BinariesSmoke Test

Acceptance Tests

Automated ManualJez Humble amp David Farley Continuous Delivery

22

The Key Pattern ndash Basic Deployment Pipeline

Production-like environmentUAT + exploratory testing

usability testing showcases

Duration lt5 not more than 10 min

Unit tests + selected othersPreset thresholds test coverage amount of

duplicated code cyclomaticcomplexity afferent and

efferent coupling number of warnings code style etc

Duration 1 to 2 hrsProduction-like environmentFunctional acceptance tests +

regression tests

Production-like environmentNonfunctional Testing Capacity Security SLA

conformance

2015-10-02 Janusz Stankiewicz

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 23: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Sample Implementation

23

You Think itrsquos Complexhellip Wellhellip Have You Seen Car Factory Production Linehellip

httpwwwibmcomdeveloperworksrationallibrarydeploy-industry-solutions-cloud-platform

2015-10-02 Janusz Stankiewicz

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 24: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

24

Continuous Delivery by Nhan Ngo 14

2015-10-02 Janusz Stankiewicz

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 25: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

25

Continuous Delivery by Nhan Ngo 24

2015-10-02 Janusz Stankiewicz

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 26: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

26

Continuous Delivery by Nhan Ngo 34

2015-10-02 Janusz Stankiewicz

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 27: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

27

Continuous Delivery by Nhan Ngo 44

2015-10-02 Janusz Stankiewicz

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 28: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Dev QA

Ops

DevOpshellip What Is Ithellip

Dev QA Ops

DevOps represents a change in IT culture focusing on rapid IT service delivery through the adoption of agile lean practices in the context of a system-oriented approach DevOps emphasizes people (and culture) and seeks to improve collaboration between operations and development teams DevOps implementations utilize technology - especially automation tools that can leverage an increasingly programmable and dynamic infrastructure from a life cycle perspectiveGartner

The term ldquoDevOpsrdquo typically refers to the emerging professional movement that advocates a collaborative working relationship between Development and IT Operations resulting in the fast flow of planned work (ie high deploy rates) while simultaneously increasing the reliability stability resilience and security of the production environment Gene Kim

ldquoOne of the valid complaints about DevOps is that itrsquos difficult to describe what it is Currently DevOps is more like a philosophical movement and not yet a precise collection of practices descriptive or prescriptive (eg CMM-I ITIL Agile etc)rdquo Gene Kim

2015-10-02 Janusz Stankiewicz 28

Extend delivery to production ndash Automation

Embed projects knowledge into Operations ndash Culture Sharing

Extend Operations feedback to projects ndash Monitoring

Embed Operations knowledge into projects ndash Culture Sharing

CAMS ndash core values of DevOps movement Culture Automation Measurement Sharing

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 29: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

29

Key DevOps Principles and Practices

ldquoBy 2020 at least 80 of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1 groups up from 10 todayrdquo Garter

Source Gartner Cameron Haight - Principles and Practices of DevOps (March 2015)

2015-10-02 Janusz Stankiewicz

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 30: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

30

Continuous Delivery is about software delivery model from code commit to production while

DevOps is all about how to make it work

2015-10-02 Janusz Stankiewicz

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 31: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

The Lean Change Canvas

Urgency Target Options Vision Communication Change Participants

Success Criteria Action Items

Commitment Wins Benefits

19-Jul-2015

Iteration 7Continuous Delivery amp DevOps

2015-10-02 Janusz Stankiewicz 31

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 32: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Doing Done Doing Done Doing Done

Pursue amp Scale

Pivot amp Adjust

Improvements

BacklogNext [2]

Prepare [2] Introduce [2] Learn

19-Jul-2015

Iteration 7

32

Continuous Delivery amp DevOps Improvements Kanban Board

2015-10-02 Janusz Stankiewicz

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 33: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

What CD amp DevOps Team Topology Is Righthellip

2015-10-02 Janusz Stankiewicz 33

Anti-Type A Separate Silos

Classic lsquothrow it over the wallrsquo split between Dev QA and Ops

Anti-Type B Separate CD amp DevOps Silo

The CD amp DevOps team quickly forms another silo keeping Dev QA and Ops further apart than ever

Anti-Type C ldquoWe Donrsquot Need Opsrdquo

Developers wildly underestimate the complexity and importance of Ops skills and activities

Dev QA

Ops

Type 1 Smooth Collaboration

The lsquopromised landrsquo of CD amp DevOps which needs quite substantial cultural change Dev QA and Ops teams specializing where needed but also sharing where needed On top of that Dev QA and Ops must have

clearly expressed and demonstrably effective shared goal

Type 4 CD amp DevOps-as-a-Service

Suitable for smaller teams or organizations with limited experience of operational issues

Type 2 Fully Embedded

QA and Ops are fully embedded within Dev Suitable for organizations with a single main

web-based product or service

Type 3 Infrastructure-as-a-Service

Suitable for organizations with several different products and services with a traditional Ops or

whose apps run entirely in the public cloud

Type 5 Temporary CD amp DevOps Team

Suitability as a precursor to Type 1 topology Act during limited period of time (+- 12 months) as

an incubator and catalyst of the change

Matthew Skelton What Team Structure is Right for DevOps to Flourish Posted on October 22 2013 on httpblogmatthewskeltonnet

Star

t w

ith

Typ

e 5

an

d m

ove

to

Typ

e 1

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 34: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Who2x2 Pizzas DevOps Team

- 14 () People collocated core cross-functional team (Dev QA Ops) with right blend of personalities attitudes and skills with the following roles

- 2 Leaders and Key Liaison with ldquoexternal worldrdquo 1 in charge of Continuous Delivery and 1 in charge of DevOps- 3 () Systems Integrators- 3 () Developers- 2 () QA Experts- 4 () Operations Experts

- Owns automation of delivery pipeline steps from code commit to deployment to all environments including production and automation of all environments provisioning for the following set of applications to begin with

- BPMShellip for warm-up- (mBank Selected Apps from Mode 2 Set)- (Unified Front-End on new platform other)

- 3 Sources of backlog

- Projects Portfolio- IT Orders- Maintenance Requests Bug Fixes

- Upstream entry point ndash Code commit stage

- Downstream exit point ndash Code ready for automated push deployment to production

342015-10-02 Janusz Stankiewicz

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 35: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

35

2015-10-02 Janusz Stankiewicz

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 36: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

AcknowledgementsWhile working on this material I have been inspired and heavily influenced by the thinking of the following thought leaders of the agile movement and their respective publications

o Jeff Anderson - The Lean Change Method Transforming Your Technology Business through Co-Creation and Validated Learning

o Jurgen Appelo ndash Management 30 Leading Agile Developers Developing Agile Leaders

o Jez Humble and Dawid Farley ndash Continuous Delivery

o Paul M Duvall and Steve Matyas Adrew Glover ndash Continuous Integration

o Lisa Crispin and Janet Gregory ndash Agile Testing

o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project

o Scott W Ambler ndash Refactoring Databases Evolutionary Database Design

o Mary Poppendieck and Tom Poppendieck ndash Implementing Lean Software Development From Concept To Cash

o Mary Poppendieck and Tom Poppendieck - Lean Software Development An Agile Toolkit

o David J Anderson - Kanban Successful Evolutionary Change for Your Technology Business

o Michael Sahota ndash numerous posts on agilitrixcom

o Eric Ries - The Lean Startup

o Dean Leffingwell - Agile Software Requirements

o Ellen Gottesdiener and Mary Gorman - Discover to Deliver Agile Product Planning and Analysis

o Mike Cohn - Agile Estimating and Planning

o Mike Cohn ndash User Stories Applied for Agile Software Development

o Michael Nir - Agile Project Management

o Donald G Reinertsen - The Principles of Product Flow

o Craig Larman and Bas Vodde - Scaling Lean amp Agile Development

o John P Kotter - Leading Change

o Eliyahu M Goldratt and Jeff Cox - The Goal A Process of Ongoing Improvement

o Eliyahu M Goldratt - Critical Chain A Business Novel

362015-10-02 Janusz Stankiewicz

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 37: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

37

Appendices

2015-10-02 Janusz Stankiewicz

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 38: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Lean Change Management

38

Lean change management is a system of innovative methods for effecting change in an organizations management which was formulated by Jeff Anderson and Alexis Hui This system brings together concepts such as Agile Lean Startup and Kotterrsquos 8 Step

Model to create a feedback driven approach

2015-10-02 Janusz Stankiewicz

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 39: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Lean Change Key Themes

- Negotiated Change - Negotiated Change approach demands that recipients of any change are co-authors and co-implementers of all aspects of the change that they are part of Designated change agents change stakeholders and change recipients act as change co-creators ensuring that suggested changes get the buy-in necessary to ensure that they are successful

- Validated Learning - Lean Change advocates that any change plan and change target state model should be described as a set of assumptions and change agents and other change stakeholders are responsible for validating these assumptions with explicit hypotheses

- Lean Change Requires Improvements Kanban - For the lean change method to work it is required that team members adopt their own internal agile improvement method to help them identify impediments and other improvement opportunities Most Lean Change implementations have elected to use Kanban as the improvement method of choice

392015-10-02 Janusz Stankiewicz

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 40: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Lean Change Components

- Change Canvas - The canvas is an informal plan on a page which cover most parts of Kotterrsquos 8 Step Model

- Minimum Viable Changes - Smallest possible change that will enable learning whether a particular change will provide sustainable improvement

- Validated Change Lifecycle - Minimum Viable Changes are introduced to the organization through a Validated Change Lifecycle This lifecycle has been defined to maximize ability to accelerate negotiation and learning necessary to creating asuccessful change

- Capability and Performance Metrics - Lean Change also provides a number of ways to measure the impact of specific changes The first perspective is the ability of change recipients to adopt and ultimately excel at new agile and lean methods and techniques The second perspective is the impact of these techniques on actual delivery performance and value

402015-10-02 Janusz Stankiewicz

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 41: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Management 30

41

ldquoManagement 30 brings together the best thinking in the field ofcomplex adaptive system Agile management and Lean product deliveryto suggest a pragmatic framework for effective management in the 21st

century To be successful in the face of rapidly changing marketconditions we must create organizations that enable our people toadapt with a minimal amount of oversight and direction Management30 gives us a roadmap for leading teams in the face of profounduncertainty Jurgen [Appelo] has made a significant contribution the thefield of Agile management and leadershiprdquo

Mike Cottmeyer Agile Coach LeadingAgile

2015-10-02 Janusz Stankiewicz

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 42: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Management 30

42

Management 10 = Hierarchies Some people call it scientific management whereas others call it command-and-control But basic idea is the same An organization is designed and managed in a top-down fashion and power is in the hands of few

Management 20 = FadsSome people realized that Management 10 doesnrsquot work well out-of-the-box so they created numerous add-on models and services with a semi-scientific status like the Balanced Scorecard Six Sigma Theory of Constraints and Total Quality Management Being add-ons to Management 10 these models assume that organizations are managed from the top and they help those at the top to better ldquodesignrdquo their organizations Sometimes it works sometime it doesnrsquot

Management 30 = ComplexityPeople may draw their organizations as hierarchies but that doesnrsquot change that they are actually networks Second social complexity shows us that management is primarily about people and their relationships It makes us realize that we should see our organizations as living systems not as machines

A software team is a self-organizing system Support it donrsquot obstruct it

Agile managers work the system around the team not the people in the team

A team is a complex adaptive system (CAS) because it consists of parts (people) that form a system (team) which shows complex behavior while it keeps adapting

to a changing environment

2015-10-02 Janusz Stankiewicz

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 43: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Martie Jurgen Appelorsquos Management 30 Model amp Declaration Of Interdependence

43

The management hierarchy is a basic necessity (but nothing to brag about) and the bulk of the work is done in a social network of peers leaders and followers Communication flows through the network Authorization flows through the hierarchy

2015-10-02 Janusz Stankiewicz

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 44: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Best Quotes From Management 30

442015-10-02 Janusz Stankiewicz

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 45: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Kanban Method

45

The name Kanban originates from Japanese [看板] and translatesroughly as signboard or billboard It was formulated by David JAnderson as an approach to incremental evolutionary process andsystems change for organizations It uses a work-in-progresslimited pull system as the core mechanism to expose systemoperation (or process) problems and stimulate collaboration tocontinuously improve the system Visualization is an importantaspect of Kanban as it allows to understand the work and theworkflow

2015-10-02 Janusz Stankiewicz

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 46: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Kanban 9 Values

46

- Transparency

- Balance

- Collaboration

- Customer Focus

- Flow

- Leadership

- Understanding

- Agreement

- Respect

2015-10-02 Janusz Stankiewicz

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 47: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Kanban 4 Foundational Principles

47

- Start with what you do now

- Agree to pursue evolutionary change

- Initially respect current processes roles responsibilities and job titles

- Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 48: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Kanban 6 Core Practices

48

- Visualize

- Limit Work-in-Progress (WIP)

- Manage Flow

- Make policies explicit

- Implement feedback loops

- Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 49: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Mapping Values vs Foundational Principles

49

- Understanding Start with what you do now

- Agreement Agree to pursue evolutionary change

- Respect Initially respect current processes roles responsibilities and job titles

- Leadership Encourage acts of leadership at every level in your organization from individual contributor to senior management

2015-10-02 Janusz Stankiewicz

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 50: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

50

Mapping Values vs Core Practices

- Transparency Visualize

- Balance Limit Work-in-Progress (WIP)

- Customer Focus Flow Manage Flow

- Transparency Make policies explicit

- Transparency Implement feedback loops

- Collaboration Improve collaboratively evolve experimentally (using models and the scientific method)

2015-10-02 Janusz Stankiewicz

Kanban Board Sample

512015-10-02 Janusz Stankiewicz

Page 51: Continuous Delivery & DevOps - IT Value Stream Improvements Roadmap Chapter 2 v8

Kanban Board Sample

512015-10-02 Janusz Stankiewicz