Delivery of Things World 2016 - Day 1

Today, Delivery of Things World 2016 - a conference about DevOps and continuous development - started in Berlin. It spans two days, and about 300 people participate. I attended the following sessions on the first day:

• DevOps and Moving the Elephant by Chris Gargiulo, Head of DevOps & Enterprise Service Platforms at Maersk Group (keynote):
• You have to start communication and work against fears.
• Continuous integration and continuous delivery are starting points for the journey towards trust in DevOps. He showed numbers of an example concerning decreased build times due to automation.
• First rule of DevOps: There's no crying in DevOps! I.e. you have to stand throwbacks and resist switching back to the old manual processes, learn from failures and watch out for potential improvements.
• Define a mission goal, adopt changes incrementally, quantify the results and celebrate success accordingly.
• Leading organisations that don‘t need leading by Mark Rees, former COO at E-POST Development (keynote):
• Their development units consist of several DevOps teams, each DevOps team in turn consists of a number of developers, a QA engineer and a delivery lead - kind of a mixture of a scrum master and a product manager.
• Responsibility and leadership always came up in discussions.
• Leaders should act as enablers and provide an environment for teams to become confident about taking responsibility for yet unexplored fields.
• Leaders should coach their teams in the beginning and then step back, delegate and provide support.
• Don't manage your teams, lead them!
• SecDevOps: How can we create cultural change to bridge this gap between security and DevOps? by Ben Hughes, Network Security Manager at Etsy:
• A typical DevOps pyramid: 10 developers, 1 ops person.
• Typical SecDevOps pyramid: 100 developers, 10 ops persons, 1 security person.
• Establish security champions: Join security conferences, hang around in relevant chats etc.
• Etsy does security bootcamps: Join a couple of other different teams for some time, then return to your home team (you are now well connected and got the security word spread).
• Security team culture:
• "Don't hire a**holes."
• Be approachable.
• Be transparent.
• Be humble.
• Act blamelessly.
• Create a culture where people report strange things happening rather than pretending everything is fine.
• "If you make security hard, people won't use it."
• Get everybody in your company/department to be "part of" your security team. Security is not something someone else cares about.
• Buy vs Build by Nishan Subedi, Senior Engineer at Etsy:
•  A nice tour through the tools they built:
• Virtual Madness (set up and manage development VMs).
• deployinator (deploy code changes).
• supergrep (tail production server logs).
• StatsD (metrics collector).
• morgue (for blameless postmortems).
• The main ideas behind these tools:
• Encapsulate ideas.
• Provide reasonable defaults.
• Make users feel comfortable due to transparency.
• Technology is a product of the culture that builds it. The Etsy culture consists of:
• Just Ship! (I.e. enable frequent deployments of small changes leading to continuous deployment.)
• If it moves graph it!
• Optimize for developer happiness.
• Don't be an a**hole.
• Engineering with a capital "E" - "E" as in empathy.
• A new hire always does a "First Day Deploy":
• Learn from what you see (and do).
• Make implicit explicit. No knowledge hidden in a small number of brains.
• Etsy strongly considers itself a learning organization.
• Generali‘s journey to reduce release and maintenance downtimes by 90% by Torsten Rehfisch, Scrum Product Owner at Generali:
• They decided to use XL Deploy for deploying web applications into a IBM WebSphere landscape including every dependent artifact and configuration which is needed to run a web service.
• After a description of their evaluation process these results were shown:
• Deployment landscape: 6 XL Deploy instances (3x for development/integration, 3x for UAT/pre-production/production).
• Each XL Deploy instance is set up via Puppet.
• Jenkins is used for build.
• They gained speed, confidence, transparency and repeatability.
• From Need to Speed - How to successfully setup a DevOps transformation by Robert Michel, IBM Cloud Solutions Technical Sales at IBM:
• Levels of DevOps adoption to increase delivery speed:
• Agile development/continuous integration.
• Continuous delivery.
• Continuous deployment.
• Continuous operations.
• Start fresh with a new project, start small, and think of "developer first" and "cloud first".
• Evolving to Continuous Development: a skill set example by Sebastian Ehrich, Software QA Engineer at ebay Kleinanzeigen and Manuel Aldana, Senior Development Manager at ebay Kleinanzeigen:
• Iterating often leads to a smaller change set per single deployment/iteration, which leads to less risk, better traceability and faster feedback.
• Key success factors:
• Culture.
• Mindset.
• Communication & collaboration (e.g. create communication/collaboration spaces in order not to broadly disturb people, implement open meetings where people can decide on their own whether the meeting is of interest for them).
• Visibility and spreading the knowledge (e.g. metrics on wall screens).
• Automation.
• They are mainly looking for people fulfilling the t-shape model.
• Product teams are self-containing, i.e. each product team consists of a mix of required people like developers, QA people, designers, operations people etc.
• Use kanban (due to its inherent continuous improvement).
• DevOps for leaders by Adam Lukas Urban, Head of Order Management Development at 1&1 and Tim Schuppener, Head of Development Webhosting Infrastructure & Content at 1&1:
• Invention and adoption cycles get shorter and shorter (examples: steam machine, computer, mobile phone).
• Faster shipment is required.
• Collaboration (communication, transparency) and common responsibility are essential.
• CAMS.
• First day deployment (like they do at Etsy).
• Pair operations (like pair programming).
• Hackathons, team events, socializing/communications areas.
• For leaders/management:
• Define values & targets.
• Give time & space.
• Performance will go down. Don't start measuring too early.
• Retrospectives are the key to continuous improvement.
• Software is eating the world by Henk Kolk, Chief Architect at ING (keynote):
• The bank is IT, and the IT is the bank.
• ING's journey from an organization heavily driven by processes (e.g. there were times when 64(!) documents had to be written before getting the clearance to start coding) to an agile one.
• Their reorganization lead to 180 full DevOps teams (i.e. operations people and developers in one team).
• Later they integrated the business people, too, to build product teams being completely responsible for a product. With that they got rid of 2 management levels.
• Results of their journey:
• IT drives the commercial strategy.
• IT is a value driver.
• Hiring the best talents.
• Building as the way to understanding.
• Line drives the changes.
• Products and services.
• People.
• The Rationale for Continuous Delivery by Dave Farley, Author of Continuous Delivery (keynote):
• The scientific method:
• Characterization.
• Hypothesis.
• Deduction.
• Experiment.
• Repeat!
• Iterative development processes are more successful than traditional ones like waterfall.
• Lean thinking:
• Deliver fast.
• Build quality in.
• Optimize the whole.
• Eliminate waste (unnecessary variations, overburden, wasteful activities).
• Amplify learning.
• Decide late.
• Empower the team.
• Continuous delivery leads to shorter cycle times and thus enables iterative processes.
• Continuous delivery motivation:
• First principle of the agile manifesto.
• Logical extension of CI.
• Holistic approach to development.
• Every commit creates a release candidate.
• "Finished" means released into production.
• Continuous delivery gains:
• Repeatable and reliable process.
• Automation.
• Everything under version control.
• If it hurts, do it more often.
• Build quality in.
• Done means released.
• Everybody is responsible for the release process.
• Continuous improvement.
• The Google build process shows that CD scales:
• A single monolithic repository.
• All tests run on every commit.
• More than 100 million tests are run per day.
• Amazon does one deployment every 11.6 seconds, each deployment hits 10,000 servers.
• The DevOps transformation at the HP LaserJet firmware team e.g. resulted in 8x the capacity for innovation.