If you're not familiar with the episode from Seinfeld, the tl;dr of it is that George's father, Frank, is given the mantra of " 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 Serenity now..." 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 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 . grandfather of Agile Agile Manifesto But before looking deeper into Lloyd's principle, let's first revisit the original Agile Manifesto's 12 principles: The highest priority is to satisfy the customer through early and continuous delivery of valuable software Welcome changing requirements, even late in development. Harness change for competitive advantage. Deliver working software frequently. Business people and developers must work together throughout the project. Build projects around motivated individuals with the environment and support they need to get the job done. Prioritize face-to-face conversations. Working software is the primary measure of progress. Promote sustainable development, where a constant pace can be supported indefinitely. Attention to technical excellence and good design to enhance agility. Preference for building on things_._ not Build self-organizing teams. 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 matters. It matters that I believe in , with Lloyd's getting placed at index 0. Lloyd Braun Principle of Agility so much 13 Agile Principles 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: 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. Serenity now. But the second lesson tucked away in the second part - that is what we don't spend enough time discussing. It's not just an instruction to add complexity later - to put off the insanity. It is a warning that prioritizing simplicity means insanity 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. Insanity later. will explains the first 6 Agile principles. Those first six offer a framework for delivering with simplicity. Serenity now 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. Insanity later I hear too much about retros that don't happen or aren't taken seriously . Or I've seen too many teams that are resistant to change, or adapting 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. ("There's no point in bringing this up... it's not like my manager can fix it...") ("Why are we changing the process again? I thought this was working?"). 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 here.

Keep

FAQs For a Software Engineering Hiring Manager - Part 1 of 5: Resumes

Dealing With Systems Debt

Read My Stories

Check out the resources I've made for job-seeking coders...

Too Long; Didn't Read

Make resilience your competitive advantage

The Lloyd Braun Principle of Agility

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

FAQs For a Software Engineering Hiring Manager - Part 5 of 5: On Managers, Growth & Progression

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

FAQs For a Software Engineering Hiring Manager - Part 5 of 5: On Managers, Growth & Progression

The Noonification: The Future of DeFi - Emerging Evolution (11/3/2022)

10 Ways PMs Can Earn The Respect and Trust of Their Team

10 Terms Every Engineer Must Know

10 Subtle Superpowers of DevOps

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps