2. About
Jay Harrison
DevOps Engineering Lead at Connected Home in British Gas
2 years at British Gas
Previously at Dell, Electronic Arts and Rebellion
Connected Home products include
o Hive - Remote Heating
o MyEnergy - Energy Usage Analysis
o BoilerIQ - Remote Boiler Fault Monitoring
5. Aaron Gray – A Criticism of Scrum
o http://www.aaron-gray.com/a-criticism-of-scrum/
o Assumes you can reliably estimate task duration
o Measurement impedes flow
o Far too many opportunities for bikeshedding
o Deals with project management not programming
o Doesn’t like remote workers
6. Paul Graham - Makers Schedule
o http://www.paulgraham.com/makersschedule.html
o Manager's schedule and the maker's schedule
o Manager’s schedule
o Each day cut into one hour intervals
o Meetings are a practical problem. Find an time, book them.
o Maker’s Schedule
o Half day intervals
o A single meeting can blow a whole afternoon, breaking it into two small
pieces
7. Problems with Scrum for DevOps
o High priority interrupts
o Regularly context switch
o Tend to have longer pieces of work
o Different work flow/development languages
o Sometimes tough to demo/show progress with
scripts/infrastructure as code etc
o Even more difficult when you have Operations in a silo’d team
as opposed to fully embedded
9. Types of DevOps
o Traditional silo’d teams Dev > QA > Operations
o ”DevOps team” doing core work e.g. Tooling and services such
as CI/CD, Config Mgmt, Monitoring for consumption by product
teams
o Embedded DevOps
10. DevOps In This Context
o The DevOps ideal
o Embedded in a product focused team consisting of
o Developers
o Operations
o QA
o Project management
o Product management
o No barriers to communication or collaboration
o Project and product management as facilitators to the process
11. Fitting DevOps into Scrum
o Project Manager should:
o Involve Ops in Dev process and vice versa
o Schedule work for everyone and fit it to the roadmap
o Enable collaboration
o Facilitate communication
o Get out of the way
o But also be aware that:
o Operations is not a traditional delivery function
o Ops things happen in the background
12. How To Make It Work Better
o Allow for interruptions
o Include DevOps tasks in the sprint
o Don't be surprised if the tasks overlap sprints
o Include their time worked but be realistic about sprint-end
deadlines
o Pick and choose which aspects apply, don’t implement
indiscriminately
o Kanban works better
o Take the time-box out of the equation
13. How To Make It Work Better in Silos
o Frequent communication
o Attend standups/planning
o Be involved from the start
Doesn't fit software development very well in the first place
Even harder to apply effectively to Operations/DevOps workflow
Assumes you can reliably estimate task duration
Hidden Complexity
Inconsistent overhead
Varying Distractions
Measurement impedes flow
Observer effect – The act of observation changes the observed
Imposing standup, planning, review, retro, demo, company meetings, and training actively prevents work happening
Bikeshedding
Meetings break flow, change work mode etc
Problems with scrum for ops
number of problems:
high priority interrupts - "Live platform is broken? Sorry I've got 2 hours of sprint planning!" See? Mutually exclusive.
devops/web ops/SRE/whatever regularly context switch,
tend to have longer pieces of work than 'add this feature' or 'fix this bug',
Tough to demo/show progress with scripts/infrastructure as code etc
Even more difficult when you have a Dev Ops silo as opposed to fully embedded
include their tasks in the sprint but don't be surprised if they stay there for several.
Include their time worked but be realistic about sprint-end deadlines.
Be a la carte not 'set menu' about your application of project management for devops