So many buzzwords in one title - what has gotten into me? Years back, I remember someone endorsed me for Agile methodologies on LinkedIn. I was like: “Huh? Really? Am I good at that? What is that exactly?”. I have never been a fan of labels, nor I am now, so even if I did work in agile ways, I did not use the word agile to describe it. Now knowing way more about various methodologies and ways of working, I would like to give a little heads-up about them (caution alert: in my Quality Foundations series I will be mainly concentrating on practices more known in Agile/Lean/DevOps as in my experience they are more related to higher team performance). It is important to understand what methodologies you work or want to work with, and, why. There is a context in the company on why certain methodologies were chosen (it could have been history, limitations, company goals) - understanding that can make you better equipped to achieve success within the company and even drive change if the time comes. It can also save you a lot of frustration if you are clear about the why on your methodology choice: there are advantages and disadvantages for all. This post will be a very high-level overview of how I see these methodologies including some bits and pieces of what I like about them.

We started with a concept of quality and how much it depends on the context you work in. It’s the same with methodologies, your use of them will differ based on your context. Some people have “holy grails” of methodologies that they prefer more than others. I also prefer some better, but may not label them as a methodology. Some ways of working match my work style, but they may not match yours. I lean towards more modern quality analysis concepts and this is what I will concentrate the most in the Quality Foundations series. However, increasing our understanding of these processes, even if they’re not our preferred choices, will help us work more efficiently.

You may feel overwhelmed by the choice of methodologies around, I do, too. I also question if I follow them in a certain way (I am not sure if my Agile methodologies endorsement is 100% true at all, some things I do may not be considered agile). It’s okay not to know all the nitty-gritty details about methodologies. You don’t have to be an expert on any of them. Read about them, get to know them better, keep an open mind, but choose what you want to try out and prefer yourself. There may be “ideal” definitions, but in reality, most companies work in a mixed state of them. I’m yet to witness purely Agile projects.

Usual opposites: Agile & Waterfall

Agile vs. waterfall drawing My simplified drawing of Waterfall vs. Agile

For a while now, waterfall has had a bit of a bad rep: isn’t it what creates silos and makes companies/projects stay behind? Well, it is not just 0 or 1: waterfall projects where stages go one after another with a big bang release can be useful for certain domains especially regulated ones.

Agile methodology is often what comes to “save” waterfall projects by trying to have more autonomous teams that release faster, smaller pieces of work. It started with a definition of the Agile Manifesto, which encourages a more collaborative nature of work. Agile practices are about people and how to help them work better together.

The funniest part is that often companies are never 100% one or another methodology: there even are mixes of these two “opposites”. I have seen occurrences of scrumfall (scrum is a common agile framework that you may recognize from daily standups, and timeboxed iterations called sprints, to complete a certain number of work items). It’s common to see Agile practices used in traditionally waterfall projects.

I have heard way too many times some failures (like a bug in production) being blamed on agile. What matters here is to realize that:

A certain methodology won’t suddenly solve all of the company’s problems. Do not use labels as a scapegoat or an excuse for things you still can improve.

If you want a perfect example of methodology, you also may need to create a perfect environment for it. The reality is that there’s no such thing, especially when it comes to digital transformations.


Lean manufacturing is a production method derived from Toyota’s 1930s operating model. It gained quite some popularity in the software development world, as its principles proved to be applicable and beneficial. Kanban is one of the Lean manufacturing methods, which was the preferred way to organize work items, in many teams I’ve worked in. There the team’s board would have a queue of work items to be done rather than a goal to complete certain items in a timeframe. Kanban is often recognized by simplistic columns of To Do -> In Progress -> Done.

The Lean methodology concentrates on value streams and efficiency, which is the reduction of waste. It values eliminating waste and embracing continuous improvement. The concept of activities to achieve this is called Kaizen.

Kaizen is extremely close to my heart as a QA. Work done by a good QA can be hard to measure. By spotting and helping remove bottlenecks, which impact efficiency, we’re helping improve the overall work functions and involving everyone.


DevOps is a set of practices that combine Development (Dev) and Operations (Ops). DevOps is complementary to Agile software development.

Stakeholders seeking digital transformations tend to put all the buzzwords together and DevOps is likely the most popular one to be paired together with Agile. DevOps primarily aims to have the ownership of the operational part of delivering software not siloed, but part of the development team. In short: “you build it, you run it”. This also comes with practices like Continuous Delivery.

Using DevOps practices leads to a much faster pace of software delivery, which can result in some questioning about testing’s role. As a QA, I see DevOps as a chance to get involved all over the story lifecycle. Dan Ashby’s illustration of where we test in DevOps depicts this well:

Testing in DevOps drawing by Dan Ashby Testing in DevOps drawing by Dan Ashby

A great book to learn more about this is A Practical Guide to Testing in DevOps by Katrina Clokie. I like DevOps because as a QA I can grow into many more areas than just testing. If we need to consider quality in every stage, then it means that as a QA I need to learn how to better contribute to pipelines, why monitoring and observability matter, or how to spot and remove bottlenecks development teams are facing in product delivery. This is why I have started the Quality Foundations series so that I can share a little bit of all things quality.


There are multiple ways to deliver software development projects. Getting to know the way your company or team prefers to work can be extremely beneficial, but take it with a grain of salt: there is no perfect methodology or practice.

You don’t need to know all of the nitty-gritty details about each methodology. Each has advantages and disadvantages but keep an open mind. Learn what practices/principles they have, and choose for yourself.

There may be something useful everywhere.