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:

• Break work down into small units, organised into a hierarchy as needed. This means work at the lowest level is either done or not done - we do not want to talk about 30% done, for example
• Use a backlog of work that might or will be done. Understand and maintain it properly. A good backlog replaces (or relocates) much of the activity we associate with 'planning' in older approaches. See more about the importance of backlogs
• Do not commit to delivering the smallest units until they are fully understood, are known to be worth doing (valued) and prioritised. For preference, ensure any pre-requisites or dependencies are satisfied before the work that rquires this is started
• Work as a team, with clear working practices and shared, visible decision-making. Avoid hierarchical work structures (as opposed to hierarchical work) by devolving decision-making and responsibility as far as possible
• Regularly review how we work - what went well and not so well - and see what we can learn to keep improving things

{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:

• Sprints - the team time-boxes work into fairly short units (normally 1-4 weeks). Working as a team, it is decided what to prepare or deliver in a given sprint. This involves setting sprint goals and then agreeing the work items to be delivered in that sprint. It rarely works out exactly as planned, but the short sprints minimise deviation from the overall plan and facilitate feedback and adaptation of the solution in response to user feedback. This is managed by a set of defined 'ceremonies'
• Ceremonies - these are whole team events which provide a structure within which everyone works. This is helpful for ensuring people work together and understand their contribution to the overall result. All ceremonies should be concise and focussed - spending a lot of time on irrelevant meetings is not being agile. The key ceremonies are:
  • Standups - daily. Everyone tells everyone else what they have done since the last standup, what they are planning to do before the next standup and raises any issues which are slowing them down or where they need assistance to progress. About 2 mins per person is a good target
  • Backlog refinement - once or twice per sprint. Look at everything in the backlog, decide what do do about it (e.g. refine, delete, break into smaller bits, add something new, set values and priorities)
  • Sprint planning - start of each sprint. Look at the backlog and decide what we can commit to delivering in this sprint.
  • Sprint review - end of each sprint. Check what we intended to deliver vs. what we delivered. Understand why we missed the target (you almost always do) and what we can do to make it better
  • Sprint retrospective - end of every sprint or couple of sprints. Look (as a team) about how things worked and what we could change. This is not the same as a sprint review because it focuses on general issues, not specific pieces of work. It is important that issues from a retrospective are turned in to actions that lead to change, othwewise is is just lip-service to agility and not delivering the value of agile
• Metrics - when we are sprinting, there are certain basic metrics we can use to inform the team about how delivery is going and help with learning to improve things. These work because sprinting is a time-boxed process. All sorts of other metrics might be appropriate for different teams, but generally we can use:
  • Work delivered in each sprint - how many of our work items we completed
  • Commitment vs. delivery - how much we planned to do as opposed to how much we actually completed
  • Blockers - how much of the work we committed to that cannot be completed because of factors which are not under control of the team (e.g. external dependencies)

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.

• Backlog - there is still a backlog of items, some of which must be ready to work on
• Each individual has a capacity (number of items they can work on) and only works within that capacity
• When an individual completes a piece of work, they free up some of their capacity and will then pick up a new piece of work from the backlog

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:

• Regular backlog maintenance is essential - and a team activity
• Review - the team needs to get together on a regular basis to review progess and do a retrospective to reflect on issues so that they can improve
• Metrics - since we are not time-boxed, different metrics are appropriate. The most common/useful is throughput - how long it typically takes to do a piece of work (and how that relates to how long it was expected to take) and how many work items are completed in a given time period

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:

• Only do what adds value - do not do things just because you have always done them that way or because it seems like a good idea. Make sure what you do actually contributes to what you are wanting to achieve
• Identify and eliminate waste - Seems logical, but it is careful to be clear what you mean by 'waste'. In manufacturing this can bequite well defined as material which is purchased but not used or parts which are created but do not get used in a final product. This does not necessarily apply to all areas where you might apply lean. In particular, waste is well defined in lean manufacturing because the design work happened before the manufcturing. If we are doing just-in-time on the design process (as we do in agile to maximise responsiveness to user needs) then there will always be things that contribute to the final product in an indirect manner e.g. exploring different options, doing rapid prototyping, carrying out research. These things are not waste. It is important to be clear about what you mean by waste in your context
• Work 'Just In Time' - Do things at the appropriate time for when they are needed. This does not mean 'at the last moment'. It requires knowing about things like lead times and dependencies. See Just in Time to learn more

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:

• Do not expect to pick one methodology and apply it across a whole organisation. Different methods are more suitable for different contexts and different parts of a larger organisation {See articles on organisations}
• Do not expect to take a methodology 'off the shelf' - there is a lot of work involved in making even a commonly used method fit with the needs of your organisation to gain maximum benefit
• This is not a 'once and done' decision. YOu might pick the most appropriate methods for now, but expect to continuously evolve and change these methods as you learn more and become better at agile your context
• Any one of these methods alone (or even a combination) will not be the whole solution. There are other aspects which will require transformation outside the basics covered in these methodologies

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):

• What sort of work is it? Project-based work is planned and managed in a different way to response-driven work (e.g. live support teams)
• What sort of time units make sense as the smallest ones to work in? Activities where the smallest components take weeks (either due to effort involved or awaiting things from others) are unlikely to benefit from scrum approaches, which require short time lines with visible progress
• Do the team have control of the whole cycle from concept to 'delivered to customer'? If not (e.g. some things depend on other teams or external partners), the scrum is probably less relevant or needs to be adapted carefully
• What levels of the hierarchy of work/organisation do we need to consider? While tight sprinting can work well for small teams, it makes less sense when you are working across multiple teams engaged in diverse activities (and working with different methods, potentially). As we get to more abstracted levels of an organisation, short sprints become untenable so we either go to very long sprints (which greatly reduce their value) or go to a non-sprint approach (but still with some sort of cadence of activities)