This document discusses mapping agile methods to ERP development and identifies directions and limitations. It motivates using agile due to long delays and misfits with waterfall ERP development. Several agile principles like iterative development, ubiquitous language, test-driven development, and continuous integration are described. However, limitations include cultural barriers like predictive planning mindsets and technical barriers like legacy technologies. The conclusion calls for overcoming barriers and further research on agile technique adoption levels and behavior-driven development for ERP.

1. Mapping Agile Methods to ERP: Directions
and Limitations
Rogerio Atem de Carvalho
Federal Fluminense Institute, Brazil
Björn Johansson
Copenhagen Business School, Denmark
Rodrigo Soares Manhaes
Federal Fluminense Institute, Brazil

2. Motivation

Historically ERP systems have been developed
in waterfall (or almost like) approach

Although based on heavily planned and
documented processes, still occurs a lot of
“misfit”:

Long delay between requirements elicitation and
implementation (customization)

Too many levels of documents between
requirements and code

Lack of a proper communication process

3. Motivation

Development (customization) is a learning
process: developers learn about the users’
business needs

Big Design Up Front may facilitate planning
however creates a long gap between
requirements elicitation and the actual
implementation of them

Given the figures on ERP implementation
failure, why not use Agile?????

4. Agile Principles

Iteractive & Incremental

Ubiquitous Language

Test Driven Development

Continuous Integration

Emergent Design

5. Iteractive & Incremental

Software is released frequently and in small
pieces

Provides constant communication between
developers and users

Limited by the “Late Integration Problem”:

processes integration points are discovered late in
the development

Can be solved by flexible, low cost process
integration techniques

6. Ubiquitous Language

Very important for communication, feedback
and close collaboration between a customers
and developers

Common language, covering the entire
communication chain from customer and
business analysis to the team’s internal
conversations and coding

Does not necessarily uses the exact customer
jargon, but an unambiguous and contradiction-
free version of the domain knowledge

Is not built in a single step, but it is iteratively
refined and improved

7. Test Driven Development

Writing test cases for every programming task:
feature creation or adaptation, improvements,
bug corrections etc

Design of the system can be continuously
improved without falling into the famous
Boehm's cost of change curve

The presence of testing data is not enough,
since ERP is both integrated software and an
adaptable framework, regression testing is a
must: it occurs when a given module is altered
to meet a given customer’s specific needs

8. Continuous Integration

“Integration hell”: incompatibility between
modules, broken dependencies, out of date
modules, lack of compliance to coding
standards etc

Continuous integration (CI) provides both agility
and fast feedback, consisting of making at least
daily project builds

Every commit triggers a complete build with
immediate feedback of errors

Guarantees that software is always working
properly

9. Emergent Design

In an iterative and incremental, agile-style lifecycle,
design is not performed up-front, but incrementally
evolved as it meets the current iteration requirements

Emergent design (ED): process of evolving systems in
response to changing requirements, better
understanding of existing requirements, and in
response to new opportunities that arise from new
technology, better ideas, and a changing world

To be able to follow this principle, some disciplines
must be applied: TDD, refactoring, expressive code
and heavy use of design patterns

10. Limitations

Cultural limitations:

Predictive Planning mindset

Contracts: Product (an ERP) X Service (an ERP
customization)

(Excessive) HR especialization (analyst, designer,
programmer...)

Communication based on many abstraction levels, with
different artifacts

Technical limitations:

Legacy technologies

Database centric techniques

Determination of a sound Ubiquitous Language

11. Conclusions

The statistics on unsuccessful ERP
implementations urge for new ways of facing
the misalignment problem

Agile techniques can improve communication

There exist cultural and contractual barriers

Future directions:

Agile techniques adoption levels for Proprietary,
Free, and In-house

Behavior Driven Development for ERP