May 24-45th, 2022
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.
yes. individual engineers can *write* software, but only teams can deliver, ship, maintain and own software.— Charity Majors (@mipsytipsy) April 14, 2022
the smallest unit of software delivery is the team. https://t.co/mkYPvzRuDh
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.
“Are our rules helping up to add capabilities? Or are we just getting scared and adding more checkboxes?”
“Accidental gamification corrodes systems.”
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.
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.
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.)
This doesn’t just apply to people in positional authority (executives, managers), but also to those with power or influence relationally as well.
with Zach Bonaker
In order to remain unchanged, the system must change, specifically.
― John Gall, SYSTEMANTICS. THE SYSTEMS BIBLE
When a system stops adapting, it is dead.
Keep it loose, give people (at least three) options.
WIIFM (what’s in it for me?)
A powerful, simple rule.
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.”
Focus your efforts on that bottom layer.
In Brian’s experience, he’s never seen this amount to less than $42k per person per year.
with Diana Larsen
Hold people accountable <—— OR ——> Lead through learning
Knowledge Learning Work”
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.
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%
“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.