DevOps seeks to tear down barriers between development and operations that lead to slower change and worse quality. Implementing a DevOps Team that adds yet another silo to an organization can be counterproductive. Rebranding infrastructure or operations teams as "DevOps" doesn't help, either. However, scaling DevOps benefits from a dedicated team. This session looks to answer key questions when building a team to enable DevOps transformations. What are common DevOps team structures? Are there existing groups that can lead the transformation? Who should I include on the team? What should its charter be? This deck is from a session delivered at IBM Interconnect 2015.

1. © 2014 IBM Corporation
Creating a DevOps Team
That Isn’t Evil
Curtis Yanko - Cigna
Eric Minick - IBM

2. Who are these guys?
• Eric is a DevOps Evangelist with
IBM where he helps customers get
the most out of their build, deploy
and release processes.
• Today he works with customers
and industry leaders to find the
best ways of adopting continuous
delivery and DevOps.
• @EricMinick
Eric
Minick
• Curtis has 17 years’ experience in
Application Development and
Delivery and is a leading
evangelist for DevOps in the
Enterprise.
• Curtis has a background in Config
Management, Continuous
Integration and is now driving a
DevOps vision and strategy in a
large Enterprise.
Curtis
Yanko

3. Evil?

4. And yet…
3
Slide from Stephen Elliot at #DOES14:
http://youtu.be/9_ZuEhgTdLc?t=12m16s

5. Is the industry
making a huge
mistake?

6. The Plan
• What Would Make a DevOps Team Evil?
• A Success Story: DevOps Team at Cigna
• Other Good Models
• Q&A
5

7. The Plan
• What Would Make a DevOps Team Evil?
• A Success Story: DevOps Team at Cigna
• Other Good Models
• Q&A
6

8. Silos
New silo = same old problems
7
Dev OpsDevOps
HT: Matthew Skelton
http://slidesha.re/1vOiHc4

9. 8
Rebranding – Declaring Success without any
Doesn’t
sound
helpful

10. 5 Signs your DevOps Team is Evil
Other groups interact with you via Tickets
Your team owns lots of things
The manager is growing his fiefdom
You share metrics “up” not “out”
Define success in IT terms, not business terms
9

11. The Plan
• What Would Make a DevOps Team Evil?
• A Success Story: DevOps Team at Cigna
• Other Good Models
• Q&A
10

12. Feedback From the System
11
Anti-Type C – “We Don’t Need Ops”
Dev OpsSCM
DevOps Patterns: Team Topologies – Mathew Skelton

13. The ‘Team’ was an Opportunity
12
To demonstrate something new

14. Two Ingredients for Change
13
Create an appetite for something new
Create a distaste for the status quo

15. Tracer Bullet
14
A Battle Plan For DevOps in the Enterprise – Willie Wheeler

16. Problem Domain - Zero Touch Deploys
15
Build Deploy Test Release
Code
Config
Data
Env
SystemDe-composition
In Scope
Value Stream
In Scope
Out of scope
Out of scope

17. Culture and Collaboration
16
No need to tear down silo’s just go knock
on the door and introduce yourself.
We offered transparency and inclusion

18. The Plan
• What Would Make a DevOps Team Evil?
• A Success Story: DevOps Team at Cigna
• Other Good Models
• Q&A
17

19. IBM – A global team of developers
18
Perth
Canada
Toronto, Ottawa
Montreal, Victoria
Haifa
Rehovot
China
Beijing
Shanghai
Xian
Yamato
Taiwan
Paris
Pornichet
Kirkland
Seattle
Foster City
San Francisco
SVL/San Jose
Almaden
Agoura Hills
Irvine
El Segundo
Costa Mesa
Las Vegas
Bedford, MA
Bedford, NH
Essex Junction, VT
Westborough
Cambridge
Littleton
Marlborough
Cork
Dublin
Galway
India
Bangalore
Pune
Hyderabad
Gurgaon
Vizag
Cairo
Rome
Gold Coast
Sydney Canberra
Fairfax
Raleigh
Charlotte
Lexington, KY
Atlanta
Boca Raton
Tampa
Krakow
Warsaw
Sao Paulo
Malaysia
DelftStockholm
Boeblingen
Southbury
New York City
Princeton
Hawthorne
Endicott
Moscow
Zurich
Pittsburg
Poughkeepsie
Somers
Yorktown Heights
Hopewell Junction
Wayne
Hursley
Warwick
York
Edinburgh
London /
Staines
Milton Keynes
Phoenix
Austin
Dallas
Dublin
Rochester, MN
Boulder
Denver
Lenexa, KA
Tucson
El Salto, MX
US 20,000
Canada 3,100
Latin America 600
EMEA 7,100
AP 11,800
Total 42,600

