deliver:Agile 2019

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

View bio

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

View bio

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.

View Bio

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

View Bio

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.

View Bio

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.

View Bio

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.

View Bio

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

View Bio

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

View Bio

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?

View Bio

James Shore

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

View Bio

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.

View Bio

Using Focus to Defeat CDD: Chaos-Driven Delivery

Julia Wester

View Full Abstract

The odds are high that you've heard of BDD and TDD. Well, many teams struggle with the lesser-known CDD: Chaos-Driven Delivery. CDD teams struggle with a constant onslaught of overwhelming amounts of work and a sever lack of focus. It is easy to lose hope after the millionth time of hearing that crazy is the new normal. You mean it's never going to get better? Some teams visualize their work to bring visibility into just how crazy things are. That can bring immediate relief, but it's only the first step of a much longer journey if you want to tame the chaos.

This workshop guides you deeper into your journey to tame the chaos by discovering what it means to optimize for focus without sacrificing the need for responsiveness - two extremes that continually demand an appropriate balance. Whether you're flailing due to working on too many things at once, unnecessary interruptions or the "hurry up and wait" of dependencies, you're not alone. Together we'll talk about tactics for reclaiming your lost focus. More importantly, you'll learn how to navigate the spectrum between focus and responsiveness needs by identifying the positives and negatives of optimizing for either extreme, early warning signs for veering into danger, and how to decide what steps to take. This method of thinking about polarities and the spectrum between can be reused for many other challenges you face.

For some people, workshops can be terrifying. I invite everyone to take part at the level you’re comfortable with. Both quiet observation and excited hands-on participation are completely acceptable. Attend this workshop and learn how to help your team kick CDD to the curb!

Learning Outcomes:

  • Understand the business benefit of both focus and responsiveness
  • Strategies for implementing focus of different types and levels.
  • Introduction to the concept of polarities and polarity management.
  • Technique for deciding how to operate on a spectrum between two seemingly opposing extremes.
  • Repeatable activities to bring these concepts back to the team.

View Bio

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)

View Bio

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.

View Bio

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

View Bio

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.

View Bio

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.

View Bio

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.

View Bio

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.

View Bio

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.

View Bio

martin-hinshelwood300x300

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.

View Bio

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

View Bio 

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.

View Bio

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.

 

View Bio

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.

View Bio 

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.

View Bio

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

View Bio

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

View Bio

kishau300

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:

  1. Sprint Planning - Breakdown and define agile experiments to support rapid iteration and deliver incremental value.
  2. Rapid Iteration - Create data-driven feedback loops for research and production environments
  3. 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

View Bio

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

View Bio 

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.

View Bio 

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

View Bio

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).

View Bio

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

View Bio 

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

View Bio

Title

Name

View Full Abstract

Full text and BIO LINK

 

See Bio Here

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

View Declan's Bio

View Shawn's Bio

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.

View Chet's Bio

View Ron's Bio

MORE COMING SOON ...