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 a 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 Agile Manifesto.

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, 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, 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 retro's 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.

Continued here: On Systems Debt

Popular

Work Experience vs Professional Experience

Image
In reviewing a bunch of resumes this week, I noticed quite a lot of resumes with a  "Work Experience"  section. In each of those resumes, people had de-valuing some very valuable  experience - and I write that with no exaggeration. The problem is people were looking at their experience purely through the "Job Title/Relevancy" lens and had reduced their experience down to a list of discrete, random, disconnected jobs. No interconnectedness, no narrative thread weaving through it all. As much as you may feel some jobs have no way of being connected, the reality is  you   are always the connection . To not connect them on your resume is to lose all that growth, knowledge, skills, impact, value, and trajectory. In other words - you lose the " You " in the resume. I recommended they start with a small change. Reword "Work Experience" to "Professional Experience" because, ultimately, every single job they had was in service of building their ...
Read more

Let's Clear Up The Ambiguity!

Image
Job seeking is hard - especially when you factor the ambiguity around expectations, the lack of transparency and consistency around process. It's frustrating dealing with the sheer subjectivity of everyone's opinions. Just think of even the basics: How long should your resume really be? Traditional black and white, or modern? Should you include a headshot? Oh - and cover letters - are those needed? Is anyone actually reading the cover letter? What are they looking for? Is there a bias for people with a more traditional background? Worst of all: The dreaded typo  that you catch only after applying to your dream job.  Are typos really going to cost you the opportunity??? To help bring some clarity to the process, I surveyed a bunch of hiring managers. The results were really interesting, and very illuminating.     If you're on the job hunt, I hope this information helps out! One final note: My recent post,  7 Steps to Writing an Amazing Resume , factors a lot of...
Read more

FAQs for a Software Engineering Hiring Manager

Image
Technical Interviews have evolved a lot since the early I transitioned from being a Software Engineer to an Engineering Manager. Particularly in the post-Covid era, there's been a greater emphasis on the person, which I think is an important and welcome change. Over the decade of interviewing hundreds of coders, I've also had the pleasure of working with various bootcamps, colleges, and hundreds of individual job seekers on LinkedIn. Across all the changes over the past years, across the various locations and mediums, something remained consistent throughout: The questions I get asked.  With that in mind, I thought - why not make a FAQ from my perspective as a hiring manager? While this is my perspective, it's based off years of observation and supporting data. But that being said, advice is not fact. You may disagree with certain points, and that's OK. Opinions we disagree with allow us to better understand our own views. At best, I hope these responses help you...
Read more

7 Steps to Writing an Amazing Resume

Image
  Since sharing my resume template  I've received plenty of feedback from job seekers, HR and hiring managers - all of whom value its purpose. Two (now former!) jobseekers even shared that as soon as they used my template, they were getting calls. Something about this template works, and given the traction it's getting others, I wanted to share - in more detail - why  this approach works so well.  Before continuing, let me give an important disclaimer: This resume isn't a miracle cure that's going to land anyone their dream job. Unless they're filled with lies, resumes are only as good as the candidate themselves. But they can also be a whole lot worse. This template and approach are all about maximizing the potential candidates have by highlighting and summarizing key areas.  Last point before beginning: If you don't know me, it's worth stating this advice comes from more than a decade of having hiring a broad range of coders: straight out of college, hig...
Read more

7 Steps to Building your Portfolio MVP

Image
Often when I suggest to coders that they build a portfolio, I'll hear back: "I don't need one..." "With all the effort it takes to apply, where will I find the time?" Simply put, having a portfolio's never going to hurt your chances at landing a job - it can only help. That second question is where a lot of struggle - because applying to jobs can be time consuming. Especially if you're wrapping up a bootcamp, or having to manually type in your resume info after uploading your resume. That's why I made these 7 steps which, when done correctly, can really help you stand out with a hiring manager. And, the best part is, it should only take you 2 days. Being the Agile-Obsessive that I am, it's all about maximizing value while minimizing effort. Fix links to your Resume, GitHub, LinkedIn, etc. at the top where they're always accessible. Link to everything here - and then remove all other links on your Resume except your Portfolio link . It sa...
Read more