For years, Agile has been turned into frameworks, certifications, ceremonies, and checklists. Over time, many organizations stopped asking why and focused only on how.

Agile Unframed exists because Agile deserves better.

This newsletter is not about defending Scrum, selling another framework, or arguing over story points. It's about returning to the principles that made Agile transformative in the first place: learning, experimentation, collaboration, and building products that genuinely improve people's lives.

The name Agile Unframed has two meanings.

The first is simple: Agile should never be confined to a frame. It is not a rigid methodology or a predefined process. It is a way of thinking about uncertainty, complexity, and continuous learning.

Second, we'll look at Agile with clear eyes. No buzzwords, no consulting jargon, and no so-called best practices just because they're popular. We'll question assumptions, challenge common views, and focus on what really works.

What You'll Find Here

Agile Unframed brings together ideas from software engineering, product development, design thinking, Lean thinking, organizational psychology, and leadership.

Topics you'll see include:

• Why Agile transformations succeed or fail.
• Why Scrum is not synonymous with Agile.
• Building learning organizations instead of process-driven organizations.
• Product discovery and evidence-based decision-making.
• Engineering practices that enable agility.
• Leadership in complex systems.
• The role of design thinking in product development.
• Lean principles beyond manufacturing.
• Organizational culture and team dynamics.
• The myths, misconceptions, and unintended consequences of Agile adoption.

Some articles will be practical, some will be more about ideas, and often they'll be a mix of both.

What You Won't Find

You won't find:

• Lists of ceremonies to implement.
• Framework comparisons for the sake of comparison.
• "Ten easy steps to become Agile."
• Dogmatic opinions presented as universal truths.
• Advice disconnected from real-world engineering.

Complex problems usually don't have simple answers, and organizations are much more than just flowcharts and process diagrams.

Who This Is For

This newsletter is for people who build products and organizations.

Whether you're a software engineer, engineering manager, product manager, designer, executive, founder, coach, or simply someone curious about how great teams work, I hope you'll find ideas that challenge your thinking.

You don't have to agree with every article.

In fact, I hope you don't.

Good ideas become stronger when they're questioned.

Why I'm Writing This

After years of building software, leading teams, and working with startups, healthcare groups, and product companies, I've noticed a pattern:

Most Agile problems aren't Agile problems.

They're leadership problems.

They're communication problems.

They're organizational design problems.

They're engineering discipline problems.

They're incentives.

They're culture.

Agile makes those problems visible.

Instead of asking, "How do we become more Agile?" we should ask better questions:

• How do we learn faster?
• How do we navigate uncertainty?
• How do we create better feedback loops?
• How do we build software that matters?
• How do we create organizations where people can do their best work?

Those are the questions this newsletter wants to explore.

An Invitation

Agile Unframed isn't about having the final answer.

It's about continuing the conversation.

If an article here changes how you think, challenges your assumptions, or starts a conversation with your team, then it's done its job.

The Agile Manifesto was never intended to be the end of the conversation.

It was the beginning.

Let's keep exploring what Agile can be when we take away the frame.