Agile Methodologies

Many (most?) agile guides start with a description the various methodologies, and I think that’s bad. It’s backwards. The methodologies are useful for:

  1. Getting started with your practice of agile (and then adapting it to your situation)
  2. Finding ideas to solve a particular job/problem you’re grappling with (ex: How might I integrate a part time data scientist into the team?)

Particularly for #2 above, you need a point of view on what you’re trying to achieve and why before you worry about what a given methodology says.

What they’re definitely not good for is mastering a fixed orthodoxy and then focusing your practice of agile on trying to cohere to that orthodoxy—yet this is the role that many of these methodologies end up serving in actual practice. That’s bad for obvious reasons, not the least of which is pretty much the exact opposite of the agile tenet of ‘Responding to change over following a plan’.

If you’re a Scrum enthusiast (or similar), please don’t be mad. It’s not that I don’t like Scrum—I’m just not as into it as you are.

These methodologies are a useful starting point for many practitioners and, regardless, you’ll need to have a basic reference understanding of them for items you’ll read and discussions you’ll have around your practice of agile. I’ve covered three of the most popular methods below.



Scrum actually precedes the Agile Manifesto (2001) by quite a few years, having been introduced by academics in the 1980s. It was later taken up by a group of thought leaders in the ’90s, further evolving in the ’00s to support agile. It now has multiple institutes supporting it and offering certifications.


While exact figures are a little murky (partly because many companies use multiple methodologies), anecdotally I can say that Scrum is by far and away the formal methodology I see most out in the field.


Much of what agile teams do today stems from Scrum, even if they don’t explicitly practice it. Examples include the daily standup (or daily scrum) and the roles of product owner and scrum master (I much prefer ‘agile coach’—scrum master evokes the Stanford Prison Experiment for me). The product owner is the lead on supplying input from the user perspective—organizing story writing workshops, for example, and answering questions about user stories.



Extreme Programming (XP) was created by Kent Beck and articulated in his 1999 book Extreme Programming Explained. Relative to Scrum, XP is more focused on how code is actually written and tested.


While probably not as widely deployed as Scrum, many of its practices are well liked and widely practiced by developers. Examples of this are pair programming (programming in pairs), test-driven development, and an emphasis on continuous integration.

“Doing agile well is about choosing, testing and iterating on the practices that turn out to work well for your particular project and team.”


Many of the practices above are adopted and practiced by development teams and, in practice, it’s usually the developers themselves that are most influential in deciding to adopt these practices. This makes sense (I would say) because the practices deal with their work at a very prescriptive level.



This practice originates from work on Lean Manufacturing whose goal is to minimize work-in-progress and build on a just-in-time basis (among other things). It has become popular as a method


example of the kanban methodologyI hesitate to call the kanban board for tracking user stories (and/or tasks) ubiquitous, but I sure do see it a lot—you may have as well. As a general housekeeping tool it works well.


While the kanban board is popular, the really high functioning practice is self-organizing around flow. That means the team works such that work items move from idea to deployment really quickly and don’t stack up at any choke point in the process. This is closely tied to the rapidly growing practice of continuous delivery where the delivery pipeline is closely managed not just for flow but for consistency and automation.

Closing note: Kanban is not a fully articulated SDLC (software development lifecycle) methodology like Scrum or XP. It just doesn’t have all the plumbing articulated. For reasons I still don’t fully understand, there are a lot of ‘Scrum vs. Kanban’ articles out there. Kanban is something you would practice within, say, Scrum, but not a direct alternative to it.

Now that we’ve discussed the methodologies, we can talk about the fundamental jobs that are part of any software/digital development and how you can improve at them.


See why IT Teams


Track all your projects – Free for 30 Days