Agile, AI, and Engineering Pragmatism with Jon Kern

Alexis:

This is Le Podcast on Emerging Leadership. I'm your host, Alexis Monville. Today, I'm joined by Jon Kern, an aerospace engineer turned software architect and a co-author of the Agile Manifesto. Jon is currently an agile consultant at The Adaptavist Group. How do you introduce yourself to someone you just met?

Jon Kern:

Like in a formal business setting, or at a party at a friend's house?

Alexis:

Let's say in a business setting.

Jon Kern:

Okay. I was just in Nuremberg at the Business Agility Conference last week — you could probably ask people there. I generally introduce myself as just a guy, a developer, a software engineer. I love to help build awesome products and help teams build awesome products. So mostly as just a guy, an engineer. I only reluctantly mention that I'm a co-author of the manifesto — and that's pretty rare, when I have to impress somebody. I really am just another person doing the good fights, trying to help people.

Alexis:

I love that, and I agree. I met you a few years back at the Agile conference in Dallas, I believe. It felt like a normal interaction. A lot of people knew who you were, but you were very curious about what other people had on their mind. So you mentioned the Agile Manifesto — can you tell us what led to your contribution to it?

Jon Kern:

I've had a really blessed career, starting with Defense Department jet engine testing. Some wonderful mentors — I still get together with Rich Thaler pretty much every year. One of my first mentors. And also some really interesting signposts. I'm in my early 20s at the time, and I remember thinking of somebody in their 40s, "Yeah, I don't want to be like this person that far into my career." So I had these great opportunities to be mentored and to see things I didn't want to do, and to grow from there as an engineer.

After four or five years of jet engine and cruise missile engine testing, I discovered the awesomeness of software — bringing a three-hour job down to a few minutes. I was bitten by the bug early on. Then I moved with another one of my former bosses to a Defense Department contractor and started a whole other 10-year career there with flight simulation and, again, heavyweight MIL-STD-2167. So I started to brush up against these heavyweight processes that made no sense with the kind of work we were doing. They might make sense for other types of work, but it was a one-size-fits-all big heavyweight process.

My personality is the kind where if it's stupid, I don't want to do it. Many times I probably should have been fired from some companies. But I learned it's better to ask forgiveness than to ask permission. I was creating a lighter-weight method — I'm a taxpayer too, why should I just do this stupid process for process's sake? So I created my own lightweight process to combat the lunacy of pretending you could estimate a year-long research-and-development project that was purposefully going to wander and learn — that's the whole point.

A lot of things led me to be very vocal at Snowbird about my experience with heavyweight process. I had also started working with Peter Coad, who became an object-oriented mentor and then hired me away from my own company to help found Togethersoft in the late '90s / early 2000s. We had a way of working there — feature-driven development — and a mantra: frequent tangible working results. Looking back, it's easy to see why people, process, and tools — kind of the first value — was a mantra we already used. It certainly feels like the manifesto was tailor-made as a way to capture a lot of the learning I had. It was an amazing opportunity to get all that into a resonant frequency with others in the room.

Alexis:

Excellent. So now, roughly 25 years later, what are some of the misconceptions about Agile you've encountered over time?

Jon Kern:

The blessing and the curse of the manifesto, looking back, is that it's an extremely post-conventional way to make your meaning about how to do software development. One of my good friends, Daniel Markham, once said, "Imagine being a fresh-out-of-college developer on a software team, being told to go read the manifesto — especially the first values page. What are you supposed to do with that? Where do I start?" That's definitely a blessing and a curse: it's super powerful if you get it and understand it, but super ambiguous and unclear if you don't.

It's not a recipe. It's not a step-by-step process. That's the biggest — I don't know if it's a misconception or just human nature to want an easier way. So people reached for things like Scrum, or God forbid SAFe, which reminds me of the old Rational Unified Process we were fighting against back in the day. Over time, I literally checked out of the Agile community because I saw the penchant for simplifying — assuming you could just learn a framework and get a certification in a couple of days and somehow be agile. I was like, no, not interested. I'll just go work with teams and have fun and help explain through action and involvement what I think agility is.

At Adaptavist we happily work with teams to help them experience what agility might be. And when I was brought back into the Agile Alliance for a gathering, I remember thinking, "What happened? Why is there nothing technical in this conference?" I'm an engineer by training, and all of a sudden it was all about coaches. Yes, you need to care about the soft skills, but what happened to the main thing? The main thing is trying to produce value and put smiles on customers' faces in exchange for helping pay my salary.

Alexis:

Yeah. And I feel the first sentence of the manifesto was the very important one — about uncovering better ways of developing software by doing it and helping others do it. That one could be enough on its own.

Jon Kern:

When I look back, nobody knew this was going to take off. We just passed the 250th anniversary of the Declaration of Independence — the amazing thing that happened when a relatively small number of farmers and lawyers and doctors came together and created a document. In hindsight it's amazing. In an extremely humble way, I feel the same thing happened at Snowbird. It was a magical cauldron that produced a pretty small set of words.

