Overview of Agile

Overview of Agile2017-10-24T15:16:19+00:00

If you’re not familiar with the Agile lifecycle, you may find the following helpful.

  • For a sense of Agile’s core delivery process, click on The core delivery lifecycle below.
  • For the wider picture of how Agile manages not just technical development and deployment but the whole process from product vision and strategy through to final deployment, click on The Product, Release & Iteration layers.

The Agile iteration lifecycle is the most basic process in the whole of Agile.

It looks like this:

In the most general terms:

  1. The Core Team takes Stories (the basic units of delivery in Agile) from the Backlog (a simple catalogue) based on their agreed priority.
  2. These Stories are then implemented by developers and users collaborating closely.
  3. Each day the team meets to report progress at the Daily Stand-Up Meetings and, if appropriate, flag up any issues they face.
  4. As code is developed – using test-driven development and refactoring – , it is continuously re-integrated back into the mainline, to ensure that inconsistencies and breaks are identified as quickly as possible.
  5. From time to time (maybe once or twice per iteration) the backlog is reviewed to see if, given the team’s most recent experience, it needs to be refined in any way – e.g., do stories need to be re-estimated or re-prioritised?
  6. Usually towards the end of the iteration (though it may be more often), the team conducts a ‘Showcase‘, at which the stories implemented as working software are demonstrated to the stakeholders who asked for them.
  7. Completed stories are then deployed to users, or at least stored in a state ready for deployment.
  8. The team holds a Retrospective, at which it discusses what went well and what could have gone better, and agrees appropriate improvements they been to make.

The key steps in this cycle are explained in more detail under the Iteration menu, and the key tools and techniques are detailed under Tools. The tools the video mentions are described and explained under Tools. The whole process is fundamentally very simple, but there are plenty of reasons why organisations struggle to make a success of it:

  • The devil is, as always, in the detail. As you will hear all over this website, simple doesn’t mean easy.
  • There are quite a few new things to learn – especially if you come from a strong waterfall background.
  • Agile challenges some of the most basic assumptions about management and delivery from the pre-Agile world. And it’s not just about development – some challenge the most basic assumptions the roles of developers, managers, users and business teams.

But as the whole point of Agile201 is to make Agile as straightforward as possible, we are confident that you will find the answers to all these questions somewhere here!

Agile is a lifecycle and/or methodology designed to let organisations manage change easily and reliably.

You can think of the process as a whole as being divided into three layers:

The relationship between these layers looks like this:

Agile Lifecycle Layers

That is:

  • Each Product goes through a cycle of Releases.
  • Each Release is sub-divided into one or more Iterations, often carried out by several teams working in parallel.
  • Each Iteration aims to implement and deliver ‘Stories‘ – generally speaking, units of valuable functionality.

The last point is fundamental to Agile. Unlike with most other methodologies, new working software is not released only when the Release (or project) finishes.

  • In principle, Agile aims to deliver new working software more or less continuously – in fact, every time a Story is completed.
  • There may be circumstances when it is better to group Stories into batches for release. For example:
    • There may be good architectural or operational reasons why it is not optimal to release individual stories.
    • The organisation’s ability to absorb change may be less that the Agile teams’ ability to deliver it.
  • But generally speaking, although the Product-Release-Iteration model is like a hierarchy of nested blocks, delivery is intended to be as close to continuous as possible.

You can think of the Product-Release-Iteration model as a system of ‘Russian dolls’ – each level embedded in the one above:

Agile Lifecycle

This is what each of these key terms means. Click on the links in the left-hand column for more details on each layer of Agile.

Product Management
  • In Agile, a ‘Product’ is a major part of the business or organisation, often a product or service, but also possibly an internal function, an architecture or a support queue.
  • A Product is a (more or less) permanent component of the business, and supports the business vision, strategy and goals.
  • A Product typically has a Product Plan and a roadmap that identify the expected Releases – by scope, objectives, schedule, etc.
  • It’s usually regarded as good practice in Agile to have a dedicated Product Team for each product or group of related products.
Release management
  • Products evolve over time, passing through a number of versions as they are developed, updated, expanded and retired.
  • ‘Release’ is superficially the process of replacing one version of a product with another, but in practice it tends to be simply a useful unit into which a manageable number of Stories can be grouped.
  • In Agile, a Release is typically defined by targets and the delivery by an agreed selection of ‘Epics’, ‘Features’ and ‘Stories’.
Iteration management
  • Individual Releases are divided into Iterations (also called ‘sprints’).
  • An Iteration is a short burst of work – typically only a few weeks – in which a small, highly integrated team creates packages of working software that could be shipped for operational use.
  • Each of these packages of working software consists of a ‘Story’ – a brief description of some useful function or capability a real user, customer or other stakeholder values.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?