Agile2019 has ended

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

DevOps [clear filter]
Monday, August 5

10:45 EDT

DevOps > Automation, DevOps = Culture + Ownership + Empowerment (& Good Patterns) (Reneshan Moodley)

The three spheres of a DevOps adoption being Culture, Processes and Tools are fundamental to any organisation. The focus on tools often supersedes any work being done at the process levels and almost always, the culture aspect is 'ignored'. Through my years of helping teams adopt agile and eventually pursue DevOps, I've identified certain patterns that address the varying levels of change that are needed by a team pursuing Agile Ways of Work.
In this talk, I'll highlight the most important patterns that are needed along with suggestions to help embed these patterns. I will be using the DevOps radar (from SAFe) as a guidepost for patterns to get an organisation moving towards the promised land.
Whilst there isn't an 'endpoint' for a DevOps adoption, these patterns reflect milestones on a DevOps transformation roadmap and serve as a possible ‘quick start’.
NOTE: This is not. A SAFe pitch or SAFe sales workshop. The DevOps radar can be used, regardless of the presence of SAFe.

Learning Outcomes:
  • 1. Identify the three spheres of DevOps and assess where the most difficult work is to be found.
  • 2. Understand the patterns that can help and their suggested application.
  • 3. Understand the core skills/capabilities of a DevOps team.



Monday August 5, 2019 10:45 - 12:00 EDT
Chesapeake 10/11/12

15:45 EDT

But Why is it Shipped So Late? (Dr. Sam Swapn)
Limited Capacity seats available

Why should I see & hear this talk:
In a lot of seemingly agile environments software still does not get shipped very often. Teams work hard and create an increment usually within two weeks, still it gets stuck and does not get shipped and deployed to production. This is a big problem in software development. Why does that happen? How do we fix this problem? Implementing DevOps can help you ship more often by closer communication and collaboration between Development Teams and Support Teams. Close coordination and experimentation between these teams helps in faster recovery and faster delivery. That is why it seems, Forrester Research states that the 2018 was the "Year of Enterprise DevOps" and now more than 50% companies globally are applying DevOps.
What to expect from this talk
DevOps can work even at Enterprise Level if practiced correctly. I will talk about this, in a highly interactive and engaging environment, on how we dealt with this situation in a Case study from Leading Insurance FORTUNE 30 company when we were stuck and not to release, by applying Devops concepts of automation, lean, communication, and exploration- CI (continuous Integration)& CD (Continuous Delivery) we were able to solve the problem. When introducing DevOps here is how you can face challenges. With one challenge being that DevOps is not only about tools such as Maven, Docker, Containers, Micro services but a lot about ‘ silo mindset’. It is about bringing culture change that can help. Applying DevOps technique will help release faster,have fewer defects and frequent releases. In this highly engaging and interactive Case Study we learn concepts of DevOps, followed by an Exercise in which we play a Game:The DevOps Game- The Phoenix Project from Sogeti- to demonstrate the success that DevOps can bring to collaborative teams, and finally a Debrief session to answer questions in a Q&A time box that audience might have- we will highlight the benefits of applying DevOps.

Learning Outcomes:
  • Participants will learn in a highly interactive and engaging environment and practice to work on 'key success factors' for faster delivery to production by applying DevOps.
  • By applying DevOps principles it will prepare Agilists to solve forward fixes problems and reduce failure rate for releases.
  • This session will also prepare participants to learn to resolve the culture related issues by applying DevOps and help create a shift in mindset required to be truly Agile teams.
  • With DevOps we collaborate and experiment between Development & Infrastructure teams and not just stop on creating the code but making sure it is delivered to production and released and business starts getting the benefits on their investments.


avatar for Dr. Sam Swapn

Dr. Sam Swapn

Agile Coach, Agile Strategic Solution
I am an Agile Coach, a mentor, a friend, a philosopher, and a guide to many leading professionals in America and globally for last more than a decade. I have trained thousands, from C level executives to Team level, in Agility. I have more than three decades of corporate experience... Read More →

Monday August 5, 2019 15:45 - 17:00 EDT
National Harbor 6/7
Tuesday, August 6

09:00 EDT

Continuous Build and other DevOps anti-patterns, and how to overcome them (Thomas Stiehm)
Limited Capacity filling up

