conferences

My notes from conference sessions I have attended.

View the Project on GitHub jonfazzaro/conferences

Agile & Beyond 2022

May 24-45th, 2022
Detroit

Keynote: Deep Gamification: Designing Team Agency

with Jessica Kerr

When something is given a score, it narrows our vision of what we’re actually trying to accomplish.

“Striving Play”, when we are aiming for the victory condition

“Our best score is not the same as our best work.”

The usual tropes of gamification (badges!) are shallow. They are also not portable–a mechanic that makes one game can ruin another. “Copy the questions, not the answers”!

Games show that we can design agency.

A blocking Pull Request workflow creates competition. The goal of the reviewer is to not release software.

Counterintuitively, mobbing is less draining than pairing. It’s okay if your mind wanders a bit in an ensemble.

Symmathesy

“Are our rules helping up to add capabilities? Or are we just getting scared and adding more checkboxes?”

“Accidental gamification corrodes systems.”

Resources

Try Hack Me

EEP! Extreme Embedded Programming

with Clayton Dowling and Charlie Snider

(Mostly on the benefits of using TDD to develop embedded systems)

Using unit tests on embedded code isolates software vs. hardware problems (a common cause of debugging confusion when working with embedded systems).

As we learn about the hardware’s behavior, what we learn gets encoded into the mocks used in the tests. This creates a ratchet against regression.

For those working under regulation, tests passively create an automated trail of documenation.

Tests also provide insulation against supply chain problems, allowing developers to continue their work even when the hardware is not available for testing.

V&V (Software verification and validation) regulated mandated separation of coding/testing operations.

The Hunt for the Elusive Agile Architecture

with Doc Norton

“We don’t know what software architecture is–we just say stuff and call it architecture.”

Entropy! Regardless of the initial intended architecture, components slough across boundaries over time.

Microservice architectures are also monolithic–nothing deploys into a vacuum. The services grow more dependent on one another over time, despite attempts to keep them independent.

Successful architecture allows major decisions to be deferred. It is an aspect of the code itself, its boundaries.

Day 2 Keynote: How to Talk to the Elephant

with Linda Rising

Thinking Fast & Slow by Daniel Kahneman is “the most agile book in recent time”.

System 1: Fast, subconscious, right brain, the bulk of the iceberg, the elephant. System 2: Slow, linear, left brain, the tip of the iceberg, the rider. The more science learns about the brain, the more this part shrinks.

Use a Personal Touch. Understand the other person’s elephant and path, their environment and situation.

Direct the Rider to the bright spots! (Naive Realism: the mistaken belief we are rational and logical.)

Motivate the Elephant

Fear Less

Never talk to elephants of high-ranking people in groups. Meet 1/1, "whisper in the general's ear".

This doesn’t just apply to people in positional authority (executives, managers), but also to those with power or influence relationally as well.

Resources

Braver Angels

Simple Rules for Business Agility

with Zach Bonaker

Systems of Work x Systems of People

In order to remain unchanged, the system must change, specifically.

― John Gall, SYSTEMANTICS. THE SYSTEMS BIBLE

When a system stops adapting, it is dead.

― Design in Nature

Keep it loose, give people (at least three) options.

Use Simple Rules!

3 C’s (via Esther Derby + Don Gray)

WIIFM (what’s in it for me?)

“Giving people options is more important than consistency.”

“Make work visible at all levels.”

A powerful, simple rule.

Archimedes Lever: Utilizing Hidden Costs as Change Lever and Improvement Metric

with Brian Irwin

SEAM (Socio-Economic Approach to Management). The socio and economic factors are interlinked, interdependent, like sides of a coin. (Connection back to Bonaker’s Systems of Work/People chart)

Don’t get distracted by the cost of change. “Show them the cost of not changing.”

TFW (Taylorism-Foolism-Weberism) Virus

Results Pyramid

Focus your efforts on that bottom layer.

Make hidden costs visible!

In Brian’s experience, he’s never seen this amount to less than $42k per person per year.

Lead Without Blame

with Diana Larsen

Hold people accountable <—— OR ——> Lead through learning

”Knowledge Learning Work”

Motivators

Learning Leaders 4 C’s

Efficient?! Ensemble Programming!? How?

with Tim Ottinger

Watch the baton, not the runners.

– Don Reinertsen

There is an undue amount of attention given to speeding up development work. In a traditional team of solo devs, hands-on-keys work typically only accounts for a small percentage the total lead time. Most of the time, the work sits in a queue somewhere, waiting.

Even if they were to double the speed of their dev work, that would only produce a 2.5% gain in speed overall. Also: no one can double their development speed. That’s not a thing.

“Where there is a handoff, there is a queue.”

A hypothetical team spends 60% of their development time fixing bugs. What if they could eliminate bug work by going 2x slower? This would result in a net lead time reduction (speed gain) of 20%:

(100% - 60%) * 2x = 80%

Ensemble programming

“Every bit of work you have in progress is another reason for someone to interrupt you.”

Ensemble programming (including pairing) is inherently more efficient because it replaces handoffs and the considerable lead time between touches with real-time interactions.