Continuous Delivery & DevOps Roadmap

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: Janusz.Stankiewicz@gmail.com, 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 basis?“
Mary And Tom Poppendieck
Technology is Wiping Out Companies Faster Than Ever… At Current Churn Rate, 75% of the S&P 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 basis?“
Mary And Tom Poppendieck
Let Me Twist Mary’s and Tom’s Quote a Bit
Seconds… Minutes… Hours… Days… Weeks… Months… Ages…
2015-10-02 Janusz Stankiewicz

What - Vision
"We need to figure out a way to deliver
software so fast that our Customers don't
have time to change their minds“
Mary Poppendieck
4
Chapter 2 Focus is on Enabling Fast Flow for the IT Value Stream Segment from Development through QA to
Operations… other Segments are being addressed separately

5
Now… What Options Are Available?
… And Many Many More… But Wait…

6
How About Systems Thinking, Theory of
Constraints, Lean Startup, and…
Lean Software Development + Agile?

7
Systems Thinking, Theory of Constraints, and Lean
Startup

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 customer’s
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 – the art of maximizing the
amount of work not done – 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 Waste
• Seeing Waste, Value Stream Mapping
2. Amplify Learning
• Feedback, Iterations, Synchronization, Set-Based Development
3. Decide as Late as Possible
• Options Thinking, The Last Responsible Moment, Making Decisions
4. Deliver as Fast as Possible
• Pull Systems, Queuing Theory, Cost of Delay
5. Empower the Team
• Self-Determination, Motivation, Leadership, Expertise
6. Build Integrity In
• Perceived Integrity, Conceptual Integrity, Refactoring, Testing
7. See the Whole
• 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 it.
Through this work we have come to value:
Individuals and interactions over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding 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

9
Now… Which Way…?
When we look through the lenses of Systems
Thinking, Theory of Constraints, Lean Startup,
and… Lean Software Development + Agile…
Continuous Delivery combined with DevOps is
The Sound Choice.

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
Puppet Labs 2015 State of DevOps Report, In partnership with IT Revolution. Sponsored by PwC

Where Are We Today?

Typical Mindset and Operating Culture In Command and
Control Driven Organizations
12
Strong Waterfall Mindset Deeply Rooted in Current
Operating Culture
Operating Culture:
High – Power, Oppositional and Conventional
Low – Achievement and Self-Actualizing
styles of behavior

Practice
Build management and
continuous integration
Environments and deployment
Release management and
compliance
Testing Data management
Level 3 – 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 – 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 – 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 – 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 – 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 1/2

Practice Culture Automation Lean Measurement Sharing
Level 4: Optimising
Desired elements of the culture
are identified, ingrained and
sustainable – “ the way we work
here”
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 value
Effective 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 consistently
Collaboration, 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 metrics
Managed 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
Little/no involvement
Ad-hoc learning
No monitoring or metrics
collection
Poor, ad-hoc communication and
coordination
Continuous Delivery Maturity Model 2/2

Continuous Delivery & 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 & Roll-out Phase 3 - Team and Data Driven Continuous Improvement
Time1+ … …
DevOps
Automated Environment Provisioning ImprovementsAutomated Environment Provisioning Foundations
Automated Configuration Management ImprovementsAut. Conf. Mgmt. Foundations
Lean Change Management & Management 3.0
VSM & Kaizen Quick Wins
2x2PDOT Collocation Delivery & Imp. Kanban Setup Delivery & 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 & Automated Testing Improvements

Continuous Delivery & 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
Architecture
Design
System Design Development
Integration
Testing
System
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 & Downstream Exit Points For
Full Mode 2 Projects Evolve Toward Agile Specific, As Per Results Of Experiments From Kanban Improvement Boards
Continuous Delivery & DevOps

IT Order High Level Design
Integration Design Software Code
Solution Description Integration Test Plan
Maintenance Documentation
Software Package
Register IT
Order
System Design Development
Integration
Testing
System
Testing
Deployment
Test Works Schedule
Integrated Software
UAT Test Report
17
In: Phase 1 Out: Phase 1
Continuous Delivery & DevOps Scope For IT
Orders (Small Projects)

