Scrum in dev ops teams - Presentation from Scrum Gathering Bangalore

Accenture Architecture Services
How to Apply Scrum for a
System or DevOps Team When
Implementing a New Developer
Platform

Copyright © 2014 Accenture All rights reserved.
Presenter
2
Mirco Hering
APAC DevOps & Agile Lead
@mircohering on Twitter
Blog about Agile & DevOps
http://notafactoryanymore.com

Who here is using DevOps practices?
3

DevOps &Agile
4
DevOps is a direction, not a goal!

Dunning Kruger Effect - Illusory superiority
5
Named after Ig Nobel Price winners Dunning and Kruger for their paper "Unskilled and
Unaware of It,"
They were inspired by McArthur Wheeler, who robbed a bank using “invisible ink” as a
mask
The idea that people who don't know enough also don't know enough to realise that they
don't know enough
“The trouble with the world is that the
stupid are cocksure and the intelligent are
full of doubt.“
or
"The whole problem with the world is that
fools and fanatics are always so certain of
themselves, but wiser people so full of
doubts.“ Bertrand Russell
“ignorance more frequently begets
confidence than does knowledge”
Charles Darwin

Let‘s look at some examples for Dunning-Kruger
6
• In a survey of faculty at the University of Nebraska, 68% rated themselves in
the top 25% for teaching ability. - Wikipedia
• In a similar survey, 87% of MBA students at Stanford University rated their
academic performance as above the median. - Wikipedia
• For driving skill, 93% of the US sample and 69% of the Swedish sample put
themselves in the top 50% - Wikipedia
• How do you think people would rate you as a leader?” It turns out that 74%
of the respondents think they’re either above average or the best leader
their people have ever had. – SmartBrief on Leadership

Situation Statement
The current processes and tools are not able to effectively
support a more aggressive Release Calendar
Cost to Serve increases with more releases – more effort
required to maintain processes and retrofit code
•Current Dev Arch toolset is reaching its end of life
•Not completely automated deployment process
increases chances of quality leaks as throughput increases
•Inability to support Agile at Scale – current Dev Arch was
not designed with Agile in mind
•Developer frustration with the current processes,
performance of the toolset and support available
•Inability of real-time reporting as information is stored in
different systems
•Lack of Development Architecture reporting (e.g.
Deployment timing, retrofit tracking, code reconciliation,
development churn)
7
Previous Development Architecture was build for Transformation with non-overlapping releases
and was not completely suitable for high frequency, high quality Agile delivery
Business Drivers
• User satisfaction
• Traceability
• Improved productivity
• Standardisation – reduce supported exceptions
• Quality – reduce defects related to builds &
deployment
• Reduced cost – cost of poor quality, percentage
of automated steps, build time, SCM cost
Key areas of focus
• Software Configuration Management - (baseline,
branching, merge support, admin) for code and documents
• Integration between tools – IDE, Test Automation, etc.
• Workflow Management
• Build & Deployment Automation
• Agile adoption – Agile SCRUM, Kanban, SAFe
frameworks
• Reporting

Further Context
8
~1000 Developers

What’s different? Or not so different?
9
Timelines Infrastructure Culture & Mindset

And of course…
10

It is a journey – not an implementation!
11

Change Management & Training
12
Structured Training Careful Cutover Evolution

Let’s look at how we survived in a hybrid world
13
Work Items
• Plan backlog, iterations, releases
• Capture retrospectives, Kanban wall
• Collaborate via chat, discussion walls
• Tracking & reporting on work item status
• Capture Logical Unit of Work (LUW) from IR
• Plan & estimate effort to deliver LUW
• Collaborate via chat, discussion walls
• Tracking & reporting on status of LUW’s and IR
IR
LUW
LUW
Task
Agile Delivery Lifecycle Waterfall Delivery Lifecycle
IR
Feature
Epic
Story
Task

