ABCDE process

The main pattern

• Each named step contains a group of actions.
  • Each step "pulls" data from the previous step.
• Each line between the steps shows the transition and direction to the next step when all is well.
  • When an action within a step fails, the entire process restarts.
• The data already built, including errors, if any, remains for use in the next step.
  • Some data is kept, some data is discarded (eg. intermediate objects are no longer useful).
• In the "Adapt" step, the previous input is reused and the previous process state is analyzed.

( We'll stop here to keep the basics simple! )

Process Objectives

ABCDE main goals:

• Build on proven grounds.
• Deliver with quality.

ABCDE secondary goals:

• Clarity.
• Find fast the source of disturbance.
• Deliver as soon as possible.

Zoom in for details

Let's zoom in ... fast forward ... and ... stop here. Yes! The perfect place to catch up on what's important!

(...)

A cycle corresponds to an iteration of the product

Cycles:

• Cycle ABCD starts with Adapt step and ends with Deploy step.
  • When the Export step is executed, it is only bound to this cycle.
• When a next iteration of the product desired:
  • The data from a previous "ABCD" cycle is used as a base. If data from Export is also used, it Must correspond with the given ABCD instance.
  • Note: At the start of a new cycle, automated tests from the previous successful cycle should be added to this cycle's regression tests.

• eg.: Code, executed plan, test results, internal documentation, reports, public documents and manuals, packaged products.

In this case:

• It can only start from "Adapt" step.
• The failed action can be analyzed using: existing data, partially built data and the fail hints.
• The logic and actions can be adjusted for every step.
• After the analysis and adaptation part ends, the data from a previous successful "Deploy" step will be used as input.
• Restart, this time with a proper environment.

Steps

• "Adapt" step starts a new cycle:

  • Contains mostly human initial actions and decisions. However, automating some actions is preferable where possible.
  • Input: Either the project starts now from scratch, either the data from previous "Deploy" step is used as a base.
  • Output: Data, including instructions, rules and planning, new project structure, new code(in case of software project).
  • Output: product internal data, status, reports.
  • Pick next features and requirements which make sense for next product iteration.
  • Transform requirements into achievable atomic parts.
  • Plan how to implement.
  • Identify deliverables for "Deploy" step.
  • Decide for an eventual "Export" and identify deliverables for it.
  • Verify the assets.
  • Adapt or enhance project rules and conventions as necessary.
  • Plan and prepare testing and verification for this cycle.
  • These actions are usually at the end, here, but in other steps testing may be among the first actions.
  • Consider what, if any, needs to be changed in the other steps to Deploy as expected.
  • If all worked well, with no errors, the process is ready to continue and the data data is ready for the next step.
  • Apply and verify project rules and conventions.
  • While it may look a lot of work, even the whole work, this step is mainly for decisions and project logic.
  • "Plan ahead for success, else the failure's plan will triumph."

• "Build" step:

  • Contains mostly, preferably all, automatic actions.
  • Input: data from previous step.
  • Output: a new instance of a whole product, documentation for clients.
  • Output: product internal data, status, reports.
  • Brings in atomic data and incrementally build more complex objects.
  • Apply and verify project rules and conventions.
  • Run early tests on product parts.
  • "Fail Fast. Get rid of waste sooner."

• "Certify" step:

  • Contains mostly, preferably all, automatic actions.
  • Input: data from previous step.
  • Output: a new instance of a whole product, documentation for clients.
  • Output: product internal data, status, reports.
  • Apply and verify product rules and conventions.
  • Run tests on the whole product against desired functionality.
  • Pre-validation actions can be added here, for products that are subject to validation.
  • Where the whole product is a collection of individual products, (which are complete "Build" step), the corresponding tests should be moved also in the "Build" step.

• "Deploy" step:

  • Contains mostly, preferably all, automatic actions. Additionaly, enable-flags for the Export step can be set here.
  • Input: data from previous step.
  • Output: new instance(s) of a whole product, installed and ready to run.
  • Output: packaged product, where it is the case.
  • Output: product internal data, status, reports.
  • It takes care of installing the product and adapting the context so that the product is ready to run.
  • A snapshot of the whole product is made, with internal data and public(for export) data.
  • After this step is completed sucessfully, the next iteration of the product can start.

• "Export" step:

  • Contains mostly automatic actions, enabled by Human decisions.
  • The purpose of this step is to prepare shipping to customers.
  • Unlike the other steps, this one is launched under certain conditions.
  • Input: data from previous step.
  • Output: packaged products, moved in designed places, ready to ship to clients.
  • Output: public announcement and references for the new version of the product.
  • Output: product internal data, status, reports.
  • Contains Validation activities, for products that need this. In many cases, the entire validation process is performed by one (or more) external entities. In this regard, the Export step can be completed after successful validation.
  • Note: ABCDE can be used as the process inside this step.

Scaling

• If the whole product is a suite, a collection of individual products, then ABCDE should be applied for each individual product.
  • The suite-level Certify step should test the desired behavior of the suite, including how the sub-products work together.
• ABCDE can be used as a sub-process inside each of its steps.
  • The "Export" step in the sub-process, however, does not export anything outside of the host step, but only prepares the output for it.

Additional aspects to consider

Bio-diversity

ABCDE process can exist stand-alone. In the same time, it fits well to a variety of frameworks and/or methodologies.

Depending on context (project, skills, industry constrains), it can be used with: Waterfall, V-cycle, Agile methodologies. However, this affirmation can be said easily for many processes. Harder is the proof part, especially when project info cannot be shared.

ABCDE was used sucessfully until now with: TDD, Kanban, Waterfall. However, this blend was desired in particular cases, it is not a complete list of possibilities, neither claims to be the perfect combination everywhere.

"Bio-diversity" ... strange name ... seeing how the automated parts work together, taking over and executing human logic, it looks like a living and natural extension.

Adaptability

• ABCDE works very well with software development. There are already a lot of tools for Build, Link, Test, make reports, etc. For many languages and diverse contexts.
• ABCDE can be used for requirements transformation to architecture and to software requiremments. Automated actions can include: checks for requirement coverage, combining documents for the final form for the given product iteration. These, like any automatization, depends on existing (or doable) helper tools.

Notes:

• Abcd tool for software development creates the environment and oversees the ABCDE process.
• There is also ABCDE framework, very similar to this process.