Agile2015 has ended

Sign up or log in to bookmark your favorites and sync them to your phone or calendar.

DevOps [clear filter]
Monday, August 3


Team practices applied to how we deploy, not just what (Abigail Bangser)
Limited Capacity seats available

In an agile environment of quick project starts and even quicker deadlines, teams are being asked to deliver value to customers faster. Our team succeeded in delivering all the requested business value in time, but still had a huge hurdle to jump at the end - actually releasing the product to our customers!
Businesses think that they do not need to know (or care) about the “technical” decisions of their teams, such as how a product will actually be released, or how the release procedure itself will be tested. This is not only wrong; it is dangerous for the company's bottom line. When technical release decisions are contained in a technical team silo, we are only using half our teams’ skills and risking delivery to our end users.
We all know managers do not just want problems raised; they want solutions proposed. Learn to clearly articulate delivery risks to the business and also mitigate the risks through proven practices applied in new ways.
Learning Outcomes:
  • Clearly articulate delivery risks to businesses when technical decisions are in a separate silo from business decisions
  • Leave with concrete ways to mitigate risks through proven practices applied in new ways

avatar for Abby Bangser

Abby Bangser

Platform Test Engineer, MOO Print
Abby Bangser is a software tester with a keen interest in working on products where fellow engineers are the users. Abby brings the techniques of analyzing and testing customer-facing products to tools like delivery pipelines and logging so as to generate clearer feedback and greater... Read More →

Monday August 3, 2015 10:45 - 12:00
National Harbor 12


The Magic Carpet Ride: A Business Perspective on DevOps (Em Campbell-Pretty)
Limited Capacity seats available

Having problems convincing your stakeholders to try DevOps? Confused about how DevOps can work at scale? Or even just wondering where to start with DevOps? Don’t worry you aren’t the only one!
Imagine being the business owner of an application that was the complete antithesis of Continuous Delivery i.e. no delivery ever! Ok that might be a slight exaggeration. Let’s just say the realisation of benefits from projects developed on this application were few and far between.
You are presented with Agile - a silver bullet - and you wait, and you wait and you wait, but the magic doesn’t happen. Eventually someone starts a conversation about “agile technical practices”, finally you know the spell to cast to make the magic carpet fly, or so you would think…..
If you want to hear the rest of the story you will just have attend this session. Set in the context of an Enterprise Data Warehouse, this session will tell the story of how a scaled agile adoption created the case for change and subsequent implementation of DevOps practices. This tale from the trenches will provide insights into both the mistakes made along the way and the ideas that made all the difference, in completely transforming the delivery capability of the organisation.
Learning Outcomes:
  • Techniques for getting business buy-in to DevOps initiatives.
  • Approaches for funding DevOps initiatives.
  • Pitfalls to avoid when implementing DevOps.
  • Success factors likely to enable success with DevOps.

avatar for Em Campbell-Pretty

Em Campbell-Pretty

Managing Director, Pretty Agile

Monday August 3, 2015 10:45 - 12:00
National Harbor 6/7


Facilitating Operational Retrospectives: 'postmortems' minus the blame (J. Paul Reed)
Limited Capacity seats available

As organizations experience with greater concurrency and integration between their departments and move toward a continuous delivery of customer-value, failure is assured. Asking "how can failure be avoided?" isn't as useful or relevant as focusing on
  • "How does our organization react when failure occurs?" and
  • "How do we create a sustainable, actionable process for describing, exploring, and remedying failure?"
Of course, retrospectives are not new to the Agile community. But are the "end of sprint" retrospectives we know and love enough?
As organizations integrate the work being done under the "DevOps umbrella" into their Agile practices, the need for a new type of retrospective becomes obvious: the operational retrospective. (Many operations teams know this as the "post-outage postmortem.")
An operational retrospective has a number of important differences from end-of-sprint retrospectives:
  • Events can prompt them at any time, even multiple times per day in large enterprises.
  • These events can generate a lot of data for review.
  • Because they are prompted by performance problems and outages, they are often high pressure situations.
  • Unlike our team retrospectives, many different actors become involved, as cross-functional engineers swarm on problems and leadership demands to know "Why?"
Altogether, this can create a breeding ground for finger-pointing, bias, and a host of other behaviors which destroys our ability to learn anything useful from the event.
But it doesn't have to be this way.
We'll examine the current thinking on organizational and technological failure and look at tools and techniques used by other industries (transportation, construction, manufacturing) to conduct their postmortems. We'll also look at the cognitive biases that often find their way into a postmortem process and why it's important to be aware of them when conducting our own operational retrospectives.
We'll finish by looking at techniques to conduct postmortems within your own organizations, both from a process/skill perspective and from a tooling perspective, to help ensure that the results of your postmortems are incorporated back into the organization's shared knowledge for the next time there's an issue with production, not just stored on some wiki somewhere that no one remembers to look at again.

Learning Outcomes:
  • Describe existing models for postmortem/retrospective analysis
  • Describe the "New View" model of postmortems/operational retrospectives
  • Recognize bias (situational and social) and how they impact the retrospective process
  • Employ different linguistic structures for postmortem analysis
  • Compare/contrast other industries' postmortem structure and processes and be able to select techniques relevant to their Operations-focused postmortems
  • Familiarity with tools that facilitate the operational retrospective process and how they improve the organization's ability to act on the findings, learn, and improve

avatar for J. Paul Reed

J. Paul Reed

Managing Partner, Release Engineering Approaches
J. Paul Reed has over fifteen years experience in the trenches as a build/release engineer, working with such storied companies as VMware, Mozilla, Postbox, Symantec, and Salesforce. In 2012, he founded Release Engineering Approaches, a consultancy incorporating a host of tools... Read More →

Monday August 3, 2015 14:00 - 15:15
National Harbor 13


Launching MSN on Azure a Story of the 76 point checklist (Eric Passmore)
Limited Capacity seats available

Get specific and learn twelve categories and 76 points to make any cloud service successful. Cloud services on commodity hardware are less resilient and fail more often requiring more work to build a rugged and responsive system. This checklist is the recipe that will turn any dev team into devops superstars.
As a bonus hear first hand stories of moving Microsoft's MSN service of 450 million users to Azure. Stories that will make you laugh and cry!
Learning Outcomes:
  • Learn the specific check list to make any cloud service successful.


Eric Passmore

CTO MSN, Microsoft
Eric is passionate about coaching and mentoring people to be better technical leaders. He has experience leading software teams in a diverse set of cultures across Microsoft, AOL, CNET, and a few startups. During that time Eric has build global online applications supporting hundreds... Read More →

Monday August 3, 2015 15:45 - 17:00
National Harbor 12
Tuesday, August 4


Reflections on an 18-Month Federal DevOps Transformation (Dan Craig)
Limited Capacity seats available

Eighteen months ago my company was asked to serve as the primary change agent during the transformation of a large, civilian agency towards agile/CD/DevOps practices. During the sales cycle our early impressions of the the client were fantastic: they had experience with agile delivery; a CIO with a history of IT innovation; leadership that already worked well with each other and a large, highly-visible NextGen effort making everyone eager to embrace any practices that could make them more efficient. What could go wrong? We learned that even under the most favorable circumstances, enterprise-wide change is not easy. It takes significant commitment from leadership and a willingness to continually revisit the people, processes and tools involved with delivering software.
This talk provides brief background on the state of the organization when we first engaged, and highlights the major successes (and growing pains!) we encountered while building an agile/CD platform, on-boarding over 100 projects and moving the agency up the DevOps maturity curve:
The Backdrop…
• Pressure to Deliver Suite of NextGen Applications
• Highly Visible Legacy Blow-Ups (CM, Deployment)
• Infrastructure & Networking issues
• Various methodologies/technologies
• No central source for CM, Development, Test or Deployment of Systems
• No shared priorities=organizational conflict
Building the Platform…
• Introducing Open-Source & Retiring Expensive Licensed Products
• Integrating Agency Tools (Selenium, LoadRunner, WebInspect…)
• Networking Considerations (DNS Names, Publicly Accessible)
• Standardizing Environments
• Moving towards the Cloud
Creating the “Platform Playbook”…
• Platform Onboarding & Project Maturation Process
• Inter-Organization Touch-points
• Piloting Migrations to the Platform
• Refactoring Process at we Learn
Shoring Up Agile Practices…
• Agile Assessments/Metrics
• Tailored Best Practices, Standards
• Training
• Codified Enforcement of Standards
• Automated Builds
Aligning the Organization…
• Ensuring Shared Priorities
o Quarterly CIO Summit (Roadmap)
o Monthly Stakeholder (Objectives)
o Weekly Planning (Stories)
• Communication (newsletter, website, brown-bags, Kanban wall)
Victims of our own Success…
• One-Size-Fits-All Pilot no longer works at more teams onboard
o Expanded Training for users at lower levels of process expertise
o Increased support for diverse technologies via plug-ins and customizations
o Large Diversity in Technologies & Target Environments
o Revised Bundling Technique
• Rising fixed costs for Administration
o Moved to LDAP Groups to offload user access
o Created Administrative Reports
o Automated Platform Deployments
• Difficulty Policing Platform Customers
o Implemented Templates (Jenkins)
o Automated Compliance & Administrative Reports
• Heavy Load at Peak Periods
o Jenkins Slaves
o Labeling
Finally, automating Deployments…
• Release bundles
o Environment Agnostic
o Release Documentation
o Traceability
• Automated deployments
o Jenkins/Scripts
o Puppet
o Ansible
Knowledge Transfer and Signs of Growing DevOps
• Puppet & Ansible can live together
• Co-Location
• Shared Dashboards
Learning Outcomes:
  • Attendees will leave with an understanding that:
  • • An enterprise level shift towards DevOps is difficult even in the most favorable situation
  • • People, Process and Tools are all important during transformation
  • • Process and tools become more important in organizations (i.e., Government) where contracted staff is always in transition.
  • • There will be growing pains as you move from pilot to enterprise-wide adoption. What works today will not work tomorrow. Plan for it.
  • • A solid foundation in Agile best practices is critical to the success of a lasting CD/DevOps practice

avatar for Dan Craig

Dan Craig

Director, Agile Delivery, Steel Thread Software

Tuesday August 4, 2015 09:00 - 10:15
Potomac 5/6


Incident Response Patterns: What we have learned at PagerDuty (Arup Chakrabarti)
Limited Capacity seats available

At PagerDuty, we see how engineers across the industry are resolving incidents. Some teams take days to resolve problems, some take minutes, and most are somewhere in between.
In this talk, we will cover some learnings that we have had internally at PagerDuty from our own incidents, steps we have taken to get better at them, and how we run post-mortems. From there, we will also cover some trends across the industry: how long outages take, how many people have to get involved, how many teams actually fix their root causes, and how much sleep the average on-call engineer gets.

Learning Outcomes:
  • Best practices on incident response

avatar for Arup Chakrabarti

Arup Chakrabarti

Director of Engineering, PagerDuty
Arup has been working in the space of software operations since 2007. He started out at as an Operations Engineer at Amazon, helping to reduce customer defects with multiple teams for the Amazon Marketplace. Since then, he has managed and built operations teams at Amazon and Netflix... Read More →

Tuesday August 4, 2015 14:00 - 15:15
Potomac 5/6


The Secret of Our DevOps Success: Fostering Human Behavioral Change (Mark Nemecek)
Limited Capacity seats available

DevOps is all about continuous change and improvement. The only constant in a healthy DevOps culture is change. Conway’s Law teaches us that our systems will only change as our human communication methods change. That’s behavior. Ergo, if you cannot facilitate and provide for human behavior change, your DevOps culture will suffer as a result.
Problem: humans don’t like change. This is not a cynical statement. Humans evolved to be creatures of habit. Habit is safe. Routine is safe. The known is safe and the unknown is not. This one thing – the instinctive human desire to resist and rebel against change – is the single biggest blocker to a DevOps cultural transformation.
Our observations are that organizational rank is less relevant in this space. We can command that employees work, but we cannot arbitrarily command behavioral change. Introducing behavioral change via command without also aligning cultural perception tends to result in many points of subconscious rebellion that can ultimately defeat the original initiative without ever manifesting tangibly.
We have seen success here by selling ideas instead of instilling them forcibly. We have our partners, our teams and our change agents all arrive at a common truth via an interview and discovery approach instead of a command approach. In doing so, we align the culture on the idea and can then rely on cultural safeguards to see it through.
This is a powerful concept, but the path is fraught with pitfalls for the change agent, both external and internal. We’ve seen success and failure in this space, and the success/failure patterns may not be immediately obvious to newcomers. The ability to remove value judgments from change initiatives and willingness to prioritize the change atmosphere over one’s own ideas for change are among the critical characteristics we have seen in successful change agents. We will analyze these characteristics and others and discuss how to best stay on track for long-term transformational success even when short-term initiatives see rejection.
Attendees will come away feeling better empowered to attack the change needs in their respective organization.
Learning Outcomes:
  • Acknowledge that an organization’s ability to transform is directly dependent on the ability of its human resources to change behavior.
  • Acknowledge that telling people to work is very different from telling them to change; understand that change agency is difficult by nature, not because of any particular environment.
  • Learn that transformation that is worthwhile and successful is always born from a strong answer to the WHY argument, not the HOW argument. The HOW is transitive, but the WHY is your true north.
  • Learn to not attach personal value judgments to proposed changes; stop assigning “right” or “wrong” to initiatives when acting as a change agent, and thereby remove emotional attachment from the initiative; instead, one must make a judgment call on which change will provide the best cultural return on investment while keeping one’s eye on the long game.
  • Learn how to shift one’s approach to more successfully drive positive change in the face of resistance and adversity.


Mark Nemecek

Sr. Director, IT Infrastructure, CDK Global
20 year veteran of software development, including 12 years at Microsoft. Most recent 2 years spent in a DevOps-centric role in the hosting management org of CDK Global's IT division.

Tuesday August 4, 2015 14:00 - 15:15
National Harbor 12


The 10 Myths of DevOps (Seth Vargo)
Limited Capacity seats available

Although not officially coined until 2009, DevOps ideals have been explicitly discussed since at least 2006. Recently, however, the term "DevOps" has gained increasing popularity across a variety of fields and industries. DevOps is not a development methodology or technology; DevOps is an ideology. It is a way to facilitate organizational prosperity and growth while increasing each individual employee's happiness along the way. As DevOps has gained in prominence, a gap has been created between the original definition of DevOps and this new "enterprise-ready" buzzword.
For organizations beginning DevOps practices, this talk will provide a 10,000ft view of DevOps and how you can properly implement DevOps practices in your organization. For organizations that are currently practicing DevOps, this talk will cover common pitfalls, ways to sustain a happy culture, and new tips to foster organizational prosperity.
Learning Outcomes:
  • After this session, attendees will have a firmer understanding of DevOps is, and more important what DevOps isn't. They will be empowered to facilitate change in their organization, while avoiding common pitfalls new organizations trying to "implement DevOps" experience.

Tuesday August 4, 2015 15:45 - 17:00
National Harbor 4/5
Wednesday, August 5


How DevOps Will Fix Government IT: Agility in a Low Trust Environment (Mark Schwartz)
Limited Capacity seats available

We all know that agility requires trust, but the government is an extreme example of a low trust environment. We all know that agile approaches focus on maximizing business value delivered, but the definition of business value for a government is not at all clear. We all know that Lean approaches work to remove waste, but the government is designed around heavyweight processes that we know as red tape. Lean, agile IT seems like an impossible fit with a government environment.
Or - perhaps - the government is a perfect laboratory for pushing the boundaries of the agile approach and working on its most difficult issues.
I contend that every organization has a unique set of needs. The government's special needs result from its constant exposure to the cynical public eye, its complex oversight structure based on a system of checks and balances, and its foundations in a rule-based system to ensure accountability to the public. An IT project must meet these "business needs" in addition to any product-specific business needs - and the best way to meet business needs is to empower self-organizing teams to find the best way to do so. In other words, agile teams can self-organize to meet the deep needs of the bureaucracy, in addition to meeting any product-specific business needs.
At US Citizenship and Immigration Services, we have found that a DevOps framework, properly applied, can be a perfect way to meet the government's deeper needs. For example, scripted deployments can make it easier to change development contractors, which makes the government procurement system more open and more fair. By turning compliance requirements into automated tests, a DevOps team can make it clear to oversight bodies that it is fully compliant; by making metrics transparent across the entire delivery process, from development through production, DevOps can support the government's oversight processes. A DevOps-based security model can be made consistent with the government's new focus on Continuous Diagnostics and Mitigation. DevOps can help us make government IT lean - while at the same time supporting the government's needs for oversight, transparency, and accountability to the public.
At USCIS we have taken an agile approach to our agile adoption - self organizing to meet the needs of the bureaucracy in a way that is lean and delivers value.

Learning Outcomes:
  • Applying agile approaches in a low-trust environment; using DevOps to meet needs of compliance and oversight; maximizing learning about deep organizational needs, not just product needs.

avatar for Mark Schwartz

Mark Schwartz

Author, War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age
Learn from Mark Schwartz, author of "The (Delicate) Art of Bureaucracy."

Wednesday August 5, 2015 10:45 - 12:00
National Harbor 12


The ABCDs of Database Development: Always Be Continuously Delivering (Elizabeth Ayer)
Limited Capacity seats available

Imagine the freedom you would have to develop great software if making changes to the database were both faster and safer. Hard to picture? Perhaps not - database changes are not so different from code, except for one essential difference: the data.
This session will explore the tension between the speed imperative of Agile and the safety requirements of database administration. Despite years of practices built around assumptions to the contrary, we will see how both needs are better satisfied when the two sides join forces. Faster and more reliable deployments can be achieved through a combination process change, education, and technology.
Together we'll walk a happy path through the technologies needed to automate a database delivery process. With actual customer case studies, we will look at steps to transformation, drawing out the common methods from their unique situations. You will come out with an understanding how to customize practices and toolsets, building a database delivery pipeline best suited to your environment. The result will accelerate your own database delivery, while protecting your organization's most valuable asset: its data.
Learning Outcomes:
  • Understand process and technology requirements to automate your release pipeline step-by-step.
  • Learn about the organizational changes necessary to support process modifications.
  • Appreciate why these changes are necessary to match modern development and deployment methodologies.

avatar for Elizabeth Ayer

Elizabeth Ayer

Product Manager, Redgate
In a past life, Elizabeth Ayer was a software developer at a large enterprise software organisation. In a sustained backlash against this, she has since focused her energy on creating the right environment for collaboration and innovation at all levels. Elizabeth is now a product... Read More →

Wednesday August 5, 2015 14:00 - 15:15
National Harbor 12
Thursday, August 6


A Gentle Introduction to DevOps - Project Manager Edition (Amye Scavarda)
Limited Capacity seats available

As part of being a project manager in the digital world, you're frequently likely to encounter projects that involve some amount of DevOps work, and people that work with these on a deeper basis. Sometimes, this area will impact your project's schedule: whatever you build has to live somewhere! And how does everyone commit code? What happens to the code after one person build it? But, as a project manager, you don't always know how to be able to understand the responses that happen when you ask questions about 'so, how's that server thing'.
An experienced project manager who swims in both Drupal and DevOps will walk through understanding DevOps from a project manager's perspective - how to translate the answers that you get when these things come up:
  • Delays in contribution and collaboration
  • Delays in effective client reviews
  • Sites going down because you didn’t think about hosting
  • Unhappy teams: can’t get anything done
  • Unhappy clients: can’t see what developers are getting done
