Agile – Bret Patton

Building isn’t just what I do. It’s how I think.

I didn’t set out to become a Technical Program Manager.

Like many careers, mine wasn’t a straight line.

I started in Technical Support because I enjoyed solving problems. That led me into Software Engineering, then Scrum, Product Delivery, Technical Program Management, and eventually helping organizations coordinate complex initiatives across engineering, AI, product, data, and executive leadership.

Looking back, the titles changed.

The work I enjoyed never did.

I like making complicated things simpler.

I like helping people work together.

I like taking an idea that feels chaotic and helping turn it into something people can actually build.

Over the years, I’ve realized something that has shaped the way I approach every organization.

Most teams don’t fail because they lack talented people.

They struggle because priorities become fragmented.

Dependencies aren’t visible.

Communication happens too late.

Ownership becomes unclear.

Good people end up spending more time coordinating work than actually doing it.

That’s the problem I enjoy solving.

Technology has changed dramatically throughout my career.

Cloud computing.

Mobile.

Streaming.

Artificial intelligence.

Large Language Models.

Every few years there’s another breakthrough.

But one thing hasn’t changed.

Great products are still built by people who trust each other, communicate well, and stay aligned around meaningful outcomes.

That’s why I’ve always cared more about systems than processes.

Processes eventually become outdated.

Good systems adapt.

Whether I’ve been improving planning predictability, reducing delivery risk, supporting AI-powered personalization, or helping teams navigate large organizational change, the goal has always been the same:

Help people do their best work.

Outside of my career, I build for the same reason.

My wife and I recently moved back closer to family and bought a small farm where we’re learning gardening, tackling home projects, and raising our two daughters. I write because it helps me organize my thinking. I study AI because I believe it’s transforming how we work. I enjoy games because they reward strategy, creativity, and continuous learning.

Even side projects—whether it’s a comic business, experimenting with new technology, or creating stories for my daughters—usually begin with the same question:

“How could this be better?”

Curiosity has been the common thread through every stage of my life.

I don’t believe learning stops when school ends.

I don’t think leadership comes from having all the answers.

I don’t believe success is measured by how busy we look.

I believe great work happens when people understand why they’re building something, trust the people around them, and have the clarity to move forward together.

That’s the kind of environment I try to create.

Because at the end of the day, I don’t just enjoy building products.

I enjoy building teams.

I enjoy building systems.

I enjoy building organizations that leave people better than they found them.

When I step back and look at my life, I realize building has never been limited to software.

I build products.

I build teams.

I build systems.

I build ideas.

I build stories for my daughters.

I build gardens on our family farm.

I build businesses.

I build habits.

I build opportunities for others.

No matter the project, the motivation is the same.

To leave something better than I found it.

To help people accomplish more together than they could alone.

To create something that continues providing value long after I’m gone.

That’s why I build.

Thanks for reading.

If this resonated with you, I’d love to connect.

— Bret Patton

“Scrum hasn’t changed. We are just getting the description better.” – Jeff Sutherland

The Scrum Guide has been changed numerous times since inception. There is now an overall simplification of language for a wider audience. The Scrum Guide is now less than 13 pages. The Scrum Guide has placed an emphasis on eliminating redundant and complex statements as well as removing any related IT specific work (e.g. testing, system, design, requirements. Etc.)

Even Less Prescriptive:

The 2020 version aimed to bring Scrum back to be a minimally sufficient framework by removing or softening prescriptive language.

Easier to read and more white space.
removed Daily Scrum questions
soften language around PBI attributes,
soften language around retro items in Sprint Backlog
shortened Sprint cancellation section, etc.

Introduction of Product Goal:

The 2020 Scrum Guide introduces the concept of a Product Goal to provide focus for the Scrum Team toward a larger valuable objective. Each Sprint should bring the product closer to the overall Product Goal, while the Sprint Goal will still be in place.

A designated location for Sprint Goal, Definition of Done, and Product Goal:

With the addition of Product Goal, the 2020 version provides more clarity around this. Each of the three artifacts now contain ‘commitments’ to them. For the Product Backlog it is the Product Goal, the Sprint Backlog has the Sprint Goal, and the Increment has the Definition of Done. They exist to bring transparency and focus toward the progress of each artifact.

One Team, Focused on One Product:

The goal was to eliminate the concept of a separate team within a team and eliminate any negative behavior between the PO and Dev Team. There is now just one Scrum Team focused on the same objective, with three different sets of accountabilities: PO, SM, and Developers. The Development Team has been renamed to Developers to show the different team accountabilities.

Self-Managing over Self-Organizing:

Previous Scrum Guides referred to Development Teams as self-organizing, choosing who and how to do work. With more of a focus on the Scrum Team, the 2020 version emphasizes a self-managing Scrum Team, choosing who, how, and what to work on.

Three Sprint Planning Topics:

In addition to the Sprint Planning topics of “What” and “How”, the 2020 Scrum Guide places emphasis on a third topic, “Why”, referring to the Sprint Goal.

Scrum Master Leading Over Serving:

The Scrum Master has been classically called a Servant Leader, but in the 2020 version of the Scrum guide the terminology has been updated. The 2017 version stated The Scrum Master is a servant-leader for the Scrum Team. In 2020, it has been updated to Scrum Masters are true leaders who serve the Scrum Team and the larger organization. Ken commented to Jeff, “I think the biggest problem in Scrum is the word Servant Leadership.” Many people misunderstood the meaning of the phrase and see Scrum Masters as secretaries who aren’t responsible for enabling the teams to improve. Ken and Jeff knew they must do something about it, because the Scrum Master is a valuable contributor to the community and their lively hood helps establish the success of the team. They realized the problem with the misunderstanding is that the Scrum Master isn’t doing the leadership part of servant leadership. They reversed the words around where it’s still the same thing, but the leadership piece is front and center. A shift of emphasis gets people to focus on the keywords in the guide.

Scrum Team Size:

The previous versions of the Scrum Guide suggested the development team size be between 3 and 9 people. The new version suggests that Scrum Team is small enough to remain nimble and large enough to complete significant work within a Sprint, typically 10 or fewer people. Scrum has found that smaller teams communicate better and are more productive. If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner.

Conclusion:

The Scrum Guide didn’t really change. It was simply updated to have better terminology to define the purpose of Scrum. There are new words mentioned in Scrum, but that doesn’t change the meaning of Scrum. Scrum always has been designed to help teams develop complex software in a predefined set of iterations. Scrum is simple to learn, but difficult to master. Scrum still includes a Product Owner, a Development Team and a Scrum Master to coach the teams. This won’t be the last time we see the Scrum Guide updated, but this version is by far the easiest to understand so far.