18
Problem
Investigation
Development
Integration
Testing
System Testing Deployment
Incident Request
Problem
Investigation
Known Error Verify
Integration Test Plan
Software Package
Integrated Software
Test Works Schedule
UAT Test Report
Incident
Investigation
Development
Integration
Testing
System Testing Deployment
Incident Request Change Request Verify
Software Code
Problem Resolution
Incident Resolution
In: Phase 1 Out: Phase 1
Continuous Delivery & DevOps Scope For
Maintenance

19
Continuous Delivery?... What Is It?..
“Continuous 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.
You’re doing continuous delivery when:
• Your software is deployable throughout its lifecycle
• Your team prioritizes keeping the software deployable over working on new features
• Anybody can get fast, automated feedback on the production readiness of their
systems any time somebody makes a change to them
• You can perform push-button deployments of any version of the software to any
environment on demand
You 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 production.”
Martin Fowler
“Mode 1 organizations will likely not be performing [full scale] continuous delivery activities… 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 process.“ Gartner

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

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

Version Control
Artifact Repository
Source
Code
Commit Stage
Compile the Code
Run a Set of Commit Tests
Create Binaries
Perform Code Analysis
Prepare Test Databases…
UAT
Configure Environment
Deploy Binaries
Smoke Test
Capacity Stage
Deploy Binaries
Smoke Test
Run Capacity Tests
Production
Deploy Binaries
Smoke Test
Testers
Self-service
Deployments
Operations
Perform
Push-button
Releases
Developers
See Code Metrics
and Test Failures
Env & App
Config
Env & App
Config
Reports
Binaries
Metadata Binaries
Reports
Metadata Binaries
Reports
Metadata
Acceptance Stage
Deploy Binaries
Smoke Test
Acceptance Tests
Automated ManualJez Humble & David Farley: Continuous Delivery
22
The Key Pattern – Basic Deployment Pipeline
Production-like environment
UAT + exploratory testing,
usability testing, showcases
Duration: <5, not more than
10 min.
Unit tests + selected others
Preset thresholds: test
coverage, amount of
duplicated code, cyclomatic
complexity, afferent and
efferent coupling, number
of warnings, code style, etc.
Duration: 1 to 2 hrs.
Functional acceptance tests +
regression tests
Nonfunctional Testing:
Capacity, Security, SLA
conformance

Sample Implementation
23
You Think it’s Complex?… Well… Have You Seen Car Factory Production Line?…
http://www.ibm.com/developerworks/rational/library/deploy-industry-solutions-cloud-platform/

24
Continuous Delivery by Nhan Ngo 1/4

25

26

27

Dev QA
Ops
DevOps?… What Is It?…
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 perspective.
Gartner
The term “DevOps” 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 (i.e., high deploy rates), while
simultaneously increasing the reliability,
stability, resilience and security of the
production environment.
Gene Kim
“One of the valid complaints about DevOps is that it’s 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 (e.g., CMM-I, ITIL, Agile, etc.).” Gene Kim
Extend delivery to production – Automation *
Embed projects knowledge into Operations – Culture, Sharing *
Extend Operations feedback to projects – Monitoring *
Embed Operations knowledge into projects – Culture, Sharing *
* CAMS – core values of DevOps movement: Culture, Automation, Measurement, Sharing

29
Key DevOps Principles and Practices
“By 2020, at least 80% of the practices identified with DevOps and Mode 2 will be adopted by traditional Mode 1
groups, up from 10% today.” Garter
Source: Gartner, Cameron Haight - Principles and Practices of DevOps (March 2015)

30
Continuous Delivery is about software delivery
model from code commit to production, while
DevOps is all about how to make it work.

The Lean Change Canvas
Urgency Target Options Vision Communication Change Participants
Success Criteria Action Items
Commitment Wins / Benefits
19-Jul-2015
Iteration#7