We'll go over:
A short history of needing servers: what’s a CMS anyways
Why do I need to know this anyways
A simple way of thinking about version control
Improvements on this: Continuous Integration, Continuous Delivery and Continuous Deployment
Continuous Everything Maturity Matrix
New tricky things: Docker and containers vs VMs
Where can I expect to need this knowledge? A project manager that's practicing will be able to deepen their knowledge around how DevOps impacts their day to day day life. Additionally, we'll go into 'all of the things there are to learn' about DevOps.
Learning Outcomes:
  • A project manager that's practicing will be able to deepen their knowledge around how DevOps impacts their day to day day life. Additionally, we'll go into 'all of the things there are to learn' about DevOps.


Amye Scavarda

Project Manager, Amye.org
Implementer of sanity in fast-paced chaos. Pleasant, cheerful and competent in a sea of snark. I'm at Phase2 as a Drupal and DevOps project manager, expanding out the world one little website + infrastructure build at a time. I help technologists think about what they're doing, and... Read More →

Thursday August 6, 2015 09:00 - 10:15
National Harbor 13


Bill's and Aimee's Excellent DevOps Journey: From Roadmap to Rubber On the Road (Aimee Bechtle, Bill Donaldson)
Limited Capacity seats available

In their presentation, "Bill and Aimee's Excellent DevOps Journey", Bill Donaldson (Dev) and Aimee Bechtle (Ops) will share a summary of their tumultuous journey that has resulted in 75% of their corporate applications utilizing Continuous Integration with automated deployments, a 70% reduction in labor, and 288% reduction of cycle time. They will support these numbers with charts depicting the deployment volumes over the course of a 1.5 year adoption. They will share how by selecting the right applications, approach, and people from Dev and Ops, and using creative ways to advertise success, the new capabilities were embraced and adopted in their organization. The presentation will conclude with how Aimee has transformed her team to support Continuous Integration with auto deploy. Additionally, she will share why the 25% remain in the manual system and how she’s pursuing Continuous Delivery.
Learning Outcomes:
  • The audience will learn how an idea became a reality and what attitudes and feelings were experienced in the journey from manual builds and deploys to automation. They will learn how Dev and Ops can become a team working together towards a common goal. They will understand how obstacles were overcome and support was obtained for the effort. The audience will be provided with practical solutions for getting adoption of continuous integration and delivery solutions and scaling it to the enterprise.

avatar for Aimee Bechtle

Aimee Bechtle

Principal SW Systems engr, The MITRE Corp
At the MITRE Corporation Aimee Bechtle is a Principal Software Systems Engineer with over 20 years experience in full lifecycle software development. In 2009 Aimee saw the light and defected from software development to join operations. Within MITREs Information & Technology division... Read More →
avatar for Bill Donaldson

Bill Donaldson

Change Agent, MITRE
Bill Donaldson is Project Leader and Agile Coach at The MITRE Corporation. He has been developing systems and products using Agile and iterative methodologies for over twenty years. Starting in 2008, he led the transformation of MITRE’s application development from Waterfall to... Read More →

Thursday August 6, 2015 10:45 - 12:00
National Harbor 3


The Santa Monica Experiment (Dominica DeGrandis)
Limited Capacity seats available

This is a true story about the trials and tribulations of an Operations team during a period of extreme growth. A team sinking in endless requests and expedited issues and what happened as they began to measure their capability while pushing back on the barrage of customer demands. We’ll examine the three metrics that mattered, the failures along the way, and the forum used to influence the desired outcome.
The Problem
A team of forty Ops Engineers was tasked to build out six new data-centers in six different countries within six months. And roll out a new configuration management tool. And deploy features from development teams. And implement stronger security. And support live issues. And implement a new monitoring system. And support various requests from 41 other teams.
Conflicting priorities and over-commitments, exacerbated by a lack of communication led to serious interrupt-driven context switching and missed commitments. Commitments made on behalf of the team by leadership were often not communicated to the team. It wasn’t clear how decisions were made. A dismal hand dealt to the team for sure. How to insert a voice of reason in this madness?
The Approach
Quantifiable Ammunition - stay calm and collect data!
Decisions needed to be made. How to build and present a case to influence those decisions? Providing relevant metrics in an objective data-driven fashion brought essential visibility and transparency to the problems. Let's look at the diplomatic approach used to communicate the costs and risks of the decisions made.
Learning Outcomes:
  • • Why a gradual and humble approach to change worked
  • • How we identified which metrics mattered
  • • How the Operations review format worked to influence decision makers
  • • Resulting successes and failures and what I would try differently next time

