Are you daunted by the prospect of introducing automated testing to a code base without it? Does your code base have automated unit tests, but no one has confidence about what the tests say about code? Consider approval tests to confront these challenges. Approval tests simplify assessing the behavior of a system by taking a snapshot of the results, and confirming that they have not changed. They are useful for both bootstrapping testing automation and for creating more expressive tests. In this session participants will join in hands on exercises using LEGO bricks that illustrate the concept of approval tests, and will share the results of a case study where the approach was used to improve software testing.

I often suggest to teams that they should be using all sorts of tools in their pipelines- from simple static analysis checks and automated builds to security scans and performance testing. I've done presentations and talks at conferences. I've lobbied to clients. I've commiserated with my colleagues. But I've never put together my dream pipeline in one of my own projects.

There are always reasons that some tests and tools get left out- our policies won't allow them, they will take too long to get approved, we don't have time, we have bigger problems to deal with, it just isn't what the client is looking for right now. And I usually think, if only I were in charge, I'd make sure we were using those...

In late 2017 I took over maintenance on an open-source project. Now I have no restrictions. The sky's the limit. No one is around to tell me what I can't do. So why don't I have my dream pipeline in place yet?

I'll talk about the trade-offs and compromises I made when building out the pipeline. Why I decided to focus on some tools and tests but skipped others, and what I need to do or change to make this delivery process the pipeline I've always dreamed about, now that I have no one else to blame.

When organizations move to agile for software delivery, there is often tension with traditional portfolio management. This talk will illustrate how an organization can move from traditional portfolio management approaches to one that embraces agile software delivery. Doing so enables organizations to become predictable, improve the flow of value delivered, and pivot more quickly if necessary.

We will demonstrate the use of governance that allows a more adaptive portfolio management approach. We will cover topics that enable agile portfolio management including:

• Lean techniques for managing flow
• Effective prioritization techniques
• Long range road-mapping
• Demand management and planning
• Progressively elaborated business cases
• Validation of outcomes
• Support for audit and compliance needs

These topics will be illustrated by real-world examples of portfolio management that have been proven over the last five years with a wide range of clients.

Picture a tiger in front of you at this very minute. A ferocious feline looking for its next prey. Chances are you'd bolt for the door without even thinking. Your body would flip its flight or fight response switch and in this case run for safety. This is called heuristics, mental shortcuts that help us make decisions without spending a lot of time.

Now, ferocious felines in offices are most likely unlikely (and potentially questionable --someone call PETA!), however high pressure situations are not uncommon in Agile Teams. Situations that at times unconsciously flips our flight or fight switch in our brains and lead us to jump into conclusions about our work, our colleagues and lead us to make poor decisions. This the brain suffering from cognitive biases.

This talk provides an introduction to cognitive biases and how they sneakily find their way in our teams and affect our team dynamics and productivity.

I'll cover 3 aspects of teams that could be impacted by these cognitive biases - team dynamics, communication and productivity.

I'll discuss the symptoms of these biases and show you how to proactively control and reduce its effects for more effective teams.

Many software developers (especially in larger organizations) are unhappy in their jobs. They are in a never-ending spiral of increasing code cruft, and their management does not allow them time to remediate technical debt or keep the code base clean. They feel helpless, beaten-down, defeated. They can't imagine that improvement is even possible. They respond to any suggestion to improve the status quo with comments like, "In an ideal world, maybe," "That will never work here," "You don't live in the Real World®," etc. They don't know their own power. This session is meant to show them that power.

The software delivery pipeline is the process of taking features from developers and getting them delivered to customers. The earliest tests should be the quickest and easiest to run, giving developers the fastest feedback. Successive rounds of testing should increase confidence that the code is a viable candidate for production and that more expensive tests—be it time, effort, cost—are justified. Manual testing should be performed toward the end of the pipeline, leaving computers to do as much work as possible before people get involved. Although it is tempting to arrange the delivery pipeline in phases (e.g., functional tests, then acceptance tests, then load and performance tests, then security tests), this can lead to problems progressing down the pipeline.

