Agile Purists vs. Agile Realists: Do You Really Have to Go by the Book?

When we say “Agile development,” what does that mean to you? Agile software development is such an established methodology that there are now a few different approaches and schools of thought around it. There are the “Agile purists”—folks who believe in following the methodology to the letter—and then there are “Agile realists”. Like the name suggests, realists take the Agile process and tailor it to their team as the needs shift and evolve.

One Reddit user who describes themselves as a Product Owner defined the concept of Agile practice as, “the team can control their own destiny, they are autonomous, self-organising, can release when they want, can react really quickly to change, and have plenty of time to innovate.”

Navigating how to use Agile methods is part art and part science. Rather than debate the true definition of Agile development, we thought we’d offer some helpful guidance on how to adapt the Agile process no matter what comes up during your project’s lifecycle.

Stop chasing waterfalls: Embracing Agile methodology

The waterfall method is a more traditional method of project management that can also be seen as a “pass the baton” method. One team has to completely wrap up their part of the project before handing it off to another team to take over, and so on and so forth. The trouble with this method is that there’s rarely crossover or meaningful exchange between teams, since everyone is strictly assigned to their part of the process to complete when assigned.

The fallout of this is a tale as old as time: engineers feel disconnected from what sales is promising customers, designers feel like they could have more input into how certain features can work together more efficiently, and so on. Although the waterfall process may feel more controllable or manageable, it may not result in the best experience for users of the product, nor the teams building them.

It’s no wonder that software development teams are valuing more collaboration, and earlier, than less. For all these reasons, committing to the Agile method is undoubtedly a better way for development teams to operate. But it’s important to be aware that even Agile teams these days can be, ironically, a little rigid.

Most software teams aren’t actually doing Agile 100% correctly

The hallmark of Agile development is that it’s an iterative process. By nature, Agile is about adapting to change. It’s a structure that’s meant to be malleable to shifting circumstances. At Zenhub, we’ve seen the way hundreds of teams operate. And one thing we’ve noticed is teams rarely use Agile by the book. Most teams are adapting and taking bits of pieces of Agile events and processes that work for them, and leaving the rest. Essentially, most software teams are agile realists. Although Agile purists may see this as problematic, we see many teams experience great success structuring their project management this way.

“The Agile release planning process guides this rapid, iterative deployment methodology, providing structure to the team’s efforts while remaining flexible in the face of the inherent unpredictability of software development projects,” writes our own Mariana Racasan in a previous post about Agile release planning.

Since even a change in team members can set a deadline back, as new people get up to speed, Agile recognizes that there are always factors beyond our control. Our natural reaction to change may be to dig in our heels and make the team work harder to meet sprint deadlines that may no longer be feasible. Whatever you do, resist this urge. The beauty of Agile is that teams should be able to adapt it to support themselves no matter what (inevitable) changes pop up.

Making Agile work for your team and embracing being an agile realist

Estimates are called estimates for a reason. Take comfort in that! The whole spirit behind Agile methodology is continuous learning and improvement. Let’s say you’ve defined your release goal, reviewed and prioritized your backlog of tasks, mapped out your story point estimates, and you’ve determined the number of sprints you’ll need to make your target release date.

That’s a lot of work and it’s totally understandable to want to stick as closely to that plan as possible. But things happen. User research may have uncovered something new about your existing or potential user’s needs. Maybe you received some feedback from a stakeholder about how a certain part of the app operates.

Whatever the case, the good thing about story points is that they can stretch as you need. Unlike estimating projects by time (which humans are notoriously bad at doing), story points allow teams to gauge the relative size of a task—for example, small, medium, or large. That’s a much more simple way to get the team on the same page and get more consistency and accuracy in your estimates.

Knowing how a change will impact the relative size of a task—and by extension the timeline for its delivery—is more helpful than having five different people individually guess how long it will take them to adjust to and act on new changes. That kind of clarity is also going to be crucial to a product manager or owner’s ability to report to stakeholders on progress.

It’s also a useful data point for forecasting. When you’ve tracked the relative size of a new task, you’ll know how to adjust for those scenarios in the future and the team can develop a muscle around dealing with that particular kind of change or issue.

Integrating Agile processes with your tech stack

You could do all your Agile planning by cobbling together spreadsheets and notes, but that doesn’t mean you should. The right tools will support Agile processes, especially adaptive ones.

It’s wise to look for tools that can easily integrate with the software stack that your development team already uses. There are a few other key features that support flexible sprint and release planning:

• Tools that have built-in estimation and provide the ability to forecast delivery of tasks
• Tools that track and provide reports on the team’s velocity and progress on milestones
• Tools that automate tedious tasks, allowing you to spend more time on optimizing the process

So let’s go back to our original question. When we say “Agile development,” what does that mean to you? Perhaps the real question we’re asking you to consider is ‘how Agile’ is your definition of Agile? It probably helps to adopt an adaptive mindset while you embark on this work. Remind yourself and your team that change is constant and that not all change needs to lead to chaos. Controlled, productive change is possible with the right mindset, approach and toolset.

Want more advice on how to run a high-performing agile team? Check out our free guide: Focused Teams, A Field Guide for Focus-Driven Development. Also check out what the world’s most innovative teams care about most in Zenhub’s 2022 State of Disruptive Software Teams.