Software development is hard and poorly implemented or broken tools, techniques, and patterns just make it worse. Learn to spot DevOps anti-patterns and how to work your way back to a sane way of working.
Continuous Build is an anti-pattern that I have often seen where a team will have what they call Continuous Integration (CI) in place but it only builds the code, there are no unit tests or static analysis run. Certainly, this is better than not building but it leaves a lot of health check information on the table that is considered part of CI. Without this information, you can never really gain the confidence that your build is healthy. The whole goal of CI is to feel that your build is healthy so not tests and analysis means you aren’t doing CI.
Just like CI, other DevOps practices can be hard to understand, implement, and get right. Even with the best of intentions, we make mistakes or misinterpret the implementation of a technique. Learn how to spot common DevOps anti-patterns and how to correct them. These patterns include
1. Continuous Build - CI without tests isn’t CI
2. Turning unit tests off to build the release
3. Don’t automate that, it is my job
4. Different build process for developers and high environments
5. Different deployment process for developers, test environments and/or production
6. Not having a production-like environment to test in before production
7. Saving performance testing for the end of the release
8. Saving security testing for the end of the release
9. Never asking the users about the software
10. Only automating build and deployment, not testing
11. Not having retrospectives
12. Restricting retrospectives to only the development part of the process
13. Running analysis and never looking at or acting on the findings
14. Reduce coverage or static analysis gates to get a build to pass
We have all experienced a time where we wanted to believe we could make an anti-pattern work but it never does. It is better to learn how to spot these and how to correct them than it is to try to keep tweaking a broken process hoping this time it will be better.

Learning Outcomes:
  • How to spot common DevOps anti-patterns
  • How to correct DevOps anti-patterns when you see them
  • Learn how to figure out if what you are doing is stymied by an anti-pattern and how to rally your team around moving off that anti-pattern
  • Learn that motivation for anti-patterns and how to get people to change their minds about it


avatar for Thomas Stiehm

Thomas Stiehm

CTO, Coveros, Inc.
Tom has been developing applications and managing software development teams for over twenty years. As CTO of Coveros, he is responsible for the oversight of all technical projects and integrating new technologies and testing practices into software development projects. Recently... Read More →

Tuesday August 6, 2019 09:00 - 10:15 EDT
National Harbor 6/7

10:45 EDT

Dev???Ops: The Missing Middle of Security (Elizabeth Ayer)

If you thought it was difficult bringing the Ops and Dev teams to the same table, let’s talk about security! Often housed in a separate team, security experts have no incentive to ship software, with a mission solely to minimise risk.
This talk is a detailed case study of bringing security into DevOps. We’ll look at the challenges and tactics, from the suboptimal starting point of a highly regulated system with a history of negative media attention. It follows an Agile-aspiring Government IT team from the time when a deployable product was "finished" to when the application was first deployed many months later.
This talk is about humans and systems - in particular how groups often need to flex beyond the bounds of what either side considers reasonable, in order to get a job done. We’ll talk about structural challenges, human challenges, and ultimately how we managed to break through them.
There are no villains - everybody in this story is a hero, working relentlessly through obstacles of structure, time, law, and history. Come hear what finally made the difference, filling in the missing middle of DevSecOps.

Learning Outcomes:
  • Understand challenges of bringing Security into DevOps in the most challenging situations
  • Experience a detailed story of a team going from "Done" to "Deployed" - in a painful 9 months!
  • Consider the structural changes which didn't work and the human hacks that did
  • Come away with lessons for starting an initiative and where *not* to compromise
  • Develop a sympathy for the conditions of US government technology


avatar for Elizabeth Ayer

Elizabeth Ayer

Product Manager, 18F
Who are you ?I'm the product lady who had to retire her battle cry of "Shippit!" after too many people misunderstood the intent. They can't take "early and continuous delivery of valuable software" away from me, though!As a product team leader, I have tripped and recovered my way... Read More →

Tuesday August 6, 2019 10:45 - 12:00 EDT
Chesapeake 10/11/12
Wednesday, August 7

10:45 EDT

A Software Engineer's Guide to DevOps (Laurie Barth)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.

Are you new to DevOps and trying to familiarise yourself with the terminology and concepts? Then this talk is for you. In the talk I will cover the 101 of DevOps including terms and technologies. Join me as I talk about why DevOps is necessary and the current ecosystem supporting it.

Learning Outcomes:
- What is DevOps really?
- What problems is DevOps aiming to solve?
- Current tools and technologies
- Terminology and vocabulary of DevOps

avatar for Laurie Barth

Laurie Barth

Software Engineer, Ten Mile Square
Laurie is a software developer and consultant at Ten Mile Square Technologies. Depending on the day she can be found using any number of technologies from different languages to frameworks and other support tools. She loves meeting new people, so come up and say hi!