When I take that first page — the values page — I point out the preamble and the humility in it. It's active voice: we are still uncovering. With the advent of AI, I'm now wholly addicted to vibe coding, and I just did a fun workshop in Nuremberg. It's a whole game changer, but you'd better have a good solid understanding of engineering practices and principles, and what agility really means. That preamble is so true: we're still uncovering. And how do we do it? Not by reading about it, but by doing it and experiencing it.

The very first value — individuals and interactions over processes and tools — is almost sufficient on its own. The other three are details, so to speak. And the postamble, about the left over the right, is also a big dose of humility. It doesn't say the right doesn't matter. I'm a documentation nut. I'm always forcing people to take their knowledge out of Slack or WhatsApp and put it into a Confluence knowledge base. What we do is a lot more complex than people understand.

Alexis:

Yeah, I have the feeling those are polarities. At the time it was written, the pendulum was really tilted to one side, and the goal was not to pull it completely to the other side, but to say, "Hey, let's find the right balance."

Jon Kern:

That's a great way to visualize it. It's the right balance for your context, and it's going to change. That's the point — you have to be intentional. One of the things the manifesto can do is bring attention to different things you may or may not think about. All of those values are calls to pay attention to these things. And then, to your point, where do we dial it for this project, for this customer, for this feature? It really is like sliders. In a super highly regulated environment, I might bake in ways to capture more documentation and screenshots, because that's going to be a more effective way to deal with something super heavyweight. But it just has to be — how can I make it cost less and suck less? That's kind of one of my other mantras: be lazy.

Alexis:

That's an interesting one. Give me an example of being lazy that is effective.

Jon Kern:

Way back in the day, 1995 to 1998, I was cutting my teeth architecting IBM's manufacturing execution system as an outside consultant. Discrete manufacturing — making computers. One of my buddies had left the DoD company at the same time and was working in pharma, similarly in manufacturing, but not discrete — the more challenging aspect of making medicines and drugs and things with batches. Almost like hamburgers: you have to be able to track exactly what the screen looked like, how it was designed, when something was being manufactured. Versioning out the wazoo.

Being lazy, to me, is a clever use of technology to make that suck less. "We're going to have the QA people take screenshots and document…" — screw that, let me build something to do it. Being lazy is finding a faster, more effective, cheaper way to do something that I would consider mundane and tedious.

Lazy also means: don't do so much work ahead of time. The most offensive thing teams do is doing far too much work, to too great a depth of detail, too far in advance of the need. Big requirements, excessive UX design, crazy stuff. You need to do just enough to get the frame. That fights against everything we've been taught since we were children in school — doing more is better. "I got five 100s in a row on the quizzes in algebra!" That's such a disservice to an agile way of working. You have to fight it.

I often say: I can out-small anybody. What's the tiniest thing that you can think of to build? "Oh, that's lazy — I don't want to build all that." Because I don't believe it. We don't know as much as we think. Let's treat it as a hypothesis, get some feedback sooner. Think of the smallest possible thing you could do to get feedback, then make it slightly smaller until you're uncomfortable. Your level of uncomfortableness won't be mine — I'm okay being embarrassed delivering something embarrassingly small. The point is to get skilled at getting less and less, because you can always add more if you missed the mark. You can never take back the time and energy you spent, and you'll never know if it was too much.

Alexis:

And it's hard. I can feel how hard it is. You mentioned business value — putting a smile on your users' faces. How do you help teams stay focused on that?

Jon Kern:

Such an important topic. Whenever I'm working with teams — trying to center along something they're trying to achieve — the first meaningful exercise is: in 25 words or less, what is your business purpose, your system purpose, however you want to think about it? At Adaptavist, we coach internally: why are you here?

It's a bit like Bob and Bob, the efficiency experts in Office Space: "What is it that you do here?" It's humorous, but it's critical. If you don't know why you're here, what are we trying to do? I love learning a few things that apply whether it's a full product idea like agile buzzword bingo, or a feature, or an epic. The point is understanding what we're after, what the outcome is — the raison d'être. Without that, you might just be an order taker, and any list of requirements will do — and it will be huge.

The whole point is: how do I get my entire team — many of whose brains are better than mine — to participate in being humble and being lazy, because we have a flag in the distance? We know what we're trying to do. So people can exercise micro-judgments. I've got smart people; I don't want to have to think it all up myself. I put it out there — this is what we're trying to do — and then I'm surprised and elated when an engineer or a UX person offers up the smallest possible thing to get the most value. Maybe I can't do it all, but maybe all isn't necessary. That's what we say: we should treat the requirements as hypotheses.

It's a self-reinforcing loop. Without it, you're an order taker. You might have to invent it in your head and wonder why they're asking for this. "I don't know, I'm just a coder." You will be replaced by me and Replit. If you're not going to use your brain — or you're not allowed to — you need to replace the process, because you need to ask that question right from the start.

Alexis:

