The Lloyd Braun Principle of Agility

If you're not familiar with the Serenity Now episode from Seinfeld, the tl;dr of it is that George's father, Frank, is given the mantra of "Serenity now..." to help curb his enthusiasm for angry outbursts. Impressed with its effectiveness, Kramer adopts the mantra for himself. George's childhood rival, Lloyd Braun, later cautions that this mantra doesn't address feelings, but bottles them up, and leads to huge explosive anger. And that's when he delivers the classic line: Serenity now. Insanity Later.

At the surface, it's valuable advice about controlling our emotions, and stress - but deep within this statement is also a very important guideline for delivering Agile software. And while Seinfeld isn't known for technology, it's too perfect that the backdrop of this episode has Frank, George, and Lloyd selling desktop computers. George, of course, struggles to keep up with the zen-like Lloyd, who has reached true Agile enlightenment.

In fact, let's add further insult to George's unending injuries. I think Lloyd deserves to have an Agile principle named after him. Arguably, Lloyd is the grandfather of Agile given that this episode first aired in 1997 - some 4 years before seventeen people would meet at a ski resort in Utah to produce the .

But before looking deeper into Lloyd's principle, let's first revisit the original Agile Manifesto's 12 principles:

1. The highest priority is to satisfy the customer through early and continuous delivery of valuable software
2. Welcome changing requirements, even late in development. Harness change for competitive advantage.
3. Deliver working software frequently.
4. Business people and developers must work together throughout the project.
5. Build projects around motivated individuals with the environment and support they need to get the job done.
6. Prioritize face-to-face conversations.
7. Working software is the primary measure of progress.
8. Promote sustainable development, where a constant pace can be supported indefinitely.
9. Attention to technical excellence and good design to enhance agility.
10. Preference for not building on things_._
11. Build self-organizing teams.
12. Reflect on how to become more effective, and adjust.

Taking a closer look at each of these, they all share the same spirit around problems we face regularly: We know that software systems only increase in complexity with time. Technical debt grows, new features creep in, scope increases, software gets bloated, developers burn out, people get frustrated, and quality decreases. You know it all.

And that's where I think the Lloyd Braun Principle of Agility matters. It matters so much that I believe in 13 Agile Principles, with Lloyd's getting placed at index 0.

0. Simplicity now - complexity later; Serenity now, insanity later.

There are two lessons to be learned from this one principle. The first lesson comes from the first part of the statement: Serenity now. We know not to over-engineer. We deliver to the baseline. The 80/20, KISS type rules. Deliver the MVP. Prioritize value. Add complexity later, and only if there's demand for it.

But the second lesson tucked away in the second part - that is what we don't spend enough time discussing. Insanity later. It's not just an instruction to add complexity later - to put off the insanity. It is a warning that prioritizing simplicity means insanity will come. Whether it's in explosive user growth, challenging timelines, taking on technical debt in favor of delivering value early on or maintaining legacy code that didn't scale to meet insane needs. Insanity and complexity are to be expected.

Serenity now explains the first 6 Agile principles. Those first six offer a framework for delivering with simplicity.

Insanity later is dealt with in those bottom 6 principles. Those principles help us manage the chaos: How we converse, how we measure value, how we should push back, how we should organize, and continuously evaluate and be critical of how we are working.

I hear too much about retros that don't happen or aren't taken seriously ("There's no point in bringing this up... it's not like my manager can fix it..."). Or I've seen too many teams that are resistant to change, or adapting ("Why are we changing the process again? I thought this was working?"). Or, worst of all, managers who subvert what it means to have a self-organizing/self-managing team or who measure progress by output and not outcome.

Especially in this new world, we're living in - with remote teams, virtual meetings, and a renewed emphasis on work/life balance - I think it's high time we take a more holistic view of what it means to be Agile - focusing less on serenity now, and more on the insanity later.

Also published