avatar for Dominica DeGrandis

Dominica DeGrandis

Principal Flow Advisor, Tasktop
Dominica DeGrandis is the author of Making Work Visible: Exposing Time Theft to Optimize Work & Flow. She is a huge fan of Flow and uses visual cues to inspire change. As Principal Flow Advisor at Tasktop, Dominica introduces organizations to flow metrics & Value Stream thinking... Read More →

Thursday August 6, 2015 14:00 - 15:15
National Harbor 6/7


Docker Enables DevOps (Boyd Hemphill)
Limited Capacity seats available

The information architecture of the outline below is how the slide deck will be laid out. Each section will follow the same format giving the attendee a pattern to hold on to while many new concepts and perspectives come at them.
Introduction (10 minutes) - common ground
  • Who am I
    • Founded and run Austin DevOps (since 2012)
    • Run Docker Austin (2014)
    • DevOps Days Austin Organizer
    • Container Days Founder and Organizer
  • What is DevOps
    • DevOps is the way a technology organization embeds itself in a business to the benefit of that business
  • What is Docker
    • A quick history of containers
    • Containers v. Virtual Machines
    • Docker is linux containers for mere mortals
Docker accelerates developers (10 min)
What this looks like:
  • Traditional - Disposable Development environments
  • Forward Thinking - Better modeling of the production topology
  • Bleeding Edge - Produce container images as black boxes
The Agile Test:
  • (y) Individuals and interactions over processes and tools
    • Developers can take risks such as upgrading PHP knowing they can get back to a working state in seconds instead of days. Enabling innovation means better velocity.
  • (y) Working software over comprehensive documentation
    • We don't care about the contents of the container, just that it passes tests (unit, functional, security, performance etc). The tests are the documentation.
  • (y) Customer collaboration over contract negotiation
    • A developer can change the function of a service in a container and show it to a customer (B2B) asking, "like this?"
    • Developers can kick out new features that can be A/B tested on a SaaS offering (B2C)
  • (y) Responding to change over following a plan
    • New features in languages (the PHP example above), run time environments, web servers and the like are constantly happening but cannot be tried or deployed until containers.
Docker Accelerates Build and Test (10 min)
What does this look like:
  • Traditional - Better parallelism in software build and test grids
  • Forwared Thinking - Better modeling of the production environment in testing
  • Bleeding Edge - Build systems produce container images as artifacts to be run in production
The Agile Test:
  • (y) Individuals and interactions over processes and tools
    • At the bleeding edge, collaboration across function becomes about producing tests rather than processes for inhibiting innovation. Code becomes the documentation and collaboration happens at the engineering level rather than the process control level.
  • (y) Working software over comprehensive documentation
    • Better modeling of the production environment, especially in a disposable way, means testing happens faster and more accurately.
  • (m) Customer collaboration over contract negotiation
    • A/B testing is a form of collaboration, though generally an individual customer is unaware they are a test subject.
  • (n) Responding to change over following a plan
    • Responding to change is the definition of both build and quality engineering. Docker adoption has no effect.
Docker Accelerates Project Management (10 min)
What does this look like:
  • Traditional - None
  • Forward Thinking - Coordination between Dev and QA is ease
  • Bleeding Edge - Problems of The Mythical Man Month are eased by micro teams
The Agile Test:
  • (y) Individuals and interactions over processes and tools
    • Micro teams build around micro services need only communicate to to other teams when they make a breaking change. This, for example, can take a development team of 20 individuals and turn them into a collection of 5 micro teams. PM's need only manage the communication between teams when breaking changes occur, and only between 5 teams.
  • (n) Working software over comprehensive documentation
    • PM's don't write or operate software. Docker has no impact here.
  • (m) Customer collaboration over contract negotiation
    • Use of disposable environments could lead to PMs doing check-ins with customers that ask, "You mean like this?"
  • (y) Responding to change over following a plan
    • On the bleeding edge change becomes about how to ensure behavior of software rather than people. Software problems are easier than people problems.
    • Change is most painful at the hand off between Dev and QA. Since that handoff is now a simply container image, the technology friction is reduced to nearly zero. This means the PM is free to focus on higher value issues.