Just enough to get feedback and deliver some value.

Jon Kern:

And as much as possible, have customers in the room when you have something to validate — even if it's early. Look over their shoulder. "I'm not sure the UI feels right — come look." All of that is shortening the gap in time between doing something and getting feedback. It's really simple in my mind. It just appears to be really hard for a lot of teams to get there, or to think it can really be that simple. It's harder to get customers to talk to — but the simplistic secret is: involve your customers.

Alexis:

You mentioned AI twice, so I need to ask about it. How should leaders consider AI in their organization?

Jon Kern:

I'll narrow it down to the way I'm thinking about it in the context of building software. A couple of years ago I spoke in Belgrade at an Agile conference where a workshop used AI at the front end for requirements. I'm a behavior-driven development guy — I write my Jira issue in Gherkin, given/when/then. It's a super awesome, fast, concise way to write a requirement. Couple that with some domain models and UI designs. The AI tool produced BDD-driven requirements. My takeaway was: it seemed a little excessive. A lot of volume. How much editing would I have to do versus just doing it myself?

More recently, I'm working with a guy who obviously asked AI to produce his requirements around producing something like a unique, protected certification. He used an AI tool, built it out, then dumped it into Jira epics and issues. Oh my God — now you're really getting on my nerves. Part of the process of taking an idea and building it out is working with it. Just because I can get a tool to spit all this stuff out — including BDD, including the specs, "use this API" — I felt that was taking the learning opportunity away. I basically pushed it aside, took the real requirement — what a customer might ask — and then, as an engineer, figured it out.

And then to the vibe coding part. This is the most wild thing. I learned about it flying to Special Operations Command in September. My normal mode was: I have a Git repo, download this little toy project, get yourself set up — a BDD/TDD environment. But I thought, it's 2025, there's ways to do development in the web without downloading anything. I stumbled on Replit. Just two weeks prior they had released Agent 3. By the time I landed, I'd already built a little Conway's Game of Life app. It took away the whole install step.

Now I just needed to coerce it. It will happily go do speaking of do the tiniest thing… no, that's not how it operates. It's "Whoa, Nelly, what are you doing?" I had to learn how to actually coerce it to do BDD. It was really funny how hard it was to get it to stop and write a failing test. I've now learned how to get it to be curious and to supply options.

The calculations about what I can now do because of vibe coding have completely changed my approach. I've had, for almost two decades, an app for firefighters and emergency services — from small rural departments to Arlington, Texas (17 stations). It's a no-joke way to try to protect lives and property. I used Replit to update the Rails app from current production to the new version. And I learned I could do things like web penetration testing, security audits, GDPR compliance, SOC 2. Instead of doing it off to the side, I built a security-audit control panel with a Kanban board and the findings, then knocked them down as I was making staging before production. I never would have done that, because in the past it's been manual — a spreadsheet, maybe. I could automate the penetration testing. I could even have Replit refer to "let's tackle finding number 13" or "tell me about your infrastructure in the context of these compliance regulations." That kind of thing is wild.

So you can do an amazing amount of rigor if you need to, and automate it. Again, that's being lazy: I don't want to do this by hand. It's unbelievable what you can do. You just need to know — I'm blessed with a long career and knowing the hard way to do things. I know what architecture looks like. I know the things I should worry about. With teams, you can now take non-functional requirements and bake them into the product. At the touch of a button, if a new client — like a major European elevator company — wants to use this firefighting app and wants to do a security audit, "Oh, check this out."

Alexis:

It's funny — I also hear things you said earlier about quality by design and solid architecture in your answer about how to use AI in an effective way. So it's very interesting.

Jon Kern:

Yeah. It's a brave new world. It's exciting.

Alexis:

Excellent. What is one question I should have asked you that I did not?

Jon Kern:

You touched on it — quality by design, solid architecture, purpose. Maybe the missing piece is: agile is necessary, but not sufficient. To build great products you also need clear purpose, a shared domain language, sound architecture, and relentless consistency. Being agile without engineering discipline just gives you fast garbage. Being disciplined without agility gives you beautifully engineered products nobody wants. You need both — especially now that AI can amplify whichever end of that spectrum you lean into.

Alexis:

Beautifully said. Thank you very much for making the time to join me for this episode, Jon.

Jon Kern:

My pleasure, Alexis. Thanks for having me.

Alexis (outro):

If this conversation resonated with you, I'd really encourage you to share this episode with one or two people in your life. Someone you work with, someone you lead, or someone you are learning alongside.

Your recommendations truly matter. They help this podcast reach people who could learn from these conversations and apply them in their own context.

You can also find the full transcript of this episode in the companion blog post linked in the description. It's available on alexis.monville.com if you'd like to revisit a specific moment or share it in written form.

Le Podcast on Emerging Leadership is supported by Pearlside. At Pearlside, we work with leaders and teams to create the conditions for responsibility, clarity, and impact to emerge.

You can learn more at pearlside.fr. Thank you for listening.