Agile Development: Methodology and Strategies

What the heck is agile development? You’ve probably heard about agile development in your career. You may have even adopted some of its practices as part of your company or departmental efforts. Or maybe you just heard an executive at a company say “We need to be more agile in our processes,” and wondered what it meant.

Regardless, agile development is here to stay, and it has entered more and more workforces since its inception.

Whether you’re looking to adopt agile principles for your team, having to assimilate its practices into your routine as part of company mandates, or working with a team that uses agile methodologies, it pays to know what it is and how to get the most out of it.

What is Agile?

Agile boils down to a project management philosophy for most, though it can become more overarching than this to become a methodology for how you run an entire business or cross-functional team.

It springs from a set of value statements - sometimes called the Agile Manifesto - and then manifests into specific practices that adhere to those values. The values are:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

This manifesto dates back to 2001, so agile isn’t necessarily a new idea!

We’ll talk more concretely in a bit about how each of these value statements can turn into actionable strategies for collaborative teams.

Agile development is also used most frequently to describe software development. However, since its popularization in this industry, it’s since jumped to others having nothing to do with software development.

We’ll describe the philosophy in ways that apply to a variety of situations, not just software development, though many of the examples will come from this area.

Agile vs. Waterfall Development

Waterfall development is more traditional and has been around for a much longer time. Agile is in many ways a reaction to the perceived flaws with waterfall development.

In the waterfall method, projects are very sequential and all aspects of a project are generally completed before launch.

Conversely, agile projects often work on getting to a viable product in the quickest period of time, then receiving feedback on this product and iterating on it. The main idea is that a product does not need 100% of the intended features to begin utilizing it, and that this quicker development cycle will allow developers to improve the product more quickly.

This isn’t to say that agile is always better than waterfall. Heavily regulated industries may not have the luxury of agile development, for example, or they’d risk security, safety or legal violations. Product testing can be less financially risky in an agile model, though, so it makes a lot of sense for industries without these concerns.

Agile vs. Scrum

Agile and scrum aren’t in opposition to one another. Rather, a scrum is a type of agile practice.

Scrum generally has some codified elements such as:

Regular, quick meetings that act as progress updates and jumping-off points for collaborative work.
Sprints, which we’ll discuss more below. These are short periods of intense work to achieve a specific goal or goals.
Rapid, successive iterations of this cycle, with periods of planning and sprints alternating.

Scrum meetings and methodologies are a core part of many agile teams.

What is an Agile Sprint?

An agile sprint is a brief period of intense work with a specific set of goals.

The term sprint is used in juxtaposition with, say, a marathon, because the idea is that each sprint produces a successive iteration and improvement on the last product iteration. In this way, teams can make quick, incremental changes to a product, and can also adjust quickly to the needs of their customers or feedback on a product.

Various strategies exist for maximizing the effectiveness of sprints. These can include turning off emails and related work notifications, delaying other responsibilities not directly related to the sprint’s goals, and conducting quick daily meetings that act as progress updates and hold team members accountable for their progress (and identify potential issues that would inhibit progress).

What Is Agile Development Used For?

On a basic level, agile development is used to create products. Advocates for the methodology will tell you, though, that it’s a mindset that is useful for aligning teams in both purpose and productivity.

In creating quick, iterative changes and focusing on cross-collaboration within teams, an emphasis is placed on that collaboration and maximizing each person’s role in the whole.

Now imagine a workplace where each person is in their own world, doing tasks that only they work on. They might be a great employee! But there are undoubtedly times when their output and productivity suffer due to a lack of a support structure within an organization.

As mentioned earlier, software development is the industry where you’ll see agile employed most frequently. And it’s easy to see why! Many software tools don’t require a physical release, so iterative improvements can be released via downloads or routine updates.

Conversely, you can’t “update” a teapot once it’s been released. However, you can still develop a new style of teapot quickly, release it, get feedback, and iterate on the initial design before re-releasing it to a new set of customers.

So agile doesn’t need to be for digital products only, but it can sometimes be harder to adapt agile methods to physical products that have more limitations.

Benefits of Agile Development

Why do agile, then? It’s a good question, and if you don’t have a strong answer, you’re likely not going to get the buy-in of others you’re working with.

Here are some of the benefits cited by those who have implemented agile principles:

