Technologists love acronyms and that can be construed from outside of IT as obscure terms for processes, systems, and projects. It’s true that technology teams and partners can seem to be speaking a different language at times, but this is really no different than any other profession.

Doctors, plumbers, teachers, accountants – they all have a shorthand that they use with one another, a common language that can abstract complicated concepts that are understood by others working in the same field.

When viewed this way, it doesn’t seem as odd that technology partners use their own terms. But it can make it difficult when you’re on the outside looking in and working closely with IT.

For instance, there are a number of ways – or methodologies – that technology teams run projects to effectively and efficiently keep project teams on track and moving in the right direction. One team works as a Scrum team, the other is Waterfall. Understanding these different types of project management can help you become a better partner to your technology team, and in turn, help them produce a better end product.

Related: The Basics of Domain Driven Design

But First – What is a Methodology?

The Project Management Institute – or PMI – defines a methodology as “a system of practices, techniques, procedures, and rules used by those who work in a discipline.” They proceed to further define it by providing examples – which doesn’t really help if you still don’t understand what a methodology is.

You might be tempted to think of a methodology as a roadmap, based on that definition, but it’s not. Instead, if we want to keep with the map analogy, it’s more of a way of figuring out how to come up with a map.

For instance, if you’re going on a road trip, you have a few possibilities on how to plan your route. You could pull up Google Maps and type in the address. You could ask a friend for directions. Maybe you’re old school and want to pull out your trusty Rand-McNally road atlas. Or perhaps you have all the time in the world and you’ve decided to just drive and see where the adventure takes you.

These are different ways to create your roadmap – some more efficient than others, some more effective depending on the number of drivers going on the trip. These methods let you define a path to reach your goal – arriving at your destination. This is, in essence, what an IT project methodology is – a means of defining how you get from point A – needing a project developed – and point B – having a technology product that meets your needs.

Common Methodologies in IT

Understanding some of the differences between these ways to define a project path will set up your expectations on what to expect during the development lifecycle. Like our road trip example, a long trip with multiple drivers and a destination that may change on the way requires a different wayfinding process than a short trip to meet a friend somewhere new. There are strengths and weaknesses to each, depending on the project and the business situation.

Waterfall

Waterfall is one of the oldest and more traditional of the common methodologies. It stems from the days when development projects were viewed as a single, linear path to achieve the project’s goal. If you’ve heard technologists talk about Waterfall, it may have been disparaging.

That’s because Waterfall fails to take into account shifting business priorities, and assumes that what was defined at the beginning of the project will not change and that the project is highly defined from the outset.

In a Waterfall process, there is an initial planning phase, the length of which is proportional to the complexity of the project. The entire project must be defined and documented prior to beginning work, and once development begins there is little room for flexibility. In fact, in many cases, the stakeholders don’t see the product until fully complete. This can certainly lead to anxiety on the part of the business and stakeholders, as well as resulting in an inflexible path to completion.

However, Waterfall can sometimes be an appropriate choice for small projects with few team members, although Kanban (below) should be considered for these situations instead, as it answers some of the shortcomings of Waterfall.

Agile

So, let’s be clear. Agile isn’t ACTUALLY a methodology. It’s a set of principles for developing software. But given how ubiquitous it has become in being called a methodology, it would be noticed by its absence in a list like this. These principles are defined in the Agile Manifesto.

What Agile is, is a flexible build process that heavily relies on iterative development cycles that are intended to create working software instead of reams of documentation. Because the intent is to have a working piece of software at the end of each cycle, changes in priorities and business needs can be taken into account along the way.

Despite being a set of principles instead of an actual methodology, Agile is generally used as an umbrella term for methodologies that marry up well with Agile concepts.

Scrum

One of those methodologies that frequently falls under the umbrella term “Agile” is Scrum. Even Scrum isn’t what we’d call a pure methodology, but more of a framework for projects. It defines roles, tools, and meeting guidelines to keep projects efficient and deliver quality software through iterative development cycles.

Two pivotal roles in Scrum are the Product Owner and the Scrum Master. While not the only roles on a Scrum team, many of the process’s activity occurs with one or both of these individuals involved.

Without oversimplifying too much, a Product Owner reviews, approves, and prioritizes a projects user stories – Scrum’s version of requirements. The PO then organizes these stories into sprints – short development cycles intended to produce functional features at the end of the sprint.

The Scrum Master, on the other hand, is more involved with leading the development team, in a sense. The Scrum Master leads daily meetings called scrums – a term borrowed from the sport, rugby – in which team members can discuss work and roadblocks and get help from the team. They also lead demos of what was produced during a sprint, and a meeting called a retrospective, in which the team discusses what worked and what didn’t during the sprint. These retrospectives are important as part of Scrum’s continuous improvement process.

Scrum can be a highly effective development process for teams doing ongoing work on software, or in cases where flexibility or high involvement from stakeholders is critical to project success.

Kanban

In some ways, Kanban is the marriage of Waterfall with Agile principles – a structured process that also focuses on lean development principles, intended to increase the efficiency of a project team.

Continual release is a main component of Kanban, with subsequent releases happening quickly and with increasing quality. This is done by limiting work in progress, continually evaluating improvement opportunities, and understanding the “lead time” – the time between when a feature or change is requested and when it can be released.

Project managers in Kanban use visual workflows – or Work-In-Progress (WIP) boards – making clear what is waiting to be done, what is in the process, and what is completed.

Kanban is particularly effective for software in production needing maintenance or additional releases, but can also be very effective on shorter lived and new projects.