In this interactive workshop, we will discuss how to arrange your pipeline, automated or not, and so each round of tests provides just enough testing to give you confidence that the next set of tests is worth the investment. We'll explore how to get the right types of testing into your pipeline at the right points so that you can determine which builds are viable candidates for production.

Communication chaos under looming deadlines - sound familiar? We'll level up our teamwork, practice rapid learning, and identify ways to calm the chaos and focus on getting to done, all using Spaceteam, a chaotic and collaborative card game.

You'll work with your teammates to repair a failing spaceship before it falls into a black hole. in order to escape, you'll communicate problems, request help, assist colleagues and respond to constant change -- all in five minutes!

You'll learn from your failures, improve as a team, and gain insights into what helps organizations and teams collaborate effectively and achieve flow.

The concept of servant leadership is nothing new in the agile community. Servant leadership shifts the focus of leaders from managing teams to empowering and supporting teams. But as the world continues to evolve, are we really forming the connections we need to have truly high performing teams? Empathy forms the foundation of connections between individuals, teams, and organizations, and is the key to successful in supporting the needs of our customers and society. To have truly high performing teams, we need to move beyond servant leadership to a more empathetic leadership mindset. So how do we recognize, nurture, and grow empathy and grow from Servant Leadership to Empathetic Leadership?

This workshop will guide participants through several topics. We'll explore how empathy changes our thinking, how empathy and agile success relate, and how to build empathy within ourselves, our teams, and our organizations.

Maybe you are standing up a new agile team or are team member of a proposed team. You know that the team should sit together, but you suspect there is something more.

Or maybe you are on an existing agile team. You think your environment could be better, but you aren't exactly sure what matters most and certainly don't want to ask facilities to move things more than once or submit multiple procurement requests.

Or maybe you are still stuck in cubeville. You know you should talk to your teammates more often, but they are down the hall. You'd like to try pair programming, but the desk shape makes that hard. You really need to brainstorm and collaborate more as a whole team, but booking a conference room is a nightmare.

Camille will share recommendations on your environment setup, why they matter, the knowledge of how to justify the changes you want and how to make some trade offs when necessary.

Our Agile transformations can feel like Sisyphean efforts – but do not abandon hope! In this talk we will discuss nine circles of Agile Hell. Each hell is an example of a common problem programs encounter.

We'll ask the audience to prioritize their pain points, and focus on the six Agile hells closest to their experience. We will discuss real examples for “escaping” out of each Agile Hell - from Agile Coaches that the Dave(s) know.

By attending this event, Agilists will expand their toolbox of techniques to help their organizations.

Kotlin is a relatively young JVM language from JetBrains. Proponents are stoked about the improvements it offers over Java source syntax as well as its potential to target native object code as well as Java bytecodes. Kotlin has already gained traction for Android development, and is also an interesting choice for general application development in organizations that have a significant investment in Java tooling, libraries, and applications. How does Kotlin differ from other JVM languages, including Java, Clojure, and Scala? Is it a flash in the pan or a genuine advance that enhances the value of the Java platform?

The concepts of value, quality, and craft are frequently debated in the software community at large and the agile community in particular. Usually, they are debated separately. Does "value" refer strictly to the Lean idea of customer-defined value, or is the concept broader than that? Is it possible to deliver "value" with low quality? What does "quality" even mean? And can we achieve high quality or deliver good value if we don't apply skill to the work? Is that what "craft" means, or does it strictly refer to artisanal crafts? Maybe the lack of consensus stems from the fact we have been treating these as three separate topics, when in reality they are inseparable. Let's find out.

Specific organizational patterns are the villains of agile adoption, setting unreasonable expectations and sabotaging progress. We’ll explore these villains, and give real examples how federal organizations overcame them.

Participants will see the power of metaphor first embraced by Extreme Programming: a system metaphor or (for transformations) a cultural metaphor to name and avoid common anti-patterns in Agile adoptions.

Leaders in government programs or large organizations will recognize common challenges patterns: setting schedules by fiat, limiting the availability of product owners, balancing responding to emergencies with focusing on consistent prioritizes, just to name a few. Coaches and champions supporting Agile adoptions will be equipped with counter-examples to avoid these challenges.