Flexible workflows. In creating numerous iterative improvements, there isn’t a rigid plan that needs to be followed.
Team collaboration. Agile environments almost invariably increase communication between team members, which can have numerous positive benefits for productivity and overall team happiness.
You don’t fail at scale. By keeping iterations time-bound and incremental, you avoid doing something that fails utterly, but spending months working on it or tons of money marketing and launching it. If something isn’t working, you find out quickly.
Decreased barriers between company and customer. Feedback is crucial to agile development, which means communication with your end users is vital. This can help their voices be heard, which increases their satisfaction with the product.

There are downsides to consider as well. In creating quick, successive iterations, it’s likely you don’t have documentation for each step, which can leave new employees floundering to catch up when they come onto your team. In industries with regulatory restrictions, this can also slow down your efforts to make sure you stay compliant with your industry’s standards.

Why Does Agile Development Fail?

If you research agile development enough, you’ll find a lot of advocates for it, but also some detractors who have seen it fail. Broadly speaking, there are two reasons this can happen:

Agile is not the right tool for the job
The team(s) did not fully adopt an agile methodology to their work

We’re going to focus on the second of those to describe some reasons agile practices could fail.

You’re Only Doing Some of Agile

A lot of people like the sound of agile and running their workplace by its principles, but they either don’t fully understand the change necessary to implement it fully, or they don’t want to.

This can be a problem. Imagine some teams in a company operating on agile while others are on waterfall. Or some employees buying into the system but not others. It’s a recipe for failure.

Conversely, one of our team members here at Leadflask had a past position where, even though his company wasn’t fully agile, he found success with daily scrum meetings with his department. This increased collaboration and reduced overall meeting time for the department. Both were positives. So occasionally these ideas can work when isolated, but in general the agile philosophy needs to be fully adopted to work as intended.

The Process Lacks Organizational Infrastructure

You can have all the motivation in the world but still fail, and this is usually because the infrastructure and resources don’t exist to facilitate the process.

This can happen in multiple ways. Maybe it’s a C-Suite that doesn’t support agile and therefore hinders its effectiveness on a departmental level.

Or maybe it’s that a team is largely remote, but lacks the proper software tools to collaborate regularly. They end up siloed in their work too much, and productivity suffers as a result.

The infrastructure must be in place to support the team, and if it isn’t, you’re ensuring failure.

Not Communicating Enough

Remembering that cross-collaboration is key to this process working, if an office environment or culture doesn’t encourage enough communication, the system breaks down. This is why scrum methods emphasize regular meetings between all team members.

If a data analyst fails to communicate relevant data points about a product release back to the production team, for instance, a product might not receive the iterative improvements it needs. Or, even if the information is eventually passed along, it might not be on a tight enough timeline, delaying improvements that hurt the company’s reputation and customer base.

Focusing on the Product, not Its Customers

Software developers usually have 100 different features they’d love to see in a piece of software, but rarely are all 100 important to the majority of their users.

If teams get too focused on their own ideas about their products, rather than listening to feedback and seeing how the products are actually being used by their end-users, development cycles will lengthen to unacceptable proportions.

Are There Alternatives to Agile Development?

While waterfall is the primary competitor in terms of its widespread use, there are other project development methods besides agile.

Waterfall might be better for organizations where the industry is slow to change, and so they can operate at scale for longer periods of time. Other times, there might be a variant of agile that makes more sense for your particular challenges.

When it comes down to it, businesses can be successful in a variety of systems. Agile has helped to solve problems and create efficiencies for numerous businesses and individual teams within them, but it’s not the only potential solution out there. Nor is it the only one that has found success.

Agile Resources

We’d be remiss in not calling out one of the central and seminal works in the agile movement, Scrum: The Art of Doing Twice the Work in Half the Time by Jeff Sutherland and J.J. Sutherland. Sutherland (J.J.) has also written The Scrum Fieldbook, a more nuts & bolts approach to creating and managing agile teams.

Literally hundreds of other books, podcasts, courses, and consulting groups exist to help you to implement not just scrum methodologies but agile methodologies as a whole. It’s become a gigantic wing of the corporate world, with applications for teams of any size.

On the software side, project management tools such as Asana and Monday specialize in providing infrastructure for agile teams.

Here at Leadflask, we actually have project management software that we created specifically for our team to be able to work efficiently. Enterprise-level software for agile can be found in a lot of places, and being able to make it work for you is important when choosing one for your company.

Mega-corporations such as Spotify have also experimented with agile practices at a scale never seen before, with numerous cross-functional teams that collaborate both within their smaller groups and between groups.

So there are numerous resources for you to absorb before trying to implement agile for your own organization.

Regardless, agile can be a powerful way to create results for a business, but only for those who take the time to diligently follow through on its core ideas and practices.