Docker Sprains an Ankle in Operations (15 min)
What does this look like:
  • Traditional - Gnashing of teeth, stress and obstinance
  • Forward Thinking - Working with DevOps thought leaders to identify an appropriate sandbox to do real world R&D.
  • Bleeding Edge - Micro services teams (Netflix), Single tenant systems (Pantheon), Bleeding edge shops (Offers.com)
The Agile Test:
  • (n) Individuals and interactions over processes and tools
    • At the operational level, Docker is a technology.
  • (y) Working software over comprehensive documentation
    • Containers are portable, so "works on my machine" is not a consideration in a Docker shop. When it gets to Ops, it works. Testing will need to focus on security and performance.
  • (y) Customer collaboration over contract negotiation
    • In the Pantheon example, this is a crucial point. Customers use the fully featured system indefinitely for free. They purchase value added services like performance, back up and the like.
  • (n) Responding to change over following a plan
    • Ops, by definition, is about eliminating the need for reaction in the production environment.
Summary (5 Min)
  • Should you consider a Docker Adoption at Your Company?
    • Can you derive benefit where it matters most? (making money)
    • Can you sandbox the adoption to create safe or low risk learning opportunites?
    • Can you work with your operations team to identify these sandboxes?
    • Can you, by success, generate a demand across all teams in a project for the use of Docker?
Questions (15 min)
  • A list of the books and web content referenced in the talk will be on screen during Q&A
While I am extraordinarily keen to attend the conference and hone my own understanding of the Agile practice, I am at your service. Docker is a hot topic, so if there is need to start a "hallway track" after to the time slot to continue Q&A or start a B.O.F. in the evening, then I will work with you to service that demand. I would love to do a B.O.F. in the Lean Coffee format in the evening after the talk!
Learning Outcomes:
  • The attendee will walk away from this talk with enough high level information to determine is they should invest real time and effort investigating a Docker adoption.

avatar for Boyd Hemphill

Boyd Hemphill

Director of Cloud Infrastructure, Contrast Security
Boyd Hemphill is the CTO at VictoryCTO where he helps customers win in their respective markets by realizing the potential of their technology. Boyd is a DevOps raconteur and thought leader in the silicon hills of Austin Texas. Boyd founded Austin DevOps and plays a role in the... Read More →

Thursday August 6, 2015 15:45 - 17:00
National Harbor 13
Friday, August 7


A Culture of Continuous Change (Barry Hawkins)
Limited Capacity seats available

Even in high-performing organizations like Netflix, rolling out changes across the whole company can be painful. Because change impacts teams and the commitments they have made, it inevitably meets with resistance, apathy and surprise. Learning to facilitate change within your organization can make you a hero. Creating a culture of continuous change, however, can scale beyond your finite capacity and deliver lasting impact.
In this talk, Netflix Change Engineering Manager Barry Hawkins will frame the challenges organizations face who want to orchestrate change in a culturally-compatible way. He will share insights from his experience at Netflix, Riot Games, and other organizations. He will also share tips for making changes effectively within your organization, and how to establish the foundations for a culture of continuous change.
Learning Outcomes:
  • understand foundational elements of change across loosely-coupled teams at scale
  • receive concrete examples of how to tailor a change strategy to your ecosystem
  • be aware of common pitfalls when orchestrating change at scale

avatar for Barry Hawkins

Barry Hawkins

Change Engineering Manager, Netflix
Barry Hawkins serves as the Engineering Manager for the Change Engineering Team at Netflix. He was previously Lead Producer for World of Warcraft at Blizzard Entertainment, and before that, Director of Product Management at Riot Games, creators of League of Legends. Barry has over... Read More →

Friday August 7, 2015 09:00 - 10:15
National Harbor 6/7