Oh! The *Humanity*

Is that framework your team uses really… working?

Something is wrong in The Agile Space™. Installing an Agile process rarely works, and there’s a reason for that that no one is talking about.

So let’s talk about it. Let’s talk about industrialism, real agility, and humanity. And let’s see if we can agree on the problem before we dive head-first into solutions.

Feedback:

"I saw this session and thought it was excellent. I'm so happy you posted [to YouTube] it so I can show my friends."

"The perfect message to me at the perfect time, thank you! I hope you don't mind me sharing the link, more people need to see this."

Ask Better Questions

Software is a game of insight. And insight comes from your team and its conversations.

But meetings are terrible, and not all conversations are created equal. Some are way more insightful than others. And when they are, it's usually because someone asked a better question.

Inside of a few minutes, I will show you ONE WEIRD TRICK to upgrade your human query syntax from puny and halting to open and POWERFUL. With your newfound superpower, you and your team can tap into its collective genius, and take your work to the next level.

You may even learn to look forward to meetings again.

How to go fast in software without really trying (and other stories from the backlog)

“I just don’t know what else I can do, man. I’ve tried everything.”

Roger had my attention. The only emotion he'd shown me before now was *I’ve got this, I don’t need your help*. The development team he led just would not deliver fast enough. And, at first glance, it did look like he had tried everything in his power as their manager.

But before long, Roger's team became known for their quickness, all but erasing their old reputation.

Wait, what happened? Come hang with me for an hour, I'll tell you all about it.

Software is a game of insight. And stories are the best way we have to share our insights with each other. By sharing them, we elevate our work, our industry, and our lives as software professionals.

I've got stories to tell you about the teams I've worked with. You'll see yourself and your team in theirs. You'll ride the ups and downs with them from the safety of your chair. You'll walk away with the lessons they lived. And you'll probably realize how many stories you have to tell, too.

Feedback from attendees:

"Jon's approach to teaching is amazing."

"Interesting twist. Loved the stories to make a point."

"Good advice on how to handle difficult situations and use stories to help describe things. Especially liked the example on asking 'why'."

"I'm learning to pay attention to the details of my story, and trying to find ways to tell it so others can learn safely from my experience. Great timing on your encouraging talk. Thanks Jon!"

"Getting to know your team is important. Thanks for thinking about what stories I can share."

"Engaging!"

"Thanks for making me want to practice the habit of finding stories AND telling them."

"Your stories were funny and your messages were awesome."

"This was amazing. I can’t think of anything you could have done to make it better."

"Some (most) people do not like to be wrong, so instead you tell them a story through which they can come to the same conclusion as you but from their own mind instead of your words. Nice job today!"

"Great!! I really enjoyed the focus on mobbing and talking through things. While I don’t have a large view into how a lot of [our company's] teams work, i hope it helps shift my teams way of thinking 🤔"

Make TDD Make Sense: Cheaper Changes through Better Boundaries

Test-Driven Development is not a way to test—it's a way to code. A way that helps you write clear code that stays clear. And clearer code is cheaper to change.

But TDD doesn't come naturally. It's almost impossible to adopt before the right architectural boundaries are in place. Boundaries that your code probably doesn't have yet.

In this session, I'll show you how to draw the hard lines in your code that keep your software soft. I'll test-drive changes in a real app—no boring toy examples here. I'll be coding live (mistakes and all), so you can see what it’s really like to work this way. And we'll cover important concepts like:

+ TDD in the age of AI-assisted programming
+ Why TDD adoption is not what it should be
+ The real relationship between TDD and good design

Boundaries, people! Let's make TDD make sense, and make our changes cheaper.

Can AI generate unit tests for your code? That’s the wrong question.

There's nothing quite like a suite of fast, sturdy unit tests. They stabilize your codebase, make it safe to change, and enable real software agility.

But your app is already behind schedule—who has the time to write tests? Wait, can ChatGPT do that for you?

Hold it right there.

AI tools like ChatGPT and Copilot are powerful. And they will end up speeding up this whole software engineering thing in ways we can’t even dream of right now. But, like with any power tool, we don’t want to grab them from the wrong end.

I mean, should we have the robots generate the tests for the code we write? Should we write the tests and have the robots generate the code that makes them pass? Or should we just go home and let Skynet happen?

In this session, we will talk about:
- code,
- the code that tests that code, and
- who should be generating what when our new robot overlords finally take over.

The Everyday Magic of Ensemble Working

“All the brilliant minds working together on the same thing, at the same time, in the same space, and at the same computer.”

"For an idea to go from your head into the computer it MUST go through someone else's hands."

We used to call this Mob Programming. But it’s not just for programming anymore! This hyper-collaborative approach will elevate any knowledge work task you do.

Ensemble working takes some getting used to. But once you adjust, you'll see fewer wasteful handoffs and delays. You and your coworkers will feel more connected. And you'll produce higher quality work.

Come learn this new way of working, for whatever kind of work you do. You'll see what actually makes a team productive. You'll hear stories and examples from teams I've worked with over the years. And you'll even get some hands-on practice, so you can bring it back to your own team with confidence.

"Some of the most clever insights of the day, thank you!"

"Great interactive session!"

"I learned something new today and will try to apply this in my organization."

"Nice overview of the practice and the concepts underlying it. The exercise might have been the best part."

"I really like this model. I will definitely put this to use."

"Thank you for educating us about mob programming. Definitely worth a try with my teams."

STUCKness: Zen and the Art of Software Development

> Stuck. No answer. Honked. Kaput. It's a miserable experience emotionally. You're losing time. You're incompetent. You don't know what you're doing. You should be ashamed of yourself. You should take the machine to a real mechanic who knows how to figure these things out.

-- Robert Pirsig, *Zen and the Art of Motorcycle Maintenance*

Pirsig makes zero mention of software in his book. Yet he narrates the development experience tangibly--tell me you’ve never felt this way before.

Let's talk about why we get **stuck**, how it cows us into feeling like imposters, and what we can do to dispatch it more effectively (even to use it to our advantage) and make great software fast anyway.

Feedback from attendees:

"Jon painted a great piece of art. I loved the slides, I loved the content... I loved how it made me think differently."

"This talk made me rethink what I am and what I want to do."

"I've got a new perspective and renewed vigor on my forever journey."

"You're obviously a very talented speaker."

"Always a great speaker! Did a great job keeping us engaged even after lunch, usually a tough spot."

"Make him a permanent speaker every year. Seriously."

"Mindblowing. I wasn't sure what to expect, but it did offer a different perspective."

"I really enjoyed this - I am not a developer but work with developer. What you teach applies to everyone."

"Off the wall way to clearly say what I have experienced as a developer. I can use this for my developers on scrum team."

We Don't Type for a Living: Plural Programming Practices for Productivity and Profit

"Why would I pay twice as much for two developers to do one thing? Get back to your desks!"

Pair programming is a preposterous idea. Until you see it work, and then it's not. In fact, pairing and mobbing are transformative techniques for building great software, and for building teams that build great software. And yes, Virginia, for going faster.

But we only get to cash in on that when we do it right.

So let's talk plural programming—I've been at it for years, and I'm in the mood to share. We'll turn over some pairing myths with data. We'll talk about how you don't need your boss's permission to do it. And we'll cover the pairing anti-patterns that can ruin it for everyone.