This blog post is for you, the well-oiled and very capable organisation that, for possibly the first time, has decided to engage in a technology project.

It might be redesigning your website, conducting a crowdsourcing campaign or building an online thingummyjig that will somehow Make Life Easier. Either way, you are embarking in a reasonably-sized software development project and are looking for capable professionals to help; maybe a web agency, a group of programmers or a technology consultant.

To your dismay, you realise that this group of individuals use words very differently to you: you’re being asked to design think, be lean and agile.

You’re concerned that there are hidden meanings behind these words, and you don’t know how they will impact you and your team.

Don’t panic, we’re here to bust some jargon.

There is lots of jargon. In its defence, it sometimes has merit as a shorthand between people who have already established that they know what each other is talking about.

More often, however, jargon is used by people who haven’t bothered to do the groundwork to establish mutual understanding. I apologise on their behalf and reassure you: there is no reason you should instinctively know what these terms mean.

There are relatively few key terms. Learning the key differences between these will give you a frame of reference to hang your nuances on. The ones I would recommend are:

• Waterfall
• Agile and
• Lean

Agile and Waterfall are almost polar opposites

Both of these are philosophies. There is no right or wrong; they just have different values.

• Agile puts a value on incremental learning and being able to adapt to changing circumstances. The proponents of agile recognise that the world is changing very fast and that waiting to have a perfect piece of software will likely result in said software being obsolete by the time it is released into the wild. As a result, agile projects typically release the software early, with a reduced feature set and then iterate on the project over a longer timeframe, making the software better with every release.
• Waterfall (sometimes called classic project management) puts a value on upfront planning. It assumes that you can know enough about the problem to be solved in advance in order to design and plan your project. You write a formal specification and deliver on it.

I say they are almost polar opposites, because there are two common misconceptions about these methodologies:

So, agile projects don’t have a plan?

FALSE: They just acknowledge that you are probably going to have to update that plan regularly. The best agile plans I have seen have a high-level plan far into the future and increasingly detailed planning for the nearer term deliverables.

So, you can’t change the plan in a waterfall project?

FALSE: Scopes can be changed in a waterfall project but there is usually a formal process involving getting a change request signed off. If you are trying to move fast and signoff is cumbersome, think twice about going this route.

Scrum, Kanban etc are specific project management styles within agile

My job here is to orient you in the words, not to tell you which methodology to pick. I can however point you to some primers if you want to know more. Here is KanBan, here is Scrum. You’re welcome.

Many people have very strong opinions on which of the above project management methodologies to use but:

1. Be aware that there are other methodologies besides Scrum and Kanban. These two are commonly practised examples.
2. Most teams adapt some methodology to their specific context: see ScrumBut. Some awesome methodologies are agile in philosophy, but don't even have names as far as I know.
3. There is no one size fits all approach to which methodology you should use. If you are working with someone who is dogmatic about their project management to the expense of pragmatism - GET OUT NOW!

Understand the difference between lean and agile

Lean is another philosophy, but it has less to do with project management styles. Lean is commonly jumbled into conversations with agile, but it is slightly different and deserves a section of its own.

Lean means “maximising value while minimising waste”. In other words: not doing things that do not bring value. That sounds pretty obvious, but not everyone does it.

The similarity to agile is that lean approaches also put an emphasis on learning. That’s why they commonly go together; you can be lean and agile.

Another term for lean discovery approaches

Some Design Thinking practitioners conduct what they call low-risk / low-cost experiments to understand whether or not to pursue a particular approach.

This terminology is actually more descriptive, but lean seems to be more pervasive.

An example of a lean approach / low-risk experiment

Let’s say you are considering starting a new mailing list for your blog. Before you go to the effort of doing all of the work writing the content, a lean approach would be to judge interest by putting a signup box on your website to see how many people sign up for it. If no-one signs up, you know not to go to the bother of writing it.

Summary

Now you know some pretty powerful words to talk about software management styles. Sure, it gets more nuanced but you’ll get pretty far with these words, so don’t panic.

Here’s a quick summary:

This post is a work in process

I continuously improve these posts as I learn more about a topic. Drop me a line at lucy [at] techtohuman [dot] com if you have any thoughts or suggestions.

Further reading

• The Sideways Dictionary on analogies for agile software development
• The key differences between agile and waterfall and the pros and cons of each.

Thanks to

Tin Geber and Nick Stenning for their ever-patient support and input on these posts.