Doing Done Doing Done Doing Done
Pursue & Scale
Pivot & Adjust
Improvements
Backlog
Next [2]
Prepare [2] Introduce [2] Learn
19-Jul-2015
Iteration#7
32
Continuous Delivery & DevOps Improvements Kanban Board

What CD & DevOps Team Topology Is Right?…
Anti-Type A: Separate Silos
Classic ‘throw it over the wall’ split between Dev,
QA and Ops
Anti-Type B: Separate CD &
DevOps Silo
The CD & DevOps team quickly forms another silo,
keeping Dev, QA and Ops further apart than ever
Anti-Type C: “We Don’t Need Ops”
Developers wildly underestimate the complexity
and importance of Ops skills and activities
Dev QA
Ops
Type 1: Smooth Collaboration
The ‘promised land’ of CD & 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 & 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 & 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 http://blog.matthewskelton.net
StartwithType5andmovetoType1

Who?...2x2 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 “external world”: 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:
- BPMS… 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 – Code commit stage
- Downstream exit point – Code ready for automated push deployment to production

35
???

Acknowledgements
While 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 – Management 3.0, Leading Agile Developers, Developing Agile Leaders
o Jez Humble and Dawid Farley – Continuous Delivery
o Paul M. Duvall and Steve Matyas, Adrew Glover – Continuous Integration
o Lisa Crispin and Janet Gregory – Agile Testing
o Gene Kim and Kevin Behr and George Soafford - The Phoenix Project
o Scott W. Ambler – Refactoring Databases, Evolutionary Database Design
o Mary Poppendieck and Tom Poppendieck – 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 – numerous posts on agilitrix.com
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 – 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 & 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

37
Appendices

Lean Change Management
38
Lean change management is a system of innovative methods for effecting change in an
organization's management, which was formulated by Jeff Anderson and Alexis Hui.
This system brings together concepts such as Agile, Lean Startup, and Kotter’s 8 Step
Model to create a feedback driven approach.

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

Lean Change Components
- Change Canvas - The canvas is an informal "plan on a page", which cover most parts of Kotter’s 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 a
successful 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.

Management 3.0
41
“Management 3.0 brings together the best thinking in the field of
complex adaptive system, Agile management, and Lean product delivery
to suggest a pragmatic framework for effective management in the 21st
century. To be successful in the face of rapidly changing market
conditions, we must create organizations that enable our people to
adapt, with a minimal amount of oversight and direction. Management
3.0 gives us a roadmap for leading teams in the face of profound
uncertainty. Jurgen [Appelo] has made a significant contribution the the
field of Agile management and leadership.”
Mike Cottmeyer, Agile Coach, LeadingAgile

Management 3.0
42
Management 1.0 = 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 2.0 = Fads
Some people realized that Management 1.0 doesn’t 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 1.0, these models assume that organizations are managed from the top, and
they help those at the top to better “design” their organizations. Sometimes it works; sometime it doesn’t.
Management 3.0 = Complexity
People may draw their organizations as hierarchies, but that doesn’t 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, don’t 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

Martie, Jurgen Appelo’s Management 3.0 Model &
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

Best Quotes From Management 3.0

Kanban Method
45
The name 'Kanban' originates from Japanese [看板], and translates
roughly as "signboard" or "billboard". It was formulated by David J.
Anderson as an approach to incremental, evolutionary process and
systems change for organizations. It uses a work-in-progress
limited pull system as the core mechanism to expose system
operation (or process) problems and stimulate collaboration to
continuously improve the system. Visualization is an important
aspect of Kanban as it allows to understand the work and the
workflow.

Kanban 9 Values
46
- Transparency
- Balance
- Collaboration
- Customer Focus
- Flow
- Leadership
- Understanding
- Agreement
- Respect

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

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)

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

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)

Kanban Board Sample

Continuous Delivery & DevOps Roadmap

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Continuous Delivery & DevOps Roadmap

Similar to Continuous Delivery & DevOps Roadmap (20)

Recently uploaded

Recently uploaded (20)

Continuous Delivery & DevOps Roadmap