20. IBM’s DevOps Center of Competency
Responsible to drive the transformation
• Lead by example
• We work the way we ask teams to work, specifically
- Using IBM Design Thinking to determine how to best help our teams transform – user out come focused
- Report our transformation work in the context of our user – SWG teams
- Using Lean & Agile practices to deliver
SWG team can execute a simple experiment for a coded
hypothesis (based on a Design Hill) in < 7 days
SWG Team can find information on measuring a signal that will validate a hypothesis < 30
secs
SWG Team can continuously collect & visualize correlated signal data in < 7 days
Who
What
Wow

21. IBM CoC Approach
• Facilitate communication & collaboration
• Establish a Community (internal forums) to share what works and get support
• Roadshows / Presentations for techies and execs
• Internal educational sessions (webinars for several thousand participants)
• Online tutorials
• Build Support in the Org
• Recruit evangelists with grass roots and management respect
• Benchmarking and case studies across teams
• Recruit implementation managers on the individual teams
• Invest in Tooling
20

22. IBM CoC Approach cont.
• Invest in tooling
• Provide as a service
• Map business controls to DevOps techniques
• Does an experiment imply a commitment to a feature?
• Can we experiment with something in English only, for a product available in 10 languages?
• How should marketing work with a steady stream of features instead of big releases?
21

23. Success Story: Watson Analytics
Continuous Delivery to SoftLayer in 15 minutes
22

24. Environments
Manual Automated
Gain
Deploy Tests Deploy Tests
Test 4 hours 80 hours 20 min 3 hrs 96%
Staging
8 hours 4 hours 40 min 15 min 92.5%
Production
(25 environments)
200 hours 4 hours 3 hours 5 min 98.5%
Gain 98% 96% 98.5%
Success Story: Workload Automation
as a Service DevOps Solution
Rome, Italy
23
IBM SoftLayer
Monitor and Optimize
Rational Team
Concert
Rational Quality Manager
Rational Performance Tester
IBM Security AppScan
SmartCloud Control
Desk
IBM Application Performance
Management
IBM Endpoint Manager
IBM Security QRadar®
IBM UrbanCode Deploy
IBM Workload Automation
• Production deployment in few hours
• Change management process
• Automated tests
• No “black out” during update

25. Standard Model for a Center of X DevOps Team
24
Dev OpsDevOps

26. In Summary
DevOps as a Silo is bad
Teams done well Scale a good idea
Not a silo. A Facilitator
DevOps Teams should put themselves out of work
25

27. Questions

28. Acknowledgements and Disclaimers
© Copyright IBM Corporation 2015. All rights reserved.
– U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM
Corp.
IBM, the IBM logo, ibm.com, Interconnect, [IBM Brand, if trademarked], and [IBM Product, if trademarked] are trademarks or registered trademarks of
International Business Machines Corporation in the United States, other countries, or both. If these and other IBM trademarked terms are marked on
their first occurrence in this information with a trademark symbol (® or ™), these symbols indicate U.S. registered or common law trademarks owned
by IBM at the time this information was published. Such trademarks may also be registered or common law trademarks in other countries. A current
list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml
Other company, product, or service names may be trademarks or service marks of others.
• REMINDER: Please follow the guidelines for copying third party materials. Third party screen shots, logos, presentations and website content are
copyrighted materials owned by the third party, and as such we need permission from the third party to use them. Also, be sure the information you
put on a chart is verifiable. Be sure to cite the source on your deck when using words, ideas, facts, photos, news clips or other expression that did not
originate from yourself. This applies even if the content is publicly available and not confidential. If you have any questions, please contact your IP
Attorney.
Availability. References in this presentation to IBM products, programs, or services do not imply that they will be available in all countries in which
IBM operates.
The workshops, sessions and materials have been prepared by IBM or the session speakers and reflect their own views. They are provided for
informational purposes only, and are neither intended to, nor shall have the effect of being, legal or other guidance or advice to any participant. While
efforts were made to verify the completeness and accuracy of the information contained in this presentation, it is provided AS-IS without warranty of
any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, this presentation or any
other materials. Nothing contained in this presentation is intended to, nor shall have the effect of, creating any warranties or representations from IBM
or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software.
All customer examples described are presented as illustrations of how those customers have used IBM products and the results they may have
achieved. Actual environmental costs and performance characteristics may vary by customer. Nothing contained in these materials is intended to,
nor shall have the effect of, stating or implying that any activities undertaken by you will result in any specific sales, revenue growth or other results.

29. Thank You
Your Feedback is
Important!
Access the InterConnect 2015
Conference CONNECT Attendee Portal
to complete your session surveys from
your smartphone, laptop or conference
kiosk.

30. Divider slide