Allison Pollard

Transforming, Not Transformations

As agilists, how are we affected by our relationships with transforming organizations? Organizations treat an agile transformation as a singular event. A budgetary line item, a noun, a one-time metamorphosis from caterpillar to butterfly. The danger is that we expect people to transform in a particular way or on a schedule.

We believe organizations benefit when we transform the way we assist organizations. In this interactive workshop, Allison and Barry will facilitate discussion on experiences with transformations and what might happen within an organization if we more actively transform ourselves.

Join us as we explore who and what is transforming through agile transformations.

Andy Singleton

An architectural approach to web services and continuous delivery

The megatrend move to cloud, Web services, and continuous delivery is impacting every agile team. We will start by seeing how Amazon, Google, Microsoft, and Facebook weave these ingredients into a Matrix of Services that has created more than $3T in market value. Their tactics are quite different from the tactics applied in a Scrum-based agile transformation. They use tech leads instead of scrum masters, product managers and outcome metrics instead of product owners. Each team and service can support a matrix of different products, avoiding the silos of SAFE programs. We’ll look at basic continuous delivery tactics, and see how tools have a bigger impact than teamwork, and how they work better at large scale. We can wrap up the session with testimonials from people who are working in the new model, and have a debate on the role of teamwork in this mechanical system. Everyone should leave the session with some new ideas to try.

Andy Van Fleet

Useful, Usable and Desirable

UX is not about making things pretty. It’s about designing products that work. Products that work are typically useful, usable and desirable. In this talk, we’ll focus on the UX process and how to make products that; correctly solve the problem, work well for end-users and are elegantly designed. {take away = an in-depth view of the UX process}

Barry Forrest

Brewing Great Agile Team Dynamics: No More "Bitter Beer Face" Communications

Ever find yourself making a sour face after talking to a coworker? Wishing your team meetings felt more like an engaging social hour? There is hope. Those everyday conflicts where something seems “off” after a conversation are often related to differences in communication styles. 

When team members understand themselves and others, there’s less conflict, more collaboration, and better working relationships. The DiSC model can help you understand why your team behaves the way it does and how to build trust for a more agile team. 

In this interactive session, agile coaches Allison Pollard and Barry Forrest will introduce the DiSC model to explain the four behavior types that are the ingredients in any team, then explore the characteristics of these ingredients and how they react with one another. Join them to learn about the behavior styles of you and your team using DiSC, how to communicate better together, and increase trust in the team. You'll leave with a common language that your team can use to better understand themselves and adapt their behaviors with others.

Brandon Carlson

Dude, Where’s My Law?

Over the years more and more people have adopted Agile processes and practices to achieve better outcomes for their organizations. As with anything that goes from relative obscurity into the mainstream, many of the driving principles behind it tend to get lost in the shuffle. In response to this, one of our industry’s best, David Hussman, coined “Dude’s Law” to remind people of this drift away from the core principles behind the way we work. Join me at dsmAgile while we revisit Dude’s Law, touching on what it means today and what it can mean tomorrow.

Gianfranco Berardi

You're Not a Code Monkey, So Stop Acting Like One!

A lot of people think the job of a software developer is merely to write code, specifically code that they were told to write by their boss.

A lot of people are wrong.

Organizations don't need programmers, and they don't need code. What they need are problem identifiers and problem solvers. They need opportunity recognizers and realizers. And whether they know it or not (and to be fair, many do not), they need their software developers to act as full partners in making decisions and deciding strategy.

If you are a software developer, you have the opportunity and the responsibility to leverage your expertise and skills to help your organization see what is actually possible and accomplish it, to see alternatives that are cheaper, faster, or just plain better, whether you work in an exciting startup environment or sit in a beige cube in a sea of beige cubes.

You are responsible for not only creating value through technology but also for maintaining that capability, and you don't get to pretend that "they won't let me" is a valid excuse.

Merely slinging code is not enough. You are not a code monkey following orders. You are a first-class citizen in the organization, more than capable of driving value as well as delivering it. Let's discuss how you (and your organization) can start acting like it.

Jeff Byron

As a Des Moines Agile conference goer, I want to learn some of the basics so that I can apply them properly in my organization.

Whether you're just getting started or would like a refresher because things have gotten stale, this session will take it from the top. We will discuss agile as a mindset, tactics to try, and most importantly, the "why?" behind each one. This session will cover the importance of motivation, the framework of a sprint, and why people keep talking about lean manufacturing in Japan. Questions are welcome throughout and we may just see where the conversation takes us.

Josh Carson

(Technical) Demoes That Don't Suck

One of the key parts of successful agile development is making sure that feedback loops are setup. An extremely common practice is to establish demos to make sure teams can show progress and can guide on where to go next.

Demos, when done poorly, do not help teams improve. They become expensive status updates. They become a means to show untested code disguised as production quality experiences. They become a means to guilt and shame teams stuck with a difficult problem.