Wednesday August 7, 2019 10:45 - 12:00 EDT
National Harbor 6/7

15:45 EDT

Oops, We Inflicted DevOps on our Business--Now What? (Allison Pollard, Barry Forrest)
Limited Capacity filling up

It seems that everyone is aflutter with DevOps, the shiny new panacea for all of our software ailments. What technical goodness can DevOps bestow upon us? What riddles does it unlock for us as technologists? How do business goals align in order to wring the true value from DevOps?
Delivering value faster is a desire of many business and IT leaders, and it often looks like a win-lose proposition to achieve it. Metrics and edicts seem to have competing interests, like the car racer being told to "go faster" and "save fuel." Barry and Allison will share their experiences with organizations and teams embracing DevOps and how it impacted both IT and business. We’ll explore the dynamics of goals and the conflict they can incite through an interactive game to further dive into what happens when DevOps is and isn’t in tandem with agile coaching.
Join us to look at what it means to align business and IT goals for creating a successful DevOps culture and how agile coaching fits in.

Learning Outcomes:
  • Recognize lack of alignment between business and IT goals related to DevOps and know it doesn't have to be a win-lose proposition
  • Understand how approaching DevOps adoption (how the goal is set and communicated) can support or hurt a shared business vision and objectives
  • Describe where agile coaching can support lean product development and lean management concepts to amplify a DevOps culture


avatar for Allison Pollard

Allison Pollard

Agile Coach, Improving
Allison Pollard helps people discover their Agile instincts and develop their coaching abilities. As an Agile coach with Improving in Dallas, Allison enjoys mentoring others to become great Scrum Masters and fostering communities that provide sustainability for Agile transformations... Read More →
avatar for Barry Forrest

Barry Forrest

Principal Consultant, Improving
Barry Forrest is a web developer, Scrum Master, and agilist. Barry loves helping make work life better for teams and leaving things in a better state than when he was introduced to the situation. Barry is also an award-winning homebrewer and an avid amateur photographer.

Wednesday August 7, 2019 15:45 - 17:00 EDT
Chesapeake 10/11/12
Thursday, August 8

09:00 EDT

Making Work Visible: Role of Information Radiators in Agile and Telemetry in DevOps (Anil Jaising, Suresh Chinnam)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.

We all know how important Information Radiators in Agile and Feedback Loops (The second way of DevOps) is for making work visible in your software product development initiative. What does it take to design an Information Radiator? With a plethora of tools like Jira, Github, Jenkins, AWS and more, what data should be part of a modern Information Radiator or used for telemetry? What can be used to aggregate large amounts of data and what UI framework can be used to visualize this data? How do we get this large amount of data available in real time? Let's explore why making work visible is key to building a culture of transparency and how technologies like React, Nifi, Spring Boot and more can be used to build an telemetry dashboard

Learning Outcomes:
  • Explain what are Information Radiators in Agile and Feedback Loop in DevOps
  • Design an Information Radiator or a Telemetry dashboard
  • Describe how technologies like Nifi and React can be used to gather and visualize big data in real time


avatar for Anil Jaising

Anil Jaising

Executive Director, JP Morgan Chase
Anil has a unique perspective on agile principles and software development practices working for 22 years as an engineer and as executive leadership for companies including Merrill Lynch, Morgan Stanley, Goldman Sachs, WebMethods, BEA software, Sybase, etc.Anil has several real life... Read More →
avatar for Suresh Chinnam

Suresh Chinnam

Executive Director, JPMorgan Chase
DevOps and SRE Lead20+ years of enterprise software development in Financial ServicesCSM, SAFe Agilist, Yoga (no twists:))

Thursday August 8, 2019 09:00 - 10:15 EDT
Chesapeake J/K/L

10:45 EDT

DevOps Patterns to Enable Success with Microservices (Richard Mills)
Limited Capacity full
Adding this to your schedule will put you on the waitlist.

