So You're New to Agile – Where to Start?

Here, I’ll outline some of the very basics that every newbie needs to know. You see, I’m a big fan of everything Agile, and I believe that Agile ways of working provide an endless array of benefits to companies and teams. You can even apply some of its principles in your day-to-day personal life (more about that here). However, Agile done wrong—or done just for the sake of saying you’re “Agile”—can bring more harm than value. That’s why it’s crucial to develop a basic understanding of its principles before attempting to apply it.

So, what is Agile? The common definition is that it’s a set of 4 values and 12 principles defined in the Agile Manifesto (you can read more about it here). The problem I have with this definition is that it’s too software-specific and, frankly, a little outdated—even for software. For example, “Deliver working software frequently, from a couple of weeks to a couple of months” might have sounded revolutionary back in 2001, but today, shipping new software every few days, if not hours, is more common.

Personally, I prefer to define Agile through these core principles:

1. Adaptability to Change: Whether it’s changes in the market, technology, politics, economics, customer behavior, or resource availability, the ability to respond quickly and effectively is key. The sooner you can recover from an unexpected change, the better.
2. Customer Value Delivery: Focus on delivering value to the customer rather than just meeting deadlines, satisfying stakeholders, or raising funds. When you prioritize the customer’s needs, business success naturally follows.
3. Team Ownership: Teams that take ownership of their products, goals, and results tend to be more flexible, creative, innovative, and resilient. They’re not just executing someone else’s vision—they’re crafting their own.

Notice how I didn’t mention sprints, Scrum masters, or story points? That’s because Agile is about mindset and common sense. The tools, roles, and practices are secondary.

Now that we’re clear on the mindset, it’s time to look deeper into the elements that Agile consists of. Sure, you can start with just the mindset and figure out how to apply it to your work on your own, but why reinvent the wheel when there are already some great tools out there?

First, we have frameworks as the largest elements of Agility. Scrum, Kanban, LeSS, SAFe, and many others provide structured approaches to implementing Agile principles. You can get a fancy official certification in any of these frameworks, but the truth is, you don’t need it to apply them to your work. It’s also perfectly fine to combine elements of different frameworks—just as long as you know what you’re doing.

Inside each framework, you’ll usually find its own subset of principles, which build on top of Agile principles, complementing but not replacing them. Then, there are elements like roles (some frameworks, like Scrum or SAFe, are very particular about roles, while others, like Kanban, leave roles up to you), practices (which can be daily processes like Sprint Review or specific approaches to work like Pair Programming), and artifacts (like a Sprint Backlog or Definition of Done).

Apart from that, we also have tools that are typically not prescribed by a framework but really help us manage our work—things like Trello, Jira, Miro, and others.

In order to be Agile, you don’t need to use any of these frameworks or tools. And conversely, using these frameworks and tools won’t magically make you Agile. Although, sometimes “fake it till you make it” does work. The mindset and values are more important than anything else.

This is why I dislike the term “Agile methodology,” and I steer clear of using it in my materials. Agile is not a methodology! It doesn’t tell you what to do or how to do it; it simply helps you focus on the right priorities.

As people learn about Agile and get excited about it, they often fall into the trap of “being Agile for the sake of it.” The first thing to remember is that Agile isn’t necessarily a silver bullet or the ultimate solution to all problems. It does bring a lot of benefits—in most cases. But there is a time and place for the opposite of Agile (what we usually call waterfall—a hierarchical, rigid product development process with zero tolerance for change). For instance, in construction, Agile might bring more harm than value. So, it’s important to apply Agile frameworks and tools only when they truly add value to the product, organization, and customer. Our goals should always align with the overall business vision and objectives.

A lot of people at the beginning of their Agile career tend to be “purists”—they try to implement Agile practices by the book, just as they were taught in training or certification courses. Any deviation from the guidelines can make them nervous and uncomfortable. But the truth is, there is no one-size-fits-all solution, and frameworks are rarely applied exactly as they are without any modifications.

As an experienced enterprise Agile coach, I’ve worked with many clients on full Agile transformations, and let me share a secret: you will almost never see a framework applied exactly as it’s described in theory. Most of the time, it’s a tailor-made combination of elements from multiple frameworks, designed to fit the organization’s processes and product context.

Of course, it’s important to understand how the elements of Agile work and what their purpose is before mixing and matching. But the ultimate criterion for determining if you’re doing it right is to ask yourself: Does this help my team deliver value to our customers? If the answer is “yes,” you’re probably on the right track.

Want to learn everything you need to know about Agile? Welcome to my course, Understanding Agile, where I cover all the basics you need to become a confident Agile practitioner!