deliver:Agile 2018

Abstract:
Serverless - the new fad that will take over the world! No more servers, no more code, no more engineers, no more operations!
But is Serverless this powerful, really? No, it's not, but it does improve on several key points in software delivery: reduce our infrastructure costs and commitments to just that which we need; outsource development and operations work that isn't unique to our business; and accelerate the lead time of conception of an idea to its deployment in production. This last point, especially, is a wonderful complement to an agile and DevOps delivery approach.
Serverless architectures are those that incorporate third-party backend-as-a-service (BaaS) products into the application, or that use functions-as-a-service (FaaS) platforms, like AWS Lambda, to run server-side code in a fully managed, event-driven, environment. By using these ideas such architectures remove much of the need for the traditional “always on” server system.
In this session Mike Roberts gives an introduction to Serverless techniques, together with examples of the types of application where it is well suited. He proceeds to give cautiously optimistic detail of the benefits, and limitations, of such an approach, concluding with how he expects Serverless to develop over the coming months and years.

Learning Outcomes:

• Learn what Serverless is, what its benefits are, where it is useful, along with limitations to be aware of.

Attachments:

• Introduction to Serverless - deliverAgile.pdf

Abstract:
While service meshes may be the next "big thing" in microservices, the concept isn't new. Classical SOA attempted to implement similar technology for abstracting and managing all aspects of service-to-service communication, and this was often realized as the much-maligned Enterprise Service Bus (ESB). Several years ago similar technology emerged from the microservice innovators, including Airbnb (SmartStack for service discovery), Netflix (Prana integration sidecars), and Twitter (Finagle for extensible RPC), and these technologies have now converged into the service meshes we are currently seeing being deployed.
In this talk, Daniel Bryant will share with you what service meshes are, why they're well-suited for microservice deployments, and how best to use a service mesh when you're deploying microservices. This presentation begins with a brief history of the development of service meshes, and the motivations of the unicorn organisations that developed them. From there, you'll learn about some of the currently available implementations that are targeting microservice deployments, such as Istio/Envoy, Linkerd, and NGINX Plus.

Learning Outcomes:

• Attendees will walk away from the talk with a high-level overview of the concept, tools for deciding when best to use a service mesh, and a getting started guide if they decide this technology is the right fit for their organisation.

Attachments:

• deliver agile - what is a service mesh FINAL.pdf

Abstract:
We will invite some volunteers from the audience to work as a Mob Programming team on a simple coding exercise facilitated by Woody Zuill. We'll provide instruction on the basics of Mob Programming, and Woody will guide the team both as a "product owner" and as a facilitator to demonstrate some of the basic techniques of teamwork and collaboration.
This is a mini-version of a Mob Programming Workshop due to the time limits of the session, but we'll still be able to cover some important things such as how to work together, how to communicate our intent, how to keep calm when things aren't going well, and how to take baby steps using Test-Driven Development.

Learning Outcomes:

• • The basics of Mob Programming
• • How to introduce Mob Programming to your teams
• • How to give each member of the team a chance to contribute
• • What it takes to be a decent team member
• • The importance of Kindness, Consideration, and Respect

Abstract:
How frequently does a good agile team deploy to production? Not every team is capable of deploying "on every commit". What does it take for a team to even start deploying at the end of each sprint, or each week, or each day?
Most companies don't realize that deploying more frequently often requires both significant technical change as well as cultural change. In this talk, I'll guide you through what it takes to deploy more frequently. I'll draw on the unique challenges that teams must overcome at each step of the way, from deploying once a month all the way down to full continuous delivery. If your team has been struggling to go faster, come see how you can change to get there. And if you already are at full continuous delivery, come see how to go even faster than that!

Learning Outcomes:

• Attendees should leave the talk with a full understanding of the different challenges for deploying at these intervals:
• - Once per sprint
• - Every few days
• - Daily
• - On Every Commit
• Attendees will learn about important DevOps techniques, including:
• - Blue/Green Deployments
• - Feature Toggles
• Attendees will be able to answer to these common cultural questions:
• - Why does more frequent deployment not translate into more risk?
• - How do you ensure quality without a dedicated QA team of manual testers?
• - Do all deployments deliver functionality?
• - Is it actually ok to let commits go to production without human intervention?

Abstract:
You have an idea for an app. It’s going to be amazing! Of course you want to test drive it to build it right. But you have to get it out there fast. You need to use an Agile, lean startup approach, with all the benefits of DevOps. And it needs to grow quickly and iteratively. The big problem is that your full staff accounts to one person… you.
In this session, you will learn how to make your app dreams come true. Using python, git and Heroku, Bryan will demonstrate a simple way to quickly iterate on your ideas, moving code through tests and deploying right to production.

Learning Outcomes:

• - Practice DevOps in a safe environment
• - Create hobby projects using technical practices
• - Mange projects with Heroku
• - Setup an API project

Abstract:
Shipping code is hard and it is rough! It doesn't have to be. Using Docker, Heroku and CircleCI you can set up a world-class Continuous Integration and Continuous Deployment pipeline in an hour with advanced functionality like Heroku preview apps, provisioning servers on-demand for to scale and containers that leverage layering to enforce Enterprise requirements, while giving developers access, flexibility and speed to get their work done. With duluca/minimal-node-web-server docker image and how you can tailor it to build your micro-services or web servers in a matter of minutes using Docker and deploy your web app on the cloud.

Learning Outcomes:

• Why a robust CI & CD pipeline is critical to Agile development
• How to containerize a web app with its own web server using Docker and Node
• How to build and publish a container using npm scripts
• How to set up a Continuous Integration pipeline with Circle CI
• How to set up a Continuous Deployment pipeline with Heroku
• How to use on demand server instances with Heroku Preview Apps

Attachments:

• shipit-or-itneverhappened.pdf

Abstract:
What would you do if your customers loudly complained about application slowness, your data center did not allow you to scale, and your technology future was on another platform?
Let us share what we did to WIN within 6 months! We used Kanban, a lean / agile practice to support frequent delivery and minimize work in progress (WIP). We optimized by rewriting key areas using microservices to be Cloud native on Platform as as Services (PaaS). Retained older solutions that would run on a Cloud Infrastructure as a Service (IaaS). Integrated with systems hosted at our on-premise data center. Finally, use DevOps or CloudOps to ensure our IT team were able to maintain and support the application. The goal was Performance, Reliability, and Scalability.

Learning Outcomes:

• At the conclusion of this presentation participants will be able to:
• 1) Understand the need for a Digital Transformation Strategy
• 2) Discover the difference between IaaS, PaaS, and Hybrid models and use each model appropriately
• 3) Learn about Microsoft Azure good, bad, and ugly experiences

Attachments:

• Technology Agility_AgileConferemce_Fin.pdf

Abstract:
“We might think of choreography in terms of ‘rehearsal’; that is, as the working out and working through of utopian, nevertheless ‘real’, social relations.” Andrew Hewitt
A cross-disciplinary exploration of choreography & (web)code. By ‘rehearsal’ it is meant a sort of temporary stage for experimenting with web design tools which follow choreographic methods and thematic concerns. This format is very similar to a open workshop, open to any participants curious to explore the use of choreographic techniques to generate newness in design, new modes of thinking composition matters, participation, relations and articulations between bodies and technologies. Traditionally, a rehearsal is a built in process, a space and time for developing ideas and work acknowledging unexpected and unpredictable results. Another important point about the ‘rehearsal series’ is to break the distancing between mind/body, self/other, subject/object, discovery/invention. Enhancing the idea of process over product: processes of becoming, becoming structures, becoming codes and scripts.
This project focus on the use of Free/Libre Open Source (Floss) models/ philosophies technologies, questioning how may creative coding practices interfere deeper with interface design and information displays — when considering new (choreographic) vocabularies, embodiment and new movement perception possibilities.
The flexibility of code allows for a combination of possibilities, not only for the live performance setting, but also for the use of the code itself by other designers, just as in any choreography that can be re-interpreted, re-created and adapted. The code serves as a generative tool for new possible outcomes in the creation of graphics for interfaces and a way of playing with the choreographic logic. Therefore, this method promotes disciplinary openness, by sharing ideologies and methodologies and questioning structures of collaboration and of intellectual property.
Choreographic thinking and methodologies address questions of unpredictability, indeterminacy, immateriality, spatial and temporal paradoxes that can inform design on how to respond to the digital logic. As in as considering the indeterminate interactions between scripts, machines and users, and the complex inter-relations, dependencies and contingencies of design. In short, its performative stance.

Learning Outcomes:

• Building process: small groups are created for sharing knowledge, mind mapping and nurturing collective discussion on the topics, references and experiences during the day.
• The outcome is a piece of ‘choreographic code' — all participants are invited to contribute to the choreographic code by translating the ideas discussed in the session into html/css/javascript functions or as prototypes developed in other formats.

Abstract:
Many developers have had the experience of learning new development methods such as TDD and design patterns only to find they can’t readily use them in their current situation. These skills, however, are very critical to Agile improvements. But we seem caught in a ‘catch-22’ situation. The answer is by looking at the challenges present and solutions required and creating a road map for adoption.
The first step is to become aware of the need for safety, lowering risk while you pay down technical debt. We must also be aware of how the changes to our eco-systems (i.e., the way our teams work together) due to Agile improvements will cause problems. This is Conway’s corollary - when you change your team structure, Conway’s law will work against you.
This talk presents an approach to move out of this dilemma:
1) Create agreements among your team members on the objectives you are trying to achieve as well as your agreed to behavior – e.g., Hippocratic oath of coding (leave your code at least as good as it was before you touched it)
2) Wrap your system with tests for safety
3) Some practices that can be used to improve practices gradually, but across the board (e.g., programming by intention, encapsulation of constructors)

Learning Outcomes:

• Attendees will understand the issues they must attend to while being provided a few simple practices that will move them forward.

Abstract:
Cucumber is usually considered a customer acceptance test automation tool. However in many situations, it can be used as a unit testing framework as an alternative to JUnit. Cucumber tests separate the test structure in feature files from the implementation in step definition files. This separation can increase maintainability. You can create customer readable tests for business rules and domain terms, rather than using less customer-readable code. Having alternative tools allows you to use the one that best defines the test specification.

Learning Outcomes:

• Applying an alternative way of expressing unit tests
• Using a common test representation for both ATDD/BDD and TDD
• Separating test structure from test implementation for maintainability
• Representing customer domain terms and business rules as customer readable tests

Abstract:
It might seem like a Big Data or Machine Learning project wouldn't lend itself to an agile software development approach. The "Big" in Big Data implies lots of infrastructure and up front work in order to get things moving before a single piece of useful user functionality can be delivered. In fact the very experimental nature and huge unknowns implicit in almost all of these projects makes an agile approach very well suited.
Ade Miller has spent the last four years working on Big Data and Machine Learning projects, first and CenturyLink Cloud and more recently at Conga. He will be presenting the results of his experiences successfully delivering with agile. In addition to talking about his experiences, what worked and what didn't, he will also be discussing how to adjust your agile approach to take into account the unique constrains of these types of project.

Learning Outcomes:

• Attendees will have a clear understanding of the constraints that big data and machine learning focused projects place on the agile software development lifecycle. In addition they will understand opportunities presented by taking an agile approach to such projects.

Abstract:
Are your tests slow or brittle? Do you get a sinking feeling when you need to refactor? Do you worry your unit tests aren't actually testing anything important? If so, you could benefit from exploring a mock-free approach to TDD.
This session is a comprehensive and practical guide to testing without mocks and other test doubles. We'll talk about real-world code, not dogma, and discuss solutions for tough problems—such as testing infrastructure code, disentangling logic and infrastructure, testing units in isolation, dealing with side effects, approaches to design, and more.

Learning Outcomes:

• Learn to test-drive code without using mocks
• Learn to test code in isolation when not using mocks
• Learn mock-free solutions to problems that seem to require mocks (such as infrastructure code)
• Learn to use mock-free TDD to improve designs
• Learn to create fast, safe test suites that have minimal integration tests

Attachments:

• Testing-Without-Mocks-Shared.pdf

Abstract:
In an interview format, Ron and Chet will discuss their current views regarding Agile Software Development, the opportunities and threats of certification and scaling, and how software professionals can best operate within current “Agile” organizations and projects.
Contents may include:
Why story points are a bad idea;
The need for better ways for developers to build skill;
Making the world safe for programmers;
The central role of Running, Tested Software.

Learning Outcomes:

• Increased awareness of the essential elements of surviving and thriving in “Agile” teams and organizations.

Attachments:

• deliverAgile 2018 copy.pdf