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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Kanban Board Sample
512015-10-02 Janusz Stankiewicz
Top Related