The Agile Object Model

The Agile Object Model2018-04-07T12:07:26+00:00

Like any methodology, Agile incorporates many types of entity.

They’re identified in the following diagram and explained in more detail below.

Agile Component Model


The overall Agile lifecycle governs development at every level:

  • At the level of the overall Product – typically a business function, operational area, etc.
  • At the level of the Release – typically the release of substantial new value and functionality.
  • At the level of the individual Iteration – during which the stories by which an Agile development defines what it will deliver are actually translated into value-adding, working software.

The practice itself links together the various Practices, through which work is actually carried out.

Crucially, the Agile lifecycle is not a rigid, linear process. Agile expects the team to consist of disciplined, experienced professionals who use the Agile lifecycle constructively, like a tool they find useful, not a machine they have to submit to.


A ‘Practice’ is a set of step-by-step instructions on how to perform any of the basic tasks Agile includes.

Look at any of the Practice pages on this site and you will see the same overall structure:

PurposeWhy are you carrying out this practice? What is it for? What will you accomplish?
Exit conditionsWhen is the task or practice complete?
Entry conditionsWhat needs to have happened before you can start this practice?
SLAWhat are expected schedule, cost, quality, performance, frequency or other criteria for deciding whether the practice has been carried out properly?
Issues & risksAre there any special things you should be aware of or concerned about when carrying out this practice?
Process mapFrom a top-level point, what are the main steps in carrying out this practice?
ProcedureFor each of the steps in the process map, what are the detailed instructions? Who leads the activity, who else is involved, what will they produce at each step? How will they produce it? What is basic good practice for each step?

Note that it is through this model that the detailed products (and therefore templates) are identified and the responsibilities of the various Agile roles (plus many ‘extended team’ personnel) are defined. Likewise for the tools. In fact, a Practice can be regarded as a list of instructions explaining which role uses which tool on which template to create which lifecycle product?


By the standards of traditional methodologies, Agile is surprisingly short on templates. That’s because, by shortening the overall delivery timescale to weeks, reducing communications as much as possible to face-to-face conversations and localising decision-making, the need for anything that might need a template has all but disappeared. Formal plans, elaborate ‘Business Requirements Specifications’, detailed technical specifications, etc., have all become largely unnecessary.

Not all documentation has gone away. There are still some circumstances in which formally structured documentation is needed:

  • Early in the introduction of Agile, it can be very helpful to include ‘stabilising’ documents such as a Release Charter, so that, when they forget what they are trying to achieve in the rush of development and delivery, the team can remind themselves.
  • If any part of the Agile lifecycle remains outside the Agile team (e.g., UAT), it may be useful to have an agreed definition of what each side will do, how, when, etc., plus written mechanisms for meeting, communication, problem-solving, escalation, and so on.
  • If supporting the delivered system will be the responsibility of another team, they will not be able to take for granted the same level of knowledge of the design, code, testing, etc. as the Core Team. So there is likely to be a basic suite of support documentation they need to do this work.
  • In large-scale Agile implementations, it can be very helpful to establish some basic ‘stakes in the ground’ that represent the core agreements on how the teams will work together. Likewise for any central programme-level PMO or governance bodies.
  • Other (often online) tools are also widely used, handling things like workflows, progress reporting, management tasks such as risk management and technical activities like code control and automated testing. Perhaps even more than the quasi-paper templates produced with word processors and other desktop tools, getting real value out of such tools demands careful design of the underlying templates.

Like any other formal documentation, the underlying templates need to be properly thought through. But the Agile discipline of challenging everything should make itself heard. For example:

  • Many organisations require the production of complex suites of support documentation, even though support teams may seldom refer to them – even for large-scale systems.
  • Central project and programme offices may require standard reporting, with reference to topics such as ‘phase completion’ that are not relevant to Agile. But more than simply adjusting the milestones and other events at which Agile teams report, Agile also assumes that many decisions can be made much closer to the work, so reporting even the Agile equivalent of milestones will often be redundant.

In such cases, even if the demands cannot be completely removed, they may perhaps be rationalised.


At each step in each practice, the practices define who is responsible for each step – either leading it or otherwise participating. The sum total of these responsibilities consists of a role.

Although, in Agile, roles are only loosely defined, they are as important as in any other methodology. But at the same time, they are loosely defined, and also are exceptionally few in number. In some flavours of Agile there are only 3 – Product Owner, Iteration Lead and Developer. The many other ‘flavours’,  such a tester and business analyst, are eliminated. It’s not that the work testers and BAs normally do is no longer done but because no rigid distinction is drawn between the roles. This is deliberate. Agile aims to be as flexible as possible, to the point where anyone might be called on to perform almost any task in an iteration.

So, it is almost better to ignore the role titles and focus on the responsibilities. These are the steps in the practices that need to be completed, but Agile doesn’t really care who does them. They just need to be done, and it is up to the team to ensure that they are done the best way – and not worry about exactly who does them.

The roles Agile identifies are not organised into the usual hierarchies. Except that the Product Owner owns the product the team is working on and decides what the final priorities are, the team members meet as equals, and interact on equal terms.


Agile cries out for automation:

  • of technically tasks such as build, integration and testing;
  • of management tasks such as risk, change and dependency management; and
  • of workflows.

Not only do you get the usual benefits of automating anything but the massive deprecation of documentation and other physical outputs in favour of pure activity means that a far greater proportion of all work can in fact be based on, and driven by tools.

So there are few points in the Agile lifecycle or within individual Agile practices that tooling should not be considered a high priority. They are scalable to any level of organisation and technical complexity. A taskboard, for example, might consist of anything from sticky notes on a spare wall to a comprehensive electronic system, with equally extensive dashboard, reporting and tracking capacities.

What is crucial in each case is to scale the tools to the problem you’re trying to solve. Electronic systems can be extremely powerful, but is it power you need? Such systems can also limit your flexibility. If you decide you want to track some small detail of each task your existing tool doesn’t allow for, how will you do it?

So choose your tools as you would anything else in Agile: with an eye to transparency, adaptability, responsiveness to change and, always, Quality First.


It’s not enough to know how to do the various things Agile asks of you; there is also a truly critical question of how you approach work. What do you bring with you when you start a new project? What is your attitude? What reusable techniques will you apply? What is you mindset?

This raises the question of the Agile disciplines.

There is no predefined set of Agile disciplines. What there is is an expectation that you we will work in a self-disciplined manner, and a mass of experience of what that takes in an Agile environment. Hence the entirely provisional list of disciplines described elsewhere on this site. Bring those with you to work every day, and Agile will seem the most natural thing in the world.

Leave A Comment

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

Toggle Sliding Bar Area
Want to do more than just build systems?