Ready for more DevOpsDays?

DevOpsDays DC will return June 8-9, 2016.

Scrum vs Kanban for DevOps work planning

Scribe: Clinton Wolfe, why not

• Kanban seems to work better for interrupt-driven work
• Agile works better when people need to be accountable for deliverable on a certain (artificial?) date
• During release, a dev team using scrum/agile will move on, while ops is left fixing broken things
• one possibility is to reserve a dev sprint post-launch for breakfix work
• "Scrumfall" is a thing
• Agile may be able to cope with emergent work by reducing commitment (less than historical velocity) and then * tracking emergent work explicitly
• Major problems come from different teams using different methodologies
• But the nature of different work make it a bad fit (eg scrum for ops is bogus; leads to gaming)
• Can you split people accross scrum teams? Yes, but it is an antipattern: serve two masters, accountable to neither
• VIsualizations - people like having the Kanban card move accross the board to completeion; can do similar things * with Scrum boards
• KPIs for scrum managers - KPI on velocity (leads to overcommitment), KPI on carryover (leads to undercommitment), * terrible things
• So much is dependent on staff!
• Product owners tend to have a short lifespan. Successful one get promoted, unsuccessful ones get transferred or * terminated; doing devops work (systems-related) is very hard for non-technical people to write suer stories for * sucessfully. Engineers are not great story authors by default.
• The tools don't help: they all blur lines
• Short sprints may help but may add overhead

Book: Large scale Agile Development - Grover et al