Our Tools…promoting collaboration and delivery
transparency
14
Our virtual
wall
Videoconferencing
with our offshore
delivery team
Polycoms
Our physical
Kanban WallInformation
Radiator
(Message
Boards) Project
Information Wall

Maturity models and what we can learn from Computer
Games
Read more on my blog:
http://notafactoryanymore.com/2015/03/26/what-computer-games-can-teach-us-about-maturity-
models-choose-your-own-devops-adventure/

Model A Continuous Delivery - Application Deployment
Flow to persistent environments
Check-in,
Store in RTC SCM
Dev
Teams
(Visual
Studio)
DeploymentTailor to Env
Work
Management
Process
Dev
Test
Prod
Environment
Configuration
Identify code changes,
Compile & Package
Automation orchestration
Code Review
Crucible &
SonarQube
Automated
Test
Asset
Mgmt
App
Libraries
App*
Persistent
Envs
Test
Data
Scr
1. Creating the Application
4. Visualisation of Delivery
3. Testing the
application2. Deploying the
application
15Copyright © 2016 Accenture All rights reserved.

Model B - Application Deployment Flow into newly
provisioned environments (a.k.a. Netflix Pattern)
SCMDev
App
Work
Mgmt
Env
(Jenkins)
QA
Automated
Test
Asset
Mgmt
(App)
Lib
Env
Asset
Mgmt
(Infra) Env
Push from Jenkins or Deployment Tool
Pull from Puppet
Test
Data
Scr
5. Visualisation of
Delivery
3. Deploying the
application

Model C – Container based Application Deployment
Flow
Host
VM
Automated
Test
Env
Asset
Mgmt
(Infra)
Env
Docker
Repository
Build container from Dockerfile
SCMDev
App
Work
Mgmt
(Jenkins)
QA
Asset
Mgmt
(App)
Lib
Test
Data
Scr
2. Creating an Application
container
6. Visualisation of Delivery

We did get the results we were hoping for
Our merges took way too long (~2 weeks) and took too much effort
3.83%
3.56%
2.86%
1.92%
0.00%
0.50%
1.00%
1.50%
2.00%
2.50%
3.00%
3.50%
4.00%
4.50%
FY12-Q4 FY13-Q1 FY13-Q2 FY13-Q3
% of Merge & Retrofit Effort [on total effort]
The result: 2 weeks -> 3 days
We removed over 3300 days of manual effort per year across SCM, Build,
Package and Deploy

Early Benefits
20
Quantitative Benefits
Qualitative Benefits
Activity Measured as % Improvement Comments
Merge &
Retrofit
% of the Build Effort
across Releases
50% Based on the actual effort tracked
Software
Configuration
Management
Effort to support SCM
activities
63%
• Elimination of manual trackers [workflow lists, baselines, objects]
• Maintenance of 2 tools [CVS, CC], scorecards & run books not
required
• Unnecessary environment sync-up eliminated
Cost of poor
quality
% of defects
attributed to SCM,
Deployment
59%
Elimination of defects introduced because of previous
• Inefficient SCM processes
• Incorrect deployments
Build &
Deployment
Process & effort to
raise deployment
requests
90%
• No. of Deployment requests (DR) reduced - Enterprise build [not
incremental or individual builds]
• Effort per DR reduced because DR not in spreadsheets [now
raised on tool ] & elimination of extra step in the flow of
deployments
• Granular Configuration Management and traceability
• Integration with agile lifecycle tooling to allow story based Configuration Management driven from meta
data
• Real-Time traceability of status for build and deployment
• Automated Build and Deployments – “One Button Deployment”
• Developer efficiencies as a consequence of improved tool interaction times, processes

This is not optional…how can I help?
21

Scrum in dev ops teams - Presentation from Scrum Gathering Bangalore

Recommended

More Related Content

What's hot (20)

Viewers also liked (16)

Similar to Scrum in dev ops teams - Presentation from Scrum Gathering Bangalore (20)

More from Mirco Hering (14)

Recently uploaded (20)

Scrum in dev ops teams - Presentation from Scrum Gathering Bangalore