Simple Solutions should be

your Strategy

Making DevOps work in an Enterprise environment

Ignite talk By Jan-Joost Bouwman

Jan-Joost Bouwman

Twitter: @janjoostbouwman e-mail: Jan-Joost.Bouwman@ing.nl Background in: • Operations • Process management (change management) • Internal DevOps and CD evangelist since 2 years • Trying to successfully marry ITIL and DevOps • Contributor to Build Quality In

Current position within ING: • Process owner Service Operations & Service Transition (and only person

that knows what that is) • ING DevOps community manager • Interests: Birdwatching, travel

Introducing Scrum as development method

The Agile Manifesto:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right,

we value the items on the left more.

Dev needs Ops needs Dev = DevOps

You know the drill!

• Destroy all Silo’s! (or sulo’s in this case)

• Just make sure the business is safe when you do so

• And don’t do it on garbage collection day…

DEV OPS QA

DevOps teams

Scrum:

• focus on team effectiveness

• Retrospective inwards

• In effect: Creating miniature containers

However…

We don’t need small containers

• We need small containers that can operate in a value stream

• Cooperation over DevOps teams

Individuals and interactions over processes and tools

In reality not so simple!

Option 1: SAFe

• Scaled Agile Frame work

SAFe: pros and cons

Pro: • Helps to deliver large projects by Agile teams • Useful for portfolio management • Helps the business to stay in charge of spending Con: • Takes away responsibility and decision making at

the team level (un-agile) • ‘waterfall-scrum’ bco planning too many sprints • Does nothing for incident resolving over teams

Option 2: Super Product Owners

• One Product Owner to rule all (related) backlogs

Super Product Owners • Pro: clear who is responsible for priorities also

for incidents • Con: may be too much for 1 person • Con: reduces the role of other PO’s

Option 3: Scrum of Scrums

• Alternative of option 2, but without real decision making

• Still difficult to get your items on other teams backlogs with the right priority

• Doesn’t help for incident resolving

Scrum of Scrums: chain monitoring

An example how we used Scrum of Scrums for an improvement on chain monitoring • Value chain Savings • Complex incidents, lot of blaming • No time to implement new tools • Simply use what you have • Put the right people in the same room

• (by force if you have to)

Example chain monitoring (Savings)

Mobile

MINGP

Profile

• Incident: no log on to MINGP and MINGZ • Visible by page view dip (left) • Often backoffice (Profile) issue. But still

some trafic there (bottom left) • Mobile shows normal trafic (bottom right) • Conclusion: problem is in MING domain. • Closer investigation led to faulty change

which was retracted

Scrum of Scrums chain monitoring

• Revolutionary? Maybe not but …

• No blame game • Quick exclusion of search areas • Limited investment of time of all involved

teams • No new tools needed

• So maybe just a little bit revolutionary

Your solutions?

• These are just 3 solutions we use • There must be 1000s more • Please come and discuss them in an

Open Space!

To sum things up

DevOps in an Enterprise environment: • DevOps teams need to cooperate

Individuals and interactions over processes and tools

• SAFe • Super Product Owner • Scrum of Scrums • Other?

Build quality in

More stories on DevOps and Continuous Delivery ! (non of which included the previous slides…) Remember your discount code http://leanpub.com/buildqualityin/c/Ghent2014 Valid until November 10th