As you search for a development partner to bring your company’s application to life, it’s important to evaluate not just a potential partner’s ability to code, but their ability to run and deliver projects. You already know you need expert support in the actual coding of your app–that’s why you’re reaching out to a development partner. But in the face of challenges like aggressive deadlines, stakeholder expectations, and pressure from investors, you also need a partner who knows how to structure a project and run a development team in a way that delivers results.

There are a many ways to organize software projects, each with their pros and cons. Below, I’ll break down a few common methodologies, and share smarter ways of working that enable your team to remain flexible.

Methodologies for Software Projects: Waterfall and Agile

Software development methodologies are generally organized under two broad systems: Waterfall and Agile. Waterfall projects are built along a linear progression through each phase of development. Agile, on the other hand, has become more popular as a more iterative way of working, built around regular, short production “sprints”.

Based on 12 concepts taken from a core manifesto, the Agile framework includes two primary subsets, Kanban and Scrum. The Internet is full of articles that break down the specifics behind these approaches (here’s one I like); rather than recounting those details, let’s discuss how these processes relate to the best way to work on your project.

Why Waterfall Doesn’t Work—But Refuses to Die

Rooted in manufacturing, Waterfall is an outdated, inefficient methodology based on assumptions about software development that don’t play out in reality. Fundamentally, a Waterfall framework relies on the assumption that a development team can know everything about a project in advance when planning a schedule, which is unrealistic in the real world.

Every person involved in software development projects is human, and no one reliably can predict the development, design, or communication cycles that inevitably change during a project. However, Waterfall codifies guesses about how long each stage will take into a six-month-or-longer process. This inevitably leads to missed deadlines, unmet dependencies, and development that’s inefficient and ineffective. A hallmark of a Waterfall project will be a frustrated team lead at the end of the project upset about why things didn’t go according to plan.

Despite all of its proven ineffeciencies, the Waterfall model just won’t die. Executive leaders often want a perfect diagram of what will happen in a project and in what order, typically laid out in a Gantt chart. And while Waterfall provides those details, that kind of rigidity doesn’t work in software development.

Agile: A More Flexible Option (In Theory)

As its name suggests, Agile was designed as a flexible–or more agile–development methodology. Agile focuses on short sprints of development with the freedom to shift requirements along the way. However, from our perspective, what was intended as a set of ideas for how teams can remain lithe, flexible, and agile–notice the lowercase “a” in “agile”–has evolved into a rigid set of practices tied to dogmatic terminology. I like to call this the “Agile Industrial Complex.”

There are many useful tenets of the agile philosophy that are framed as ideas and suggestions, but which uppercase-a-Agile has codified into rigid standards and structures. Teams meet for daily standups and weekly or biweekly sprint planning and retrospective meetings–both great ideas, supported by agile philosophy–but these meetings are often held with a strict structure and an inflexibility of application that completely bely the core concepts of agile. Often, the Agile coaches who implement these terms and processes suggest in their pitches that you can implement their methodology without meaningful changes to your team, expectations, or project timeline.

In effect, Agile implementations often apply many of the same constraints on your team’s work as Waterfall does, but simply wraps them in a different language. Agile can become a variant of Waterfall development by another name.

Scrum and Kanban Apply Varying Rules for Agile Development

Scrum is a more regimented offshoot of Agile. A project leader called the “scrum master” guides teams through planning, standup meetings, and retrospective phases of a project. Ultimately, Scrum is a common offender of what I described in the previous section: a rigid system that’s touted as being more flexible than Waterfall, but with the same problems in the end.

In theory, Scrum can be used in a truly agile way. But the more systemized each project stage becomes in estimating work “velocity,” or what can be delivered in a sprint, the more Scrum starts functioning like a Waterfall process.

Kanban is not technically an offshoot of Agile, but rather an existing project management workflow that fits neatly into agile values. Kanban has been around since the 1940s, and is centered around a board that categorizes tasks in columns like “to do,” “in progress,” and “done.” At Tighten, we appreciate Kanban’s focus on flexibility and iteration; it seems the closest of any “framework” to the core ideals of agile. More important than anything else, to us, is a tool that flexes as requirements change, and we’ve seen that to be true with Kanban more than any other “framework.”

Manage Software Projects in a Truly Agile Way

To be clear, we don’t describe ourselves as Kanban practitioners—we simply attempt to work in an agile way. Much like the original agile manifesto, our workflow is about people more than processes. Agile, Scrum, and Kanban may not suit the needs of your app or your startup. What if your team could embrace agile principles without the rigidity of following a single framework?

When you talk to a development agency about being agile, you should be thinking about the original definition of the term. You and your development team don’t have to conduct a daily meeting, and you don’t need a Scrum master to be agile. But you do need to build your teams and processes in ways that protect their agility.

Like an athlete, developers should be light on their feet and able to change direction quickly as conditions demand. Your team should be able to work together and communicate efficiently without being governed by a specific system. And when we talk about this at Tighten, we like to think about agile with a lowercase “a.”

Find a Development Partner Who Embraces Agility

At Tighten, we’ve written our own manifesto about how we work. The manifesto itself may evolve over time, but it’s built around the core concept of remaining agile in each new client context. Ultimately, we want to ensure our workflow is flexible enough to support each client and their particular needs.

For example, by default we use Trello to facilitate Kanban lists for our projects. Our process often includes weekly check-ins where we talk about what we completed last week and what we’re doing next week. At any point, our process allows us to remain flexible and define what’s most important for the project and our client in real time.

However, we don’t always use Trello, and we don’t always have daily or weekly meetings. Each client’s needs are different, and we adapt our workflow to suit those needs—even as they may evolve over time. When your development partner remains agile with its workflow framework, you can create an adaptable, efficient, and innovative process. Agility provides the real foundation that sets your app on a path toward success.

If your start-up or other business is looking for guidance on how to optimize the way your project will be built, we should talk. We can ensure your team has the expertise and agility to produce the right results.