DevOps can help you dig out of the problem you created for yourself: you spent your lunch period reading the interwebs, drank the kool-aid, and decided to embrace the utopia of microservices to solve all your fragile legacy monolithic code issues and allow you to release small independent changes into production. What you didn't realize is that you've translated an early-lifecycle code architecture problem into a late-lifecycle release management and quality assessment nightmare.
This microservice thing has not provided the nirvana you expected. You ended up with a set of federated services that have hidden dependencies on each other. You have a bucket full of independently changing applications maintained by teams that don't talk to each other and hide behind their service APIs. You want to deploy changes to production, but you can't even figure out which versions work together in your test environments. You need a way to bring your teams closer, continuously integrate the services, deploy the integrated services into various environments, and test that your still-monolithic system works in pieces and as a whole. This is looking suspiciously like a DevOps problem. You discover that your DevOps pipeline is critical to your success.
Someone once said to me "if you are building microservices without DevOps, you've already failed." I've learned that the integration problems created by independent microservices require a high level of automation for build, deployment, testing, and release. You need to create an automated pipeline that works independently for the individual services, yet has enough global knowledge of the system to assess whether small local changes break other services. The pipeline needs to facilitate communication between teams and notify them BEFORE they hopelessly break the system. It needs to keep track of which versions of the services include the right fixes to mutually breaking changes so they can travel together toward production.
In this talk, I highlight the important things you need to succeed with microservices and avoid some of the common problems:
  • Patterns for individual pipelines that combine to assess a working system
  • Using dynamic, ephemeral environments for early cross-service testing BEFORE people break things
  • Determining how appropriate versioning can simplify releases
  • Establishing a branch/merge process to minimize integration problems
  • Determining the value of using containers vs. virtual machines for microservices
  • Enumerating the types of testing needed at different stages of the pipeline
Participants will leave with some new ideas on what they might be doing wrong in their current microservice-based project and/or anticipate what's going to go wrong if they are just getting started.

Learning Outcomes:
  • Avoid common release management and integration problems caused by microservices
  • Define DevOps pipeline steps to independently deliver changes to a federated system
  • Design the right tests at the right stages for your pipeline
  • Use cross-service testing to enforce interfaces
  • Determine and promote cohesive releases of microservices


avatar for Richard Mills

Richard Mills

DevOps Solution Architect, Coveros, Inc.
Richard Mills has more than 25 years of experience in software engineering with a concentration on pragmatic software process and tools. Rich has a specific focus in Agile development methods and is passionate about DevOps, Continuous Integration, and Continuous Delivery. As a DevOps... Read More →

Thursday August 8, 2019 10:45 - 12:00 EDT
Chesapeake A/B/C

14:00 EDT

Service Ownership @Slack (Holly Allen)

Last year the Slack development team and operations teams were living in different worlds. Development teams deployed to production over a hundred times a day, and a centralized operations team tried to fix things when they broke. The operations teams struggled to support systems they had not written. Heros and knowledge islands saved the day over and over. Post-incident postmortems were poorly attended and did not encourage learning.
Slowly, then quickly, all that changed. Slack moved to teams of empowered developers on-call, with embedded SREs, safer production deployments, and actionable alerts. Postmortems focus on learning, and meaningful analysis of incident patterns is done at all levels of the company.
In this talk you’ll hear all about the bumps and scrapes, triumphs and pitfalls of our journey from a centralized ops team to development teams that own the full lifecycle of their systems. It wasn’t easy, but it wasn’t impossible. Hopefully it will inspire you to try something radically different at your company too.

Learning Outcomes:
  • How to organize development organizations for higher reliability
  • How to create learning organizations that can adapt
  • How to think about making major organizational change


avatar for Holly Allen

Holly Allen

Head of Reliability, Slack

Thursday August 8, 2019 14:00 - 15:15 EDT
National Harbor 2

15:45 EDT

Coaching deployment size down and frequency up (Alan Parkinson)
Limited Capacity seats available

Companies that release multiple times a day typically financially outperform companies that don’t. If you have a basic deployment pipeline in place, how do you go from weekly or daily deployments to multiple times a day? The counter-intuitive answer is to break work down into small frequent source code commits and deploy these as they are committed, but doing this has an impact on how developers and testers work.
In this interactive workshop, we will be using games to introduce the concepts of small frequent commits and deployments, learn why existing developer and tester practices may create a bottleneck in the deployment pipeline, and what changes you can make to avoid these bottlenecks. The exercises run within the sessions are designed to be taken back to the office to help with coaching your co-workers.

Learning Outcomes:
  • Exercises to help coach, teach, or influence colleagues to adopt small frequent commits and the required technical practice changes
  • The business case for adopting small frequent commits
  • What is a trunk-based branching strategy and why you need to move to it
  • Using Feature toggles to enable small commits and trunk-based branching strategy
  • What changes do feature toggles bring to Software Testing


avatar for Alan Parkinson

Alan Parkinson

CEO and Product Owner, Hindsight Software

Thursday August 8, 2019 15:45 - 17:00 EDT
Chesapeake 1/2/3