Two years ago, I did a presentation called Demos That Don't Suck. I recommended against giving technical demos. Many people are in environments where that is not possible.

This talk will go over what I have learned over the years of giving demos. This talk id for those of you having to get feedback on features like non-functional improvements, technical products like APIs and SDKs, or migration projects where you need to successfully show you did nothing to the customer experience.

Kent McDonald

How to build shared understanding with example mapping

One of the primary responsibilities of business analysts, product owners, and all other product people is to build and maintain a shared understanding of the outcome your team seeks to deliver. Conversations are an effective way to build that shared understanding.

You may find yourself wondering who should be included in those conversations, when do you have these conversations, what should you talk about, and how do you remember what you said?

Join Kent McDonald as he introduces example mapping, a technique that helps you structure your conversations and build a shared understanding.

You’ll learn how to determine the right people to include in your conversations, when the best time is to have those conversations, how to structure those conversations, and how to remember what you said.

Mindy Bohannon

Agile and Scrum at the Speed of Light

Cleveland’s GiveCamp is the most magical, tiring, and worthwhile 48 hours anyone will experience professionally. For example, in 2015, 200 techies volunteered their talents and passion to help 19 non-profits with projects including data collection, websites, GPS-enabled mobile app, an educational online game, and database applications. How does so much work get done in such little amount of time? Agile in hyperdrive – standups every 4 hours, adhoc swarming with heavy hitter devs roaming the projects, and lots of free food and drinks to keep everyone fortified.

This case study reviews how so much work gets done in such a short amount of time. Each GiveCamp weekend consists of 48 hours to developer, complete, and hand-off the sites or apps to the nonprofit to be self-sufficient in using and maintaining it thereafter. The organizations are prepped to have a Product Owner on site the entire weekend sitting right there with the techies on the team, ready to make decisions on the spot and keep development moving forward. If something isn’t working – the team can immediately pivot. A lot of intriguing functionality came from asking “it would be great if our site could…”. A scrummaster attends standup every 4 hours, teamwork reigns as everyone maps out the stories to accomplish the goal, and pairing and collaboration amongst everyone is key. It helps that the location, hyped up wifi, office supplies RedBull, coffee, ice cream, and all meals and beverages are donated by local companies to keep the teams going.

Nate Adams

Explaining Agile to your grandmother, your 5 year-old or your boss

A couple decades ago, when I started my life as a software developer, my grandma often tried to understand what it was that I did for a living so she could dote on me to her friends (as good Grandmothers are wont to do). Unfortunately, there were some big gaps in our shared context that made it hard for her to truly grasp how I spent my time on an average day. As I've started to spend less time writing code, and more time coaching and training teams in Agile practices and methodologies, I've found that my inability to explain what I do for a living has grown from effecting elderly relatives to just people in general. Interestingly, even as I speak to people who should understand, it often feels that we're speaking different languages or about completely different topics. Even when we use the same words, we're often not actually talking about the same thing.

This talk is about building bridges over gaps in our shared understanding. There are a lot of misrepresentations of Agile out in the wild today, and a lot of them in some pretty visible places. Let's clear these away and start fresh. More importantly, let's start simple, and talk about Agile concepts in ways that your grandmother, your kindergartner or even your boss can understand.

We'll cover some really simple, fun and engaging ways to talk about what this Agile thing is (and what it isn't). We'll talk about some myths and misconceptions that are out there and how to address them when we encounter them. We'll discuss how to talk about Agile concepts (even some complex ones) in the language the leaders of our businesses speak and understand so we can ensure that we're reaching a shared understanding while convincing them that these concepts are vital to success in today's successful industries. Most importantly, we'll have some fun while doing it.

With a little practice, you'll have them begging you to implement more!

Skylar Watson

Outcome Metrics Lead To Valuable Practices

Whereas output metrics (such as stories completed per week) measure aspects of a team’s localized productivity, outcome metrics (such as how much these features increase customer productivity) measure the difference the teams’ work makes in the world. Focus on output metrics can lead to increased waste and unnecessary stress, and distracts the organization from achieving more valuable outcomes. In this talk, through stories and group exercises, you’ll see how you can better measure and improve your organization’s effectiveness.

Learning Outcomes

• People can tell an outcome metric from an output metric (sparrow deck participation)
• Connecting the things that we do to the difference they make in the world (by drawing metric chains and then shortcutting them)
• People stop stressing about things that don’t make a difference (evidence in stories)

Tim Ottinger

Always Be Learning and Experimenting

George Dinwiddie once said that the biggest problem he sees in software teams is that people do not have enough time to learn. Knowledge workers who stop learning produce sub-optimal results and remain unproductive and frustrated. In this hour-long talk, Tim will

• help people understand the systems of learning-stop
• see how teams are building learning into their work
• learn a workable system for focused learning
• find resources to help teams learn and improve constantly.