deliver:AGILE 2019
deliver:Agile 2019
APRIL 29 - MAY 1, 2019 Nashville, TN
Keynote Videos
deliver:Agile 2019 Session Materials
Meet Our Speakers
Keynote Speakers
Enterprise transformation (and you can too)
“That would never work here.” You’ve likely heard this sentiment (or maybe you’ve even said it yourself). Good news: change is possible. Donovan Brown explains how Microsoft’s Azure DevOps formerly VSTS went from a three-year waterfall delivery cycle to three-week iterations and open sourced the Azure DevOps task library and the Git Virtual File System.
Donovan Brown
View Bio
BIO
Meet The Man in the Black Shirt. Donovan Brown is a Principal DevOps Manager on Microsoft’s Cloud Developer Advocacy team. Why is DevOps one of the hottest topics? Because it hurts the most. Luckily, Donovan’s unofficial tagline is #RubDevOpsOnIt and he’s here to make it all better. Before joining Microsoft, Donovan spent seven years as a Process Consultant and a Certified Scrum Master. Developer Tools are his thing. Donovan has traveled the globe helping companies in the U.S., Canada, India, Germany, and the UK develop solutions using agile practices, Visual Studio, and Team Foundation Server in industries as broad as Communications, Health Care, Energy, and Financial Services. What else keeps the wheels spinning on The Man in The Black Shirt? Donovan’s also an avid programmer, often finding ways to integrate software into his other hobbies and activities, one of which is Professional Air Hockey where he was ranked as high as 11 in the world.
The Origins of Opera and the Future of Programming
There’s a story to tell, about musicians, artists, philosophers, scientists, and then programmers.
There’s a truth inside it that leads to a new view of work, that sees beauty in the painful complexity that is software development.
Starting from The Journal of the History of Ideas, Jessica traces the concept of an “invisible college” through music and art and science to programming. She finds the dark truth behind the 10x developer, a real definition of “Senior Developer” and a new name for our work and our teams.
Jessica Kerr
View Bio
BIO
Jessica (@jessitron) is a talented software developer who works for hot startup Atomist. A modern technologist, she’s not easily categorized. Jessica codes a lot in TypeScript. She’s got architecture and automation chops. She also studies and talks about high performing teams, and developer productivity. Jessica is a thought-provoking speaker, and we’re excited for her to kick off the program and set the tone for the conference.
Speakers
Testing Microservices from Development to Production
Daniel Bryant
View Full Abstract
Testing microservices is challenging. Dividing a system into components naturally creates inter-service dependencies, and each service has its own performance and fault-tolerance characteristics that need to be validated during development, the QA process, and continually in production. Join Daniel Bryant to learn about the theory, techniques and practices needed to overcome this challenge. Introduction to the challenges of testing distributed microservice systems
Learning outcomes:
- Learn tactics for isolating tests within a complex microservice ecosystem
- Whistle stop tour of consumer-driven contract testing and API simulation
- Implementing fault-injection testing to validate nonfunctional requirements in development and QA
- An introduction and discussion of the need for continually validating microservice systems running in production, both through observability and practices like chaos engineering
Making a video game on the bus: a story of rapid iteration
Qristy Overton
View Full Abstract
Portland, 6PM: board the bus for Seattle to give a talk about making video games. Realize that I need to write a tutorial game. Open laptop, stare at cursor.
Seattle, 9PM: Get off the bus with a shiny new game.
This session will walk through how I got from Portland and Seattle — the steps to making a small game in a small timeframe and what made it possible.
Learning outcomes:
- Learn the high-level steps involved in making a video game
- Recognize analogous ways they could change their technologies or culture to facilitate rapid iteration
DevOps Culture Immersion (with Lego and Chocolate)
Dana Pylayeva
View Full Abstract
Organisations today can no longer afford to deliver new features to their respective markets once a year or even once a quarter. In the attempt to catch up with the competition, they jump onto DevOps journey starting with the “How” and losing the sight of “Why” and “What”.
Join this gamified simulation workshop to gain a solid understanding of foundational principles of the DevOps culture. Experience the benefits of DevOps transformation even before initiating one in your enterprise!
Ideally designed for organisations that are
• Evaluating their approach to DevOps transformation
• Making their first steps in adopting DevOps practices
• Noticing the gaps left by “automation only” approach to DevOps.
This course
• Is based on real-life examples from medium to large size organizations
• includes the latest findings from the State of DevOps report 2018
• delivers key ideas from “The Phoenix Project” by Gene Kim
• facilitates a number of debriefings to draw parallels between the issues highlighted in the simulation and some of the similar issues the learners may have in their organisations (impact on business, segregation of duty, change management, Job security and even fear-based culture)
Through this powerful role-based simulation with LEGO and Chocolate, participants experience the benefits of cross-training, learn to eliminate silos, adopt systems thinking and gain valuable insights that can be immediately applied in their organisations.
Learning Outcomes:
- Explain the benefits of the business and IT alignment with DevOps.
- Identify the principles and practices including: Continuous Integration, Continuous Delivery, testing, “shift left” on security, “one piece flow” and the Three Ways of DevOps.
- Relate DevOps to Agile, Lean and Theory of Constraints.
- Discuss the critical role of the safety culture in enabling Continual Experimentation and Learning at the level of an organisation.
- Explain the changes DevOps brings to a Segregation of Duty, Audit requirements, CAB, risk management etc.
Patterns of Instantiation
David Bernstein
View Full Abstract
One key difference between writing object-oriented software and writing procedural software is the notion of object construction. Objects must be instantiated before they can be used. This is much more than a technical detail, it is at the very core of OO’s usefulness.
By separating an object’s construction from its usage, we can encapsulate an object’s type during construction, so that it can be used without revealing its type. This gives an object testability, extensibility, and modularity. Building a program’s object graph separate from using those objects simplifies software construction and reduces dependencies so that code is simpler to work with.
One key distinction—and therefore opportunity—of object-oriented programming over procedural programming is that objects have two phases in their lifecycle: creation and use. By separating these two phases so that certain kinds of tasks are done when objects are created, and other kinds of tasks are done later during usage, we can build software that’s more modular and extensible.
In this session, we’ll explore how you can leverage object instantiation to build decoupled, extensible and maintainable systems. We’ll cover several common antipatterns in instantiation along with replacement patterns that drop the cost of ownership for software built in object-oriented languages such as Java, C Sharp, C++, etc.
Learning Outcomes:
- Leverage object instantiation to write more decoupled and testable code
- Learn how to use the object-oriented model to build maintainable software
- Recognize instantiation anti-patterns that make code harder to extend
- Apply instantiation patterns that improve testability and extensibility
- Know when to use factories and how to construct them efficiently
- Encapsulate construction to improve an object’s testability and extensibility
DevOps ICU: Improving DevOps Results by (Correctly) Integrating UX
Debbie Levitt
View Full Abstract
Agile methodologies lack the details of how UX fits into software dev projects. Some suggest that a Product Manager describing features is enough for developers, UX should train others to do their specialized jobs, or excluding UX experts solves them being “too siloed” and “not collaborative.” This happens with no other role in software dev; it’s hurting culture, efficiency, and productivity, and creating poor products for customers.
Your customer only sees your UX, not 1000 developers or if you were Agile or Lean. Companies are figuring out that UX specialists and the User-Centered Design process are good investments that more than pay for themselves. Recent highly-publicized UX failures remind us that skimping on the UX process can alienate customers, create negative media attention, and burn millions of dollars.
Learn how the UX process fits into Agile; augments DevOps goals; increases customer satisfaction; and saves time, money, and sanity before developers write a line of code.
Learning Outcomes:
- Learn that DevOps goals overlap with UX goals.
- Correct integration of UX experts and tasks saves time and money, increases productivity and efficiency, creates the best idea execution for the target customers, and keeps engineering’s changes and rebuilds to a minimum.
- Learn how UX specialists conduct user research; design your entire product, app, website, or system; validate it through user testing; iterate to fix flaws; and deliver vetted blueprints so you can build once.
- How User-Centered Design fits into project timelines and development methodologies including Agile and Lean.
Getting started with Azure DevOps
Donovan Brown
View Full Abstract
DevOps is about people, process, and products. Getting it all right requires effort, but the benefits to your organization and customers can be huge. Microsoft has a fantastic set of products that can help you get the most out of the cloud with any language on any platform. In this demo-heavy session, Donovan Brown shows you how to transform your team.
Learning Outcomes:
- Become familiar with a platform to help companies on their DevOps transformation
No Microservice Is An Island
Michele Titolo
View Full Abstract
You don’t deploy a single microservice. The journey to microservice architecture involves more than how code is written or applications are packaged. It’s about creating an interconnected ecosystem that keeps things running. Infrastructure and tools have only grown in importance as microservices have emerged as a dominant architecture pattern. Deploying, scaling, and monitoring are more important for microservices than they ever were before. Attendees will leave this session knowing the basic infrastructure and tooling needs for microservices to be successful.
Learning Outcomes:
- Learn the tooling and infrastructure needed to create a reliable microservices ecosystem.
Introduction to Kafka Streams
Pooja Rallabhandi
View Full Abstract
Apache Kafka is a high-performance distributed streaming platform. It is a scalable publish-subscribe messaging system that helps in building real-time applications with simple data pipelines that transform and react to the incoming streams of data. Over the past years big-data companies have struggled with low-latency ingestion of large volumes of event data and the demand to be continuously reactive as the data arrives. Existing message queues are not an ideal solution when applications require high-throughput and fault-tolerant publish-subscribe messaging system. Kafka provides a platform for developing applications that react to streams of data to do real-time analytics, transform, aggregate real-time data flows and perform complex event processing. In this session my aim is to introduce the basic concepts of Kafka and Kafka-streams and provide use-cases where Kafka has proven to be a better solution for building event-driven applications.
Learning Outcomes:
- This session will introduce you to the concepts of Kafka and Kafka-streams and help you build next-generation event driven applications.
Chaos Development: Removing software as the inhibitor of Agile
Fred George
View Full Abstract
You’re starting a new project. You’re using real Agile (finally!). Kickoffs, initial stories, tool selection… the atmosphere is electric. That first iteration is complete; yes, a few kinks, but we’re rolling now. A couple of more iterations flow by before the euphemism “technical debt” is heard. The next couple of iterations are a bit of a struggle. Finally, it looks like the goals may not be achievable. Programmers mumble about faulty designs and changing requirements. Business owners roll their eyes, thinking, “Here we go again…”.
What happened? Practical Agile practices were followed, but were mated with very traditional, inflexible programming styles.
Agile development centers around accommodating change. Stories can be played in business-friendly order. Unanticipated changes can and should be accepted with aplomb. Therefore the design and implementation of the software must also accommodate the uncertain.
Chaos engineering is the vogue term used to describe the design of systems that handle the unexpected. Similarly, software development must accommodate unexpected demands. It needs to focus on chaos development.
In this presentation, we will suggest two distinct approaches to chaos development. The first exploits existing OO languages, but employs a particular style of programming, and can be used for most business problems. The second uses an event bus and highly decoupled services, a technique called asynchronous MicroServices, and is appropriate for addressing fuzzy problems.
For the first style, we will delve into the aspects of the style, particularly its focus on small, tight classes; extensive exploitation of design patterns; and careful monitoring of complexity metrics.
For the second style, we will briefly address the principles at work, and show a brief animation of the type of problem nicely handled by asynchronous MicroServices.
Learning Outcomes:
- The audience should re-examine their engineering practices, and in particular realize that some of their practices are inhibiting successful Agile product development. That realization is soothed by seeing some practical, real-world examples of mitigations.
Test-First from the Product Owner to the Dev Team to Dev Ops
Al Shalloway
View Full Abstract
Test-First is a larger umbrella than many think. It ranges from more than Acceptance Test-Driven Development and Unit Testing. Done properly, it starts with product management and goes through value realization. This talk will not discuss all of test-first but will center on how Test-First affects the developer – from a requirements point of view to development to release. It will discuss how test-first with the product owner sets the stage for good design as a side-affect of getting clarity on requirements. This “side-effect” is something called out in design patterns, but not often discussed. The talk will also discuss on how the use of test-first needs to focus on value realization, not merely writing the code. The talk concludes by discussing the relationship of developers to ops and other post-production roles in the organization.
Learning Outcomes:
- how test-first is useful virtually throughout the value stream
- how design patterns espouse a test-first mind set
- the relationship between the code quality of “testability” relates to quality design
The Extreme Agility of Serverless Architectures
Joseph Emison
View Full Abstract
Most of the writing and examples on serverless application architectures either lack enough detail to understand exactly why serverless has any real advantages over other methods of building software, or are far too in-the-weeds to understand how the particular discussion would be better than an alternate implementation that was not serverless. In this workshop, I will define and explain how serverless is different from other application architectures, explaining the philosophies and benefits of what good serverless architectures deliver. Then, I will take the participants through each of four different application architectures, taking the time for everyone to pull the git repos and build and run the code, walking through more of the details of the code, and leaving everyone with very concrete examples of the substantial agile benefits of good serverless architectures.
Learning Outcomes:
- What serverless means
- What good serverless architectures look like
- Why serverless architectures deliver better agility to organizations than traditional application architectures
The Observability Pipeline
Tyler Treat
View Full Abstract
The pervasiveness of cloud and containers has led to systems that are much more distributed and dynamic in nature. Highly elastic microservice and serverless architectures mean containers spin up on demand and scale to zero when that demand goes away. In this world, servers are very much cattle, not pets. This shift has exposed deficiencies in some of the tools and practices we used in the world of servers-as-pets. Specifically, there are questions around how we monitor and debug these types of systems at scale. And with the rise of DevOps and product mindset, making data-driven decisions is becoming increasingly important for agile development teams.
In this talk, we discuss a new approach to system monitoring and data collection: the observability pipeline. For organizations that are heavily siloed, this approach can help empower teams when it comes to operating their software. The observability pipeline provides a layer of abstraction that allows you to get operational data such as logs and metrics everywhere it needs to be without impacting developers and the core system. Unlocking this data can also be a huge win for the business with things like auditability, business analytics, and pricing. Lastly, it allows you to change backing data systems easily or test multiple in parallel. With the amount of data and the number of tools modern systems demand these days, we’ll see how the observability pipeline becomes just as essential to the operations of a service as the CI/CD pipeline.
Learning Outcomes:
- What is observability and how does it relate to monitoring?
- How does operations and DevOps relate to observability?
- What is the observability pipeline?
- How can we implement observability and support data-driven decisions for sophisticated microservice-based systems?
Scaling Agile Delivery
James Shore
View Full Abstract
When multiple teams work on the same product or set of products, how can those teams work together effectively? How do we create a sustainable codebase, minimize cross-team dependencies, and divide up the work? Scaling isn’t just a management problem; it’s a technical problem too.
In this session, James Shore will share ideas and strategies based on his experiences helping organizations with multi-team products. He’ll share concrete techniques and look back at what’s worked, what hasn’t, and the context needed for each idea to be successful.
Learning Outcomes:
- How to minimize cross-team dependencies
- How to coordinate between multiple teams
- How to handle cross-cutting concerns such as platform development
- Understanding the role of architecture
Abuser Stories: Thinking Like the Bad Guy to Reduce Software Vulnerabilities
Judy Neher
View Full Abstract
- Abuser stories give us a way to view our systems from our enemies perspective. Think “user stories” through the bad guy’s lens.Abuser stories capture potential vulnerabilities in software systems, using the standard user story format. While user stories are written from a user perspective, abuser stories are written from an enemy or attacker’s perspective and describe the enemy’s mal-intent and motivation.The session will look at the concept of Abuser Stories in-depth, with hands-on exercises to create and practice your own.Learning Outcomes:
- How seemingly benign functional user stories can create vulnerabilities in our software, leaving lots of opportunity for our enemies to take advantage of our weaknesses.
- How to use the concept of abuser stories to shed some light on where these vulnerabilities can be introduced.
- How to craft a good abuser story.
- How to craft refutation criteria so that we can determine that the attack depicted by the abuser story is not possible.
- How to estimate and rank abuser stories.
Leadership Guide for the Reluctant Leader
David Neal
View Full Abstract
Regardless of the technology you know, regardless of the job title you have, you have amazing potential to impact your workplace, community, and beyond.
In this talk, I’ll share a few candid stories of my career failures… I mean… learning opportunities. We’ll start by debunking the myth that leadership == management. Next, we’ll talk about some the attributes, behaviors and skills of good leaders. Last, we’ll cover some practical steps and resources to accelerate your journey.
You’ll walk away with some essential leadership skills I believe anyone can develop, and a good dose of encouragement to be more awesome!
Practical Refactoring: Simple Steps to Cleaner Code
Woody Zuill
View Full Abstract
The goal: Clean Code That Works, and getting there is half the fun. Working with a legacy mess can be frustrating, boring, dangerous, and time-consuming. When FIBS occur (FIBs = Fixes that Introduce Bugs) you often enter an endless Test and Fix cycle that can quickly escalate into a nightmare. I’ve been there, you’ve been there. How do we return to pleasant dreams?
In this code-centric mini workshop we’ll look at ways to introduce sanity and calmness into the process of maintaining and improving buggy, poorly written, poorly designed code. Few slides, mostly code. I’ve been fighting the good fight for a long time and we are going to show you how to turn any project around and have fun doing it. It is our opinion that we can fix and enhance any code.
We’ll be working on an example project and learn the steps of making changes to code in tiny steps. We’ll find ways to clean up the most common problems of duplication, clutter, and complexity.
Our approach will have us using Solo or Pair, and maybe Mob Programming to do exercises and work with others as we experiment with many simple techniques that combine together to make a big impact on the quality and cleanliness of our code.
Learning Outcomes:
- The basic goal is to learn enough about refactoring in baby steps so you can begin doing this immediately. We’ll be covering a number of basic refactoring techniques that provide a wide range of easy to implement improvements, and learn how to identify some common code “smells” (symptoms of potential problems)
17th Century Shipbuilding And Your Failed Software Project
Pete Cheslock
View Full Abstract
Around 4:00 PM on August 10, 1628 the warship Vasa set sail in Stockholm harbor on its maiden voyage as the newest ship in the Royal Swedish Navy. After sailing about 1300 meters, a light gust of wind caused the Vasa to heel over on its side. Water poured in through the gun portals and the ship sank with a loss of 53 lives.
The fundamental reason the Vasa sank is, of course, that the ship was unstable. The reasons that the Vasa was constructed to be unstable, and launched when known to be unstable, are numerous and varied. The lessons to be learned are as relevant to our modern-day attempts to build large, complex systems as they were to the art and craft of building warships in 1628.
We’ll talk about why things fail – and how the failure of the vasa often mimics the failure of large software engineering projects.
Learning Outcomes:
- What we can learn from our past to improve how we build and deliver software.
Cutting Code Quickly
Llewellyn Falco
View Full Abstract
In this guided demo, we are going to look at 3 different techniques that are remarkably powerful in combination to cut through legacy code without having to go thru the bother of reading or understanding it.
The techniques are:
Combination Testing: to get 100% test coverage quickly
Code Coverage as guidance: to help us make decisions about inputs and deletion
Provable Refactorings: to help us change code without having to worry about it.
In combination, these 3 techniques can quickly make impossible tasks trivial.
I will be doing the gilded rose kata. It is encouraged to try it out yourself first: https://github.com/emilybache/GildedRose-Refactoring-Kata
Learning Outcomes:
- Combination Testing
- ‘Lift If’ Refactoring
- Provable Refactorings
Principles of Collaborative Automation
Jessica Kerr
View Full Abstract
Great automation doesn’t replace humans; it enhances us. When we are choosing or building tools for our team, we want them to play like team members: keep us informed, make the easy decisions repeatably, and pass the hard decisions to the humans along with the information we need to make them.
Based on research in human-centered design, this talk enumerates principles and challenges of collaboration for programs. It lists strategies for eliminating “human error” as well as human frustration. Our tools should make us smarter, not hide knowledge from us. In aviation and medicine, this is a million-dollar investment–but when we construct our own tools, collaborative automation is within our reach.
Learning Outcomes:
- People who write development tools (including for themselves) will learn how to make them work better with people.
- Developers will learn something about making software feel more collaborative to their users
- Everyone will be more frustrated with their existing tools that don’t follow these principles, and motivated to look for ones that do.
Beyond Pear Shaped: The future of pairing
Marlena Compton
View Full Abstract
Pair programming is in the midst of a renaissance. For a long time, pair programming was seen as just one of the 12 practices of the agile methodology, Extreme Programming, but pair programming is now flourishing on its own whether it is used in an XP environment or not.
Marlena will talk about the history of pair programming as it fits into the history of software and what it means in a current cloud environment. Attendees will get an advanced perspective on pairing, what they can do to encourage pairing and when they might not want to pair.
Learning Outcomes:
- Attendees will get an advanced perspective on pairing, what they can do to encourage pairing and when they might not want to pair.
Building Evolutionary Architectures
Rebecca Parsons
View Full Abstract
With business models and business needs changing so rapidly, an adaptable architecture is critical to allow systems to cope with change. Historically, adaptability has been sought through anticipating the places where a system must be adaptable and through various architectural approaches. However, recent experiences have shown these approaches to be inadequate, at least as currently practiced. This talk presents some principles of evolutionary architecture that allow systems to respond to change without needing to predict the future. We then describe three approaches that realize these principles and discuss how these approaches support adaptability of systems in an evolutionary way.
Learning Outcomes:
- Attendees will learn about the underlying principles of evolutionary architecture and will see how various techniques like continuous delivery support creating and evolving the architecture of systems.
Applying the Serverless Mindset to Any Tech Stack
Ben Kehoe
View Full Abstract
Serverless is a nebulous buzzword, and is often equated with Functions as a Service (FaaS) platforms like AWS Lambda. However, serverless is about something deeper, and in the end is not even about particular technologies. Serverless is, instead, a mindset: make technology decisions that further your ability to focus on what differentiates you as a business. This talk will dive into the serverless mindset, how it relates to serverless technologies, and show that it can serve as a compass to guide decision-making even in organizations that are entirely on-prem.
Learning Outcomes:
- Participants will learn that serverless is an approach to technology that drives focus on business value and differentiation, and that the purest application of this approach is to use fully managed public cloud services, but that the approach can be applied for any tech stack.
Five Underplayed Premises Of TDD
GeePaw Hill
View Full Abstract
Test Driven Development seems very much like pure technique, but that’s just because technique is easier to point at than what it really is: attitude. When you lead your teams towards TDD, you need to focus on their worldview and let them use that to build technique. GeePaw explores five essential premises leaders need to understand to guide their teams into full-on TDD.
The Money Premise — We’re in this for the money.
The Judgment Premise — We’ll rely on individuals making local decisions.
The Correlation Premise — Internal quality is productivity.
The Chaining Premise — We’ll test mostly in very small parts.
The Steering Premise — Tests & testability are first-class design participants.
Learning Outcomes:
- A basic understanding of the deepest attitudes of the TDD approach.
This is not your fathers Microsoft: Journey to 70,000 deploymets a day
Martin Hinshelwood
View Full Abstract
In the last few years Microsoft has gone from delivering software in 2 years + to continuous delivery on products like Windows, Xbox, and on the tools that started it all from the Visual Studio team. Come and see some of the ways that Microsoft made this transition and changed the way they do business forever.
Learning Outcomes:
- Attendees will learn many possible practices that would help them deliver more and take leanings from how Microsoft failed.
functional fundamentals: functional programming for the object-oriented engineer
Autumn Crossan
View Full Abstract
“functional” is a word that gets thrown around a lot, especially in frontend web circles. problem is, functional programming seems completely unapproachable; it requires you to dedicate lots of time to understanding the math behind category theory, set theory, and discrete mathematics. right?
what if i told you i could give you three useful, functional-style fundamentals that you could grok quickly, understand intuitively, and use productively?
join me as we learn about higher-order functions, functional composition, and strategies for blending object-oriented and functional code to make an elegant, well-constructed whole.
Learning Outcomes:
- learn more about functional programming
- streamline the process of writing your object-oriented code with functional techniques
- learn functional strategies to implement features and write code in a stateless manner
Distributed Agile Teams Dialed to 11
Joseph Moore
View Full Abstract
Agile methodologies promote and advocate for colocated teams, but many if not most companies employ distributed teams. Can distributed teams turn the Agile dials up to 11 and still have whiteboards, sticky notes, pair programming, TDD, and full-participation agile ceremonies, all without regulating some team members to being second-class citizens of the project?
Yes we can, and yes we do! Joe will walk through the processes, practices, and enabling technologies developed at pioneering agile consultancy Pivotal Labs over the past 13 years. Learn how to incorporate a few occasional “remotes”, maintain teams split across regions and timezones, and even how to adopt an “everyone’s remote” approach to your distributed agile teams.
Part I of this session is an overview and discussion of the team processes, pro-tip, and pitfalls of several distributed agile team structures; Part II will be a deep dive into supporting technologies, remote pair programming, and a unified solution to all time-zone challenges… kind of.
Learning Outcomes:
- Demonstrate that distributed agile teams can be as successful as colocated agile teams
- Teach attendees the process skills to efficiently run a distributed agile team
- Teach attendees the tools and technologies that help enable successful distributed agile teams
- Attendees share out their own pro-tips and pitfalls so everyone can improve, including the speaker.
Measuring the Business Impact of Agile Technical Practices
Jason Tice
View Full Abstract
Are you in an organization where management or leadership challenges the adoption of agile technical practices by questioning the true business value such practices provide?
Perhaps you’ve heard – “pair programming – why on earth would we pay two people to work on the same code at the same time – that’s not productive” or “why should we spend time to automate our deployment pipeline when our release process only takes about 15 minutes to run manually – we can release every day if we want to” or even better “why do we have to pay everyone overtime for being on-call during after-hours Sev1 incidents, when 90% of the time the DBAs are the root cause of Sev1 problems so everyone else gets paid overtime to sit on the bridge and wait for DBAs to fix the problem”.
If any of this sounds familiar, chances are you are working in an organization that has yet to define and communicate the impacts of adopting agile technical practices using business metrics. While technical metrics such as code complexity, test coverage, defect density, build failure rate, crash rate and many more are useful metrics to measure technical improvements by adopting agile technical practices, simply reporting these metrics to management and leadership does not adequately convey the true business value of agile technical practices.
The true business value of agile technical practices is best communicated when agile technical metrics are linked to business metrics such as mean time to resolution (MTTR), conversion rate per session or increased customer engagement / activity.
In this interactive workshop, participants will explore how to improve measuring the business impact of agile technical practices by working in small groups to first identify & prioritize technical metrics for specific technical scenarios. Participants will then be challenged to link technical metrics to business metrics to convey business impacts supported by increased adoption of agile technical practices.
- Participants will review the most common technical metrics used to measure the technical improvements achieved by adopting agile technical practices.
- Participants will review recommended business metrics that are commonly used to demonstrate the true business value of adopting agile technical practices.
- Participants will experience a collaboration framework that guides the selection of both technical and business metrics to assess the technical improvement and business impacts of addressing a specific technical challenge.
- Participants will gain insights on how to measure the technical & business impacts of specific scenarios by working through a specific scenario themselves, and then having an opportunity to see what metrics other groups selected to measure other scenarios.
Achieving Agility w/ APIs at Chick-fil-A
Brian Chambers
View Full Abstract
At Chick-fil-A, we are laser-focused on scaling our technology infrastructure and processes while maintaining a high degree of business agility so that we can take advantage of unexpected opportunities. This is being done in our “real world”: the non-pristine environment of a busy, high-functioning enterprise scattered with both modern and legacy systems.
In this session, you will learn about Chick-fil-A’s API strategy and how it is being employed to create business agility.First, you will hear about what Chick-fil-A is doing with APIs across functional teams, engineering teams, and everything in between. You will learn more about our “why”, which will likely parallel your own. Then we’ll dive into the details about how we have approached the problem technically and organizationally. When you walk out the door you will have a complete understanding of our approach, and will be ready to build your own.
Learning Outcomes:
- I want to prepare the audience to sell and execute on a strategy similiar to ours that will enable their business to be ready to scale and take advantage of unexpected opportunities as they arise.
The Ultimate Metric
Janelle Klein
View Full Abstract
Since the dawn of software development, we’ve struggled with a huge disconnect between the management world and the engineering world. We try to explain our problems in terms of “technical debt”, but somehow the message seems to get lost in translation, and we drive our projects into the ground, over and over again.
What if we could detect the earliest indicators of a project going off the rails, and had data to convince management to take action? What if we could bridge this communication gap once and for all?
In this session, we’ll focus on a key paradigm shift for how we can measure the human factors in software development, and translate the “friction” we experience into explicit risk models for project decision-making.
Learning Outcomes:
- Attendees will learn see the challenges of software development through a new paradigm, with new strategies for keeping a project off the rails.
Deep Stack - Tracer Bullets from ADC to Browser
James Grenning
View Full Abstract
A blank page can be very intimidating, even for a Test-driven developer. What if you don’t know what your code needs to do? I used to make a flippant reply to that. Now I totally get it as I tried to discover what works at the boundaries between:
- Analog to digital converter (ADC)
- Serial peripheral interface (SPI)
- Micro-controller
- IoT radio
- IoT mesh network
- Little Linux box
- Flask web-server
- JSON and javascript driven browser.
Filling the page with all the technical choices, never encountered before, calls for a risk reducing approach. In TDD, we often defer complexity to get some of the simpler behaviors in place. This approach (I call it TDD guided by ZOMBIES) is appropriate when we’re dealing with simply-a-matter-of-software. We build on simpler behaviors, helping gain insight to what has been deferred.
In a multi-layered hardware/software/COTS new product development effort, we need to understand the options and evaluate technology solutions. We better confront unknowns head-on at the component boundaries with the goal of turning the problem into simply-a-matter-of-software. There are more risks than strictly technical risks. Business risk assessment will impact technical choices. If we can build it, will it be affordable and profitable? Will anyone buy it?
In this talk we’ll look at the technology risks of a distributed real-time measurement system, firing tracer bullets through the problem and solution to discover how to invent this product.
Learning Outcomes:
- The role of spike stories during prototyping
- Discover-isolate-expand-refine
All Hands On Deck: Rallying Teams Around Test Plans
Ash Coleman
View Full Abstract
Imagine you have a grand piano in your living room. Now imagine you are moving homes and you would like to take your beloved piano with you. What is the first thing you would do? Jump straight to the task? Start pushing it along, attempting to advance it as far as you can?
Well if you are smart, the idea of moving a piano by yourself, or perhaps with yourself and one other person alone, should leave you thinking twice about your logic. The weight of the piano is grand, no pun intended, but also the shape is rather awkward. This doesn’t make the task for any one or two people very easy. In fact, you would likely begin to least think about what reinforcements you could call in to assist. Extra hands could definitely (1) lighten the burden, (2) distribute efforts across the all the awkward areas of the piano, and (3) move it more efficiently.
So the real question I now have is, why do we not address carrying the weight of quality in a similar manner?? It is definitely a huge job, way bigger than any one person can handle alone. It is incredibly awkward, considering how many areas of expertise you would have to master in order to be the most precise at your job. And, the time it takes to execute testing is usually infinite. So why would a tester take on all of the testing by themselves?!
They shouldn’t! And with proper planning, don’t have to.
A tester can address testing understanding that the quality of the product they are working on is not entirely up to them, the work is far reaching, and can be executed with more efficiency when more people are involved. The way they do is by curating a detailed test plans – an interactive, self organizing process where experience and collaboration govern the team’s ability to deliver in the most effective way.
In this workshop we will work together to come up with the master plan! Together we will:
Define Roles and Responsibilities,
Decide on Test Approaches,
Outline Scope,
Create a Text Matrix, and
Configure a Reporting Guidelines
With our time, we will call all hands on deck to work through a test plan, distributing the weight of quality, working together to produce better, stronger plans for our products.
This is a workshop for all members of a team. A chance to work together to understand testing at a planning and execution level.
Learning Outcomes:
- Executing a Test Plan
- Delegating Responsibilities
- Configuring and Outlining Scope
- Importance of Test Matrices
Agile Machine Learning, In Production
Kishau Rogers
View Full Abstract
The future of software is being driven by intelligent applications. By the year 2020, more than 85% of customer-to-business interactions will be carried out without humans (Gartner). 81% of IT leaders are already investing or plan to invest in artificial technology solutions.
Time Study is a startup on a mission to eliminate timesheets using machine learning, mobile technology, and data science. In regards to rapid development, rapid response feedback loops, and continuous improvement, ML projects are well suited for Agile methodologies. However, there are some considerations for successfully using AI and machine learning for agile development, such as:
- Sprint Planning – Breakdown and define agile experiments to support rapid iteration and deliver incremental value.
- Rapid Iteration – Create data-driven feedback loops for research and production environments
- Agile Team Roles – Expand development team roles to include engineers, data scientists as well as Subject Matter Experts
In this session, we will discuss best practices for successfully integrating agile development cycles with machine learning workflows.
Learning Outcomes:
- Best practices for successfully integrating agile development cycles with machine learning workflows, including considerations for:
- Sprint Planning – Breakdown and define agile experiments to support rapid iteration and deliver incremental value.
- Rapid Iteration – Create data-driven feedback loops for research and production environments
- Agile Team Roles – Expand development team roles to include engineers, data scientists as well as Subject Matter Experts
Dev and Test Agility for your Database with Docker
Julie Lerman
View Full Abstract
Agile practices teach us how to deal with evolving applications but so often the data store is overlooked as a component of your application lifecycle. Database servers are monolothic, resource intensive and mostly viewed as set in stone. Encapsulating your database server in a container and your database in a storage container can dramatically lighten the load and make your database as agile as your model and other processes. And you can even use a serious enterprise class database like SQL Server this way. This session will show how to benefit from using a containerized version of SQL Server for Linux during development and testing. We’ll also address concerns about data that needs to be persisted. You’ll also get a peek at the DevOps side of this, including using images in your CI/CD process.
Learning Outcomes:
- Running SQL Server for Linux in docker in development environment
- Script tests to spin up a running instance of SQL Server for test and then eliminate from memory
- Comprehend life cycle of moving database/data into production and then back to dev/test for realistic testing
Delivery Pipelines as a First Class Citizen
Cora Iberkleid
View Full Abstract
Software delivery is a key capability that is often treated as an afterthought, resulting in a rigid, fragile, and inefficient process that is difficult to maintain and evolve and that can even limit developer agility. In this talk, we will explore the burgeoning topics of delivery as code, distributed ownership of jobs/stages, and the importance of testing the pipeline itself. These practices aim to make pipelines easier to create and manage over time and at scale. We will also cover best practices to incorporate into our delivery pipelines so that developers can change and test applications more frequently and effectively, positioning us to produce better software faster.
Learning Outcomes:
- An appreciation for the value that some key best practices can provide for developer agility.
- An understanding of the recent hot topic of software defined delivery, and some of the nuances in different approaches.
Safeguarding - Using Your Bugs to Prevent Bugs and Fund Technical Debt Fixes
Arlo Belshee
View Full Abstract
Do you have that piece of code that grows bugs every time you try to change it? Yet, do you find it difficult to fund a repair? Fixing it will take a project, and that one just never makes it to the top of the queue. Or do you spend a lot of time finding others’ bugs? Or do others around you always take the safe path, even when there’s a better option? Do you get interrupted every sprint by a couple bugs, and so miss the sprint goal?
Safeguarding addresses all of these and more.
Safeguarding is a simple, 22-minute practice that allows you to find, fund, and then execute real changes to your process and product. Fix technical debt this sprint. And next sprint. And the one after. Without slipping features. Fix process debt. Fix psychological safety issues.
In this workshop, you will safeguard a real problem that you are experiencing right now. You’ll learn how to facilitate yourself and your team through safeguarding. And you’ll learn how to sell this practice to your product owners and managers.
My goal is simple: I want you to go home after the conference and start actually fixing technical debt, start actually preventing bugs. By this time next year, I want you to have less than 5% of your current number of bugs.
Learning Outcomes:
- Can define good remediations, on the basis of a bug, to prevent future bugs.
- Understand hazards and know how to look for them.
- Understand when to safeguard to get the best results.
- Ready to start safeguarding when they get home
Breaking the Monolith: Simplifying complex systems by working backwards to deliver results
Rick Garibay
View Full Abstract
If you’re a software developer, chances are you like to innovate. But how often do you really start with a greenfield project?
More often than not, innovation requires either deprecating and/or simplifying/improving existing software to deliver something better or different than what customers were satisfied with before.
Everyone’s encountered that dreadful moment when your project requires you to make a change to an existing piece of code. If you’re lucky, you have unit tests that fire green before you make the change. But what do you do when you are not so lucky? Taking it one step further, imagine you’ve been asked to deprecate one or more components in a highly distributed system that’s used by thousands/millions of customers? Maybe you’re a domain expert in the system or have limited to no domain expertise. Where do you start? What replaces the existing component(s) and how do you ensure you don’t break customers as you replace the old thing with the new?
In this talk, Rick G. Garibay, Principal Engineer @ Amazon will share patterns and techniques he’s developed over the last 18 years for embracing change while reducing technical debt. You’ll learn proven techniques for deprecating and simplifying existing software while working backwards from your customers to deliver results.
Learning Outcomes:
- Learn how to determine the complexity of the domain that you are operating and corresponding constraints to guide your architecture and detailed design and build the right feedback loops to learn quickly and fail fast.
- Learn techniques for identifying existing business capabilities and rationalizing how to factor, deprecate or redistribute concerns within your domain incrementally.
- Learn real-world patterns and techniques for working more effectively with legacy code including code reading and refactoring techniques, identifying and extracting functional seams for separating concerns and establishing release practices that allow you to test changes in isolation (and yes, sometimes even in production).
A Parable of Mapping through Pivots and Transitions
Jabe Bloom
View Full Abstract
This the story of a team of teams. A team of teams with a manager who reads on planes.
Having come back from a recent conference, our fearless manager has defined a significant pivot in strategy, and has challenged our friendly team of teams to achieve a new vision for the business.
How will our teams come to understand this strategy?
Come, listen to the tale of a team of teams, using Wardley mapping to navigate through the practical, architectural and organization issues they face implementing a disruptive change.
Take away a better understanding of the practical applications of Wardley Mapping to informing technical and organizational transitions.
Learning Outcomes:
- How to READ a Wardley Map
- How to work with teams and management with a Wardley Map
- How to understand and plan for cost of change issues
- How to dynamically team through pivots and transitions
Crack Open Innovation with Customer Journeys
April Jefferson
View Full Abstract
Discover insights that can be transformed into opportunities ripe for innovation with our Customer Journey Mapping workshop. When user’s often desire seamless experiences across mobile, online and offline platforms, mapping with empathy can help you understand and maximize effectiveness of every touch-point. You will see the big picture holistically and learn how to tell the story of common pain points along the journey and harness the power of visually storytelling the customer experience.
Learning Outcomes:
- When to use the tool, who to engage, and how to make it a living document as your product evolves
- To discover what is customer visible value
- To empathize with your user, understanding how they experience your product or service
- To find opportunities to better engage with your customers by identifying the gap between the current and desired experience
- To prioritize at high level based on the greatest value delivered
Playing for the Future: How Games, Cadence, and Chaos help us adapt to our changing world
Chris Donnelly
View Full Abstract
Volatile, uncertain, complex, and ambiguous (VUCA) describes our world more accurately each day.
These traits lead to a rapidly growing set of diverse problems across technical value networks. To stay afloat, decision makers, technical leaders, and influential individual contributors must acquire approaches apace.
We will explore play as a time-effective way to cultivate a diverse cognitive-toolkit for tackling the challenges of tomorrow across technical disciplines eg architecture, engineering, operations, UX, etc.
Through games and play (backed by research), we will discover:
- Why not knowing is a superpower
- What defusing bombs has to do with service downtime
- The commonalities between spies and engineers
- What cybernetics says about training in a rapidly moving domain
- Why katas are the most powerful force in the universe
- How balancing victory points and your economy can boost employee satisfaction
Learning Outcomes:
- Use play to collaborate and problem solve across technical disciplines
- Employ modern strategies for effective learning
- Understand the difference between training and education, comfort and safety, and repeating and repetitive
- Have more fun at work while creating value!
Ten reasons BDD won’t save your development process (plus a couple of ways it might help)
Steve Tooke
View Full Abstract
You’d think, as an owner of Cucumber Ltd, I would be shouting from the hilltops about how Behaviour Driven Development can save your development process, right?
Actually no.
There are no silver bullets, and BDD is no exception – it is at its best when used as part of a broad set of practices within a particular culture.
Using anonymized examples from the real world, we will look at ten anti-patterns where BDD on it’s own almost certainly won’t save the day.
We will also take a look at some of the surprising ways BDD – and in particular Example mapping – CAN help, especially from a social and cognitive perspective.
Learning Outcomes:
- You will understand the symbiotic relationship BDD has with other development practices
- You will begin to identify when using BDD might not be the first thing to look at
- You will be able to list some common impediments to using BDD
- You will begin to see some of the reasons BDD – and in particular Example Mapping – might help with cognitive load and collaboration
Ghost in the Machine: The Real Consequences of Bias in AI
Nivia Henry
View Full Abstract
What if the code you’ve written excluded 25% of its users? Or what if it caused a group of people real-life harm? If you’re a responsible engineer, these should be one of your biggest fears.
Artificial Intelligence and Machine Learning has introduced a new paradigm wherein code can actual do harm outside of its contained environment. While some of effects may be comically embarrassing – like a smart speaker not accounting for the US’ southern accents; others can be deeply unfair to large groups of your users.
Come with Nivia – an engineering manager at Spotify; and Andre – a polymath and Sr engineer at Venmo – on a journey to explore the world of machine learning. We’ll explore how algorithms are created, trained and implemented; and more importantly, discuss practical steps to detect, mitigate and eliminate algorithmic biases.
Learning Outcomes:
- At the end of this session, the participant will be able to:
- Understand the difference between Artificial Intelligence and Machine Learning (ML)
- Understand the types of ML algorithms and their values
- Understand the ways in which bias is introduced in the creation process
- Have a sense of the consequences of these biases
- Have practical means of preventing, mitigating and eliminating such biases
Do Programming Languages have Personalities?
Rob Myers
View Full Abstract
In his long journey from FORTRAN to Ruby, Rob has encountered many programming languages. Having written the same code in many languages for his technical classes, he may be uniquely positioned to see their similarities and differences; their unique strengths and weaknesses. But he has rarely chosen a favorite or succumbed to the thrill of “language wars.” Instead, he’s found unique and interesting innovations, and at least a few things to appreciate, in each language. Whether you’re considering picking up a new language, or trying to rekindle your love for Java, you’ll explore some interesting details, comparisons, and history of many programming languages in common use today. Such as the original intent of the Java interface keyword, the C# internal keyword, multiple inheritance in C++…and in Ruby. The promise of Java, and of the .Net languages. The advantages of strong types and compilers. The advantages of duck typing and no compilers (Ruby, JavaScript). And rather than try to answer “When would I choose one over the other?” we’ll instead explore ways to learn a new language, and not just its syntax, but its personality: what are its strengths, and weaknesses? Instead of “Is this my new favorite?” you’ll be able to ask “Will we get along? Will we be able to work together to get stuff done?”
Learning Outcomes:
- Appreciation for all the languages in common use today. The ability to tolerate an older or “less fun” language by working with it in the best way possible.
Ready Tester One? Go!
Melissa Eaden
View Full Abstract
Based on my blog post, “Ready Tester One? Go!” I take a look at my own career development and the need to understand a probable career development path for testers in software development. By using and identifying with gaming techniques such as “leveling”, testers are encouraged to find where they think they are in their career growth and then find out how they should continue along the “tester” path and what that might look like as you gain levels. Includes a nifty character sheet people can use to chart their own learning path!
Purpose of Talk:
Most companies lack an outline of career growth and development for testers. They expect testers to find their own way or move either into development or project management. The industry needs testers, but doesn’t understand how to help. This talk seeks to lay a foundation or a framework for testers to measure career growth and have a general path for development.
Learning Outcomes:
- Desire to set a learning path for their career growth
- Interested in games and gaming and want to look for ways to enjoy both
- Creating a character sheet out of personal resume
- Tips on how to learn new skills
- Tips on looking for opportunities to learn skills
Free As In Puppies: Toward a better build vs. buy understanding
Heidi Waterhouse
View Full Abstract
A free puppy, like a white elephant, is a gift that takes a lot of time, energy, and money. When we build an internal tool ourselves, we don’t have to justify it to the financial department the same way, but the lack of a bill doesn’t make something free.
The FLOSS community talks about freedom as an intellectual property right. The digital generation assumes that software without a charge is selling their information. Let’s talk about the other kind of free – the kind where you are just not clear on how much you’re paying for something, because it’s an internal tool.
When we make a build vs. buy calculation, it’s easy to miss several important parts of the calculation, including maintenance, updating, security, availability, and finding operators. None of those are easy to articulate or value for either side.
To help argue a decision for cultural change and/or spending money on tools, I’ll walk you through several examples and talk about how business value is more than money. You’ll leave with a set of questions to ask about quality, cost, and long-term use.
Learning Outcomes:
- The audience will leave with new tools to evaluate their tool spending and new ways to think about the cost of things that we build accidentally, along the way.
No Return: Moving beyond transactions in software and in life
Avdi Grimm
View Full Abstract
After 20 years building a successful software development career, my life fell apart. Deconstructing how it happened revealed surprising parallels between how I had approached building a career and family, and how I had designed software. At the root of all I found a pervasive misconception I’ve come to call the “transactional fallacy”: the tensomethingdency to perceive and model processes as if they are transactions.
Join me for an honest, sometimes raw reflection on two decades of software development and life. We’ll examine how personal philosophy impacts software design—and vice-versa. We’ll encounter the Transactional Fallacy, and how it can hinder our attempts to build resilient systems. And we’ll explore how a graceful, process-oriented mindset can lead to both better code and a more joyful life.
Everyday Beliefs Come True: Creating Greatness through the Stories We TellOvercoming dys-functional programming. Leverage & transcend years of OO know-how with FP
Declan Whelan & Shawn Button
View Full Abstract
Interest in Functional Programming has exploded in recent years. If you are an experienced OO developer, your design techniques and coding practices can easily get in the way of FP success.I t certainly did for us! Fortunately, there are way to leverage what you already know.
Join Declan and Shawn in this interactive session. Explore the joys and challenges of moving from Object Oriented programming to Functional Programming.
Learning Outcomes:
- principles and practices that work with both FP and OO
- learning path to becoming a better FP developer
- things to watch out for as an OO developer when applying FP
- refactoring techniques to move OO code to an FP style
The Agile Gap: Technical Practice, or, XP As We Would Do It Today
Ron Jefferies & Chet Hendrickson
View Full Abstract
The uptake of “Agile” methods has reduced focus on the practices and approaches that are needed to get the full benefit of the approach.
Read: Agile’s not working as well as it could.
Often, development teams are not equipped to perform well in an “Agile” situation with the result that the teams, and the results, suffer.
Read: Agile often hurts developers.
Organizations push for results, and are not investing in the requisite training, or providing the needed slack for teams to learn to perform well.
Read: Pressure crushes progress.
We’ll discuss what developers can do, and what the “Agile Industry” needs to do, to improve the lives of development team members.
Read: We’ve got some ideas. XP is in there.
Learning Outcomes:
- We hope to inspire developers to focus on their own responsibilities, and to encourage their organizations to support effective Agile development.
- Renewed focus on delivering shippable “Product Increments”.
- Ideas on using the Increment to improve our lives.
- We’ll describe what we and others are doing to influence the “Agile Industry” to address this problem.
Kube Your Enthusiasm
Paul Czarkowski & Tyler Britten
View Full Abstract
Part talk, part demo, part live coding. Paul and Tyler from Pivotal will take the audience through the basics of Kubernetes and then turn to the audience to go down a Kube Your Own Adventure exploration of a number of different Kubernetes related topics.
Strangle Your Legacy Code
Amitai Schleier & Markus Silpala
View Full Abstract
Given an ancient codebase that makes refactoring risky and expensive, how do you clear a path to continued delivery? The old wisdom says the best time to plant a tree was 20 years ago, and the next best time is today. But if you already have a gnarled old source tree, preserve your software investment by planting a Strangler: a pattern for reaping continuous value from your existing system while growing new functionality alongside it.
We’ll take a quick look at a Strangler, demonstrate the basics of Mob Programming, then split into small groups to test-drive new features into the system. You’ll leave with a powerful strategy for extending the useful life of working, valuable software — especially when it’s hard to change — and with a free bonus development practice to accelerate your team’s learning. For a limited time only!