Agile Coach Online

Expert support on demand

Agile Coach Online Logo

Popular approaches to Agile

Here are some words you often hear associated with Agile.

{{Image - }}

There are 2 interesting things about this:

  1. You do not need to adopt any of these words or practices in order to be agile
  2. Adopting any of these words or practices does not make you agile (e.g. adding 'product owner' to a person's name/role or renaming your teams as squads has no value at all)

These are all techniques, methods and frameworks you might use on your agile journey, but they are only practical things to assist you on the way to true agility. When you achieve true agility, the individuals, teams and organisations are all thinking in an agile way so anything they do is automatically approached in a agile way.

Thinking in a agile way is the fundamental point - any of these things can help you become more agile, but only if you get the right way of thinking. While this site does not discuss these approaches in detail, it is worth having a quick summary of many of them so you know why they may or may not be usedul in your agile development.

Beware of management consultants bringing frameworks

In large organisations there is a history of using management consultants. Sometimes they are helpful, but a lot of the time they are not. Many management consultants have jumped on the agile bandwagon and sell variations on what they always did but use words from Agile. Exercise caution. Although it is not explicity said, some of the principles of agile can be interpreted as 'avoid managmement consultants selling you the same old stuff in a new wrapper'.

This is a particularly true of 'frameworks'. They are appealing to a large organisation because they make it easy to look like you are being agile while actually making few real changes. This means you can look agile but not get any of the real advantages that true agility delivers. Be very wary of frameworks - especially those which retain the hierarchichal structure of the organisation. Hierarchical management is anathema to effective agility.

Scrum, Kanban and Lean - the common paths

These are the most common approaches to Agile. Each has it's place and can help you become more agile, but they are not inherently agile in themselves. Different methods tend to focus on the needs of different working environments (including the sort of work, the goals of the organisation and the individuals participating). It is quite common to evolve through methodologies over time, but ultimately each team and organisation should end up with what best suits them.

Commonalities

All agile approaches follow the general principles and guidelines identified in the Agile Manifesto which we explain in more detail here. Different methods focus on differnt aspects, but there are certain commonalities (n addition to what the manifesto says). These can be loosely grouped as:

{Some pics would be nice}

Given those commonalities, let's look at the 3 most used methods for being agile: Scrum, Kanban and Lean.

Scrum

Scrum has been around since the 1990's (before Agile had a name). It is a very structured approach so it is often a good way to start since it provides organisation and team responsibility rather than relying on individuals to be totally agile from day 1. It is often explained through diagrams that look something like this:

{pic}

The key ideas are:

To learn more start with the Scrum Guide - this is pretty much the definition of Scrum approaches. We have more to say about scrum methods but they go beyond these open resources {link to client area}.

Kanban

{{Pic}}

Kanban originates a long time before Agile had a name - back in the 1960's. It has been adapted since its origin and is probably the most popular approach to Agile.

Kanban is very easy to do badly - lots of people see it as just a sort of to-do list. It is very hard to do well because it relies on each individual being truly agile and taking full responsibility for what they do (and for what the team of which they are a part does).

The key difference between Scrum and Kanban is that Kanban does not timebox work into sprints with specific ceremonies and activities on a defined cadence. There are lots of cases where operating without a cadence is apporpriate, but it puts more emphasis on the individual. While still operating as a team member, each person has a lot more responsibility to behave in an agile way.

That is significantly different from sprints with team planning and commitment. Much more relies on the individual. However, some things are still team activities and cannot be left to an individual. Notably:

To learn more start with the Kanban Guide - this is pretty much the definition of Kanban approaches.

Lean

Lean started in the 1940's with car manufacturing. It is not as clearly defined as Scrum or Kanban. Lean is not really captured by the values and principles of the Agile Manifesto, though it is often given principles which clearly relate. Basically, it comes down to:

There is not a single, independent source of information about Lean, but www.ean.org is a reasonable place to start.

How to pick an approach

A few main points:

An important word in the above is 'context' - understanding this is essential to making good, informed decisions about your approach to agile. Here are some factors to consider (at individual, team and oganisational levels):