KentW Limited

Agile ERP Implementations – Planning

Kent — Sat, 10 Sep 2011 11:30:19 +0000

This post is an extension of the overview – read this first: Agile ERP Implementations

The Scrum methodology is a framework for developing high value products iteratively using self-regulating teams to improve synergy and effectiveness.

Scrum prescribes the following projects activities which are all related to a specific Sprint:

Sprint Planning Meeting – scope and approach for the next Sprint or Increment
Daily Scrum – short daily meeting to coordinate within the Sprint team
Sprint Review Meeting – review of the current Sprint on Product Backlog
Sprint Retrospective – review of how to improve the Sprint

Scrum does not however specify Pre- and Post-Game activities and does not prescribe the processes and techniques for building products.

An ERP implementation is a complex project where the implementation process will impact the Scrum methodology:

Multiple Sprints in Parallel
Interdependent and prerequisite Sprints
Significant non-Sprint activities
Coordination of internal; external or offshore project resources
Management of third party product and service deliveries

To keep the spirit of the Scrum Guide each Sprint should be self-regulating to produce the next Increment whilst the Product Manager must ensure each Sprint is executed in the right sequence. Planning the Scrum project becomes focus on coordinating Sprints rather than planning the individual Sprint itself.

Pre-Game Phase

The Pre-Game planning is to ensure the following:

Project Kick-off
Creation of Product Backlog
Creation of Sprint overview plan with expected number of Sprints and their dependencies and needed non-Sprint activities
Creation of strategic working documents like Stakeholder and Risk Management strategies

In particular for ERP implementations there is a specific process that must be followed as ERP systems require a sequential setup process due to module and functionality dependencies.

Sprint Phase

The planning of the individual Sprint is very much given by the Scrum methodology with the Sprint Backlog and the addition of a few ERP specific processes:

Scrum items:
- Sprint Planning Meeting – scope and approach for the next Sprint or Increment
- Daily Scrum – short daily meeting to coordinate within the Sprint team
- Sprint Review Meeting – review of the current Sprint on Product Backlog
- Sprint Retrospective – review of how to improve the Sprint
ERP specific items:
- Development Work – functional or technical work to produce features according to Sprint Backlog
- Acceptance and Sign-off – client approval of “done” features
- Increment Delivery – apply new features to Gold environment

The Sprint Team will plan the Development Work within the team so no project plan will be made for the individual Sprint – however a generic plan can be made to communicate the expected process for each Sprint – for example:

All Sprints will start with a Sprint Planning Meeting to produce the Sprint Backlog based on selected features from the Product Backlog. Next the Sprint will commence where Daily Scrum; Development Work and Feature Acceptance and Sign-off as on-going processes.

When the Sprint is complete the Increment is delivered and Sprint Review and Retrospective will take place.

Depending on the Development Work the Increment Delivery can be anything from setting up the Gold environment to deploying a new database.

So a multi-Sprint project could look like this:

The Scrum methodology states each Development Team organises their own Sprint. So the Product Owner concentrates on coordinating Sprints and other dependencies like Infrastructure.

The above example having 4 Increments would have a 4-5 months duration – so a fairly simple implementation.

Post-Game Phase

According to the Scrum methodology the Product Backlog is never complete but from an ERP project point of view there must be a go-live point and a point where external resources are released. The Product Backlog and then accumulate and a Phase 2 project can be initiated at a later stage.

An example of a Post-Game phase with a go-live and support phase and wind-down period:

Agile ERP Implementations – Artefacts

Kent — Thu, 01 Sep 2011 12:52:40 +0000

This post is an extension of the overview – read this first: Agile ERP Implementations

Artefacts and project document flows vary by the size of a project so I would use this as a generic guide only.

The Scrum methodology states the following Artefacts are needed:

Product Backlog – list of desired product features
Sprint Backlog – list of product features to be developed in a specific Sprint
Increment – a working product based on all Sprints completed to date

In addition to the Scrum methodology an ERP implementation may need additional Artefacts:

Issue Backlog – list of issues or changes

Other working documents that may or may not be needed depending on the size of the project are:

Setup documents – module configurations with specific setup sequences
Interface documents – complex interface scenarios
Data migration documents – complex data migration scenarios
Test documents – test scripts to verify if a feature has been fulfilled
User Procedures – end-user procedures and user guides
Training documents – end-user training documents
Cut-over document – complex go-live scenarios needing coordination of interfaces, data migration and people

Some working documents like the setup documents should be regarded as part of the Increment and final documentation where others is only relevant during the ERP project.

Some documents like user-guides and training documents for a feature could with some advantage be created during the Sprint developing that feature.

The working documents are normal documents for an ERP implementation so they will not be discussed further in this article.

The Scrum document workflow is as follows (disregarding working documents and project size considerations):

Keep in mind the above diagram indicates that multiple Sprints and Sprint Backlogs can exist at any one time whereas there is only one Product Backlog; Increment and Issue Backlog throughout a Scrum ERP implementation project.

Product Backlog

The Product Backlog is owned and maintained by the Product Owner throughout the whole Scrum project.

The Product Backlog in accordance to the Scrum methodology contains all features, functions, requirements, enhancements, and bug fixes. Well this would be rather impossible to manage in an ERP implementation as just the requirements may be in the hundreds and issues/bugs may run into thousands. To put all functions into the Product Backlog would not add any value as with an ERP system one would expect certain basic functions to exist like “Ability to create a journal”.

The Scrum methodology also states that the Product Backlog is dynamic and constantly changing – an approach that would be dangerous in a large scale ERP implementation. For an ERP implementation it is necessary to manage changes to requirements due to multiple stakeholders; costs; resources and dependencies. Change to the Product Backlog should be agreed in the steering committee to ensure any impacts are properly assessed.

The Product Backlog must be tailored to ERP Implementations so it becomes manageable and value added. The Product Backlog should only contain requirements specific to the business having the ERP implementation and the requirements must have an owner or a sponsor who is responsible for the desired need – ideally grouped by functional area and type of requirement like legal; business or non-functional.

Other qualifying items may be priority, cost and dependencies. Dependencies are necessary in ERP implementations as even if the Receivables module is the most important for the project you must implement the General Ledger first and before doing this you must define security and chart of accounts and so forth.

Sprint Backlog

A Sprint Backlog is owned by the Scrum Master and is created for each Sprint.

The Sprint Backlog is populated with selected Product Backlog features and then enriched with subtasks needed as part of the development ensuring that each feature/item is measurable down to 1-2 days. This detailed breakdown ensures easy tracking and removes the need for separate planning within a Sprint.

Issue relevant for the Sprint may be added from the Issue Backlog.

Issues encountered during the Sprint should be added to the Sprint Backlog as a subtask and if not resolved during the Sprint or if outside the Sprint scope – the issue should be added to the Issue Backlog.

Suggested Sprint Backlog fields:

Development Item – id; name and approach of feature/subtask/issue
Type – feature; subtask or issue
Reference – requirement id or related development item id
Status – open; setup; developed; tested; accepted or cancelled
Assigned – assigned Sprint team member
Estimate – duration (if estimate is >2 days additional subtasks are needed)

For a successful Sprint – all or most of the development items should have accepted hence a Sprint item do not have a priority.

When the Sprint is complete the Product Backlog is updated from the Sprint Backlog which then cease to exist.

Increment

The Increment is owned by the Product Owner throughout the whole Scrum project.

The Increment is the accumulated working product of the latest Sprint. In an ERP implementation this is a new base-lined instance of an environment – normally called gold. When a new configuration or development has been successfully tested and accepted – it is applied to the gold environment and then backed. The new gold environment is now ready for go-live or the next Sprint.

A type typical ERP implementation Sprint could be done as follows:

The Sprint environment is the clone of the gold environment where development; changes and test are being made. As the Sprint environment contains dirty data - the base-lined changes must be re-applied to the Gold Environment. The Gold backup is needed in case something goes wrong during the base-line setup.

The environment is maintained by the infrastructure team on an on-going basis and is therefore outside the Agile ERP implementation methodology.

Issue Backlog

The Issue Backlog is owned by the Product Owner throughout the whole Scrum project but can be maintained by the Product Owner and the Scrum Master(s).

The Issue Backlog is an ERP implementation specific need due to the high number of issues; changes and bugs normally occurring in an ERP project. Many issues are also be cross-functional and could be outside the scope of the current Sprint and hence should be tracked outside the Sprint.

If the ERP implementation scope is only one or two modules then this Issue Backlog could be avoided by including the issues in the Product Backlog.

Suggested Issue Backlog fields:

Issue Item – id; name and problem description
Reference – related requirement id
Status – open or closed
Priority – critical, important, cosmetic
Estimate – duration
Approach Id – id of assigned Sprint Backlog or Product Backlog item

Any issue can be selected for a Sprint Backlog or converted into a Product Backlog item if it’s a new feature.

Agile ERP Implementations

Kent — Sat, 27 Aug 2011 08:26:31 +0000

By applying Agile development and project management methods we can improve overall customer satisfaction by increasing customer interaction throughout the project without sacrificing scope control and quality.

The Agile methodology helps the customer to gradually understand and accept the new system whilst providing constructive feedback and suggestions to the implementation team throughout the project.

This article will focus mainly on the high-level phases of Agile.

A later article will discuss the detailed project management and the resource management side of Agile.

Agile Development

The term Agile originates from Agile Software Development which is a software engineering methodology that focuses on interactive development and regular working releases.

The Agile Manifesto states:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

· Individuals and interactions over processes and tools

· Working software over comprehensive documentation

· Customer collaboration over contract negotiation

· Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

The above makes sense not only in a software development but also in ERP implementations. In order to ensure the Agile manifesto applies to an implementation we need to apply an Agile project management method.

Agile Project Management

There are several Agile project management methods but let’s have a closer look at Scrum as an example. There are many flavours of Scrum as it was originally made for product development but from a high level we can say there is three phases in a Scrum project lifecycle:

· Pre-game Phase – project initiation with requirements and high-level planning

· Development Phase – multiple development cycles (Sprint’s) delivering working product releases

· Post-game Phase – project go-live with deployment and documentation delivery

Pre-game Phase

In this phase the business and non-functional requirements are put into a prioritised list of features called the Product Backlog - essentially forming the project scope and high-level project plan.

The Product Backlog should only define what is needed:

So no huge scope or requirements document but merely a list of customer needs. In my experience this makes sense as it is impossible to define all requirements up-front – even for an out of the box solution especially when the make of the future system is unknown.

The original Scrum methodology states that anyone on the project can update the Product Backlog with new requirements and any defects or issues encountered. On an ERP project – where the team is huge and defects and/or issues can run into the 100s – I would refrain from this approach and rather treat the Product Backlog as being under change control to avoid scope creep. The defects and issues could be places in a separate Issue Backlog or similar.

Development Phase

This phase contains multiple development cycles – each called a Sprint. Each Sprint delivers a product release with new features as defined in the Sprint Backlog, which is a subset of features from the Product Backlog and any previous defects or issues to be resolved from the Issue Backlog:

Each Sprint contains analysis; design; build; test and delivery.

Each ERP Sprint would encompass:

· Sprint Backlog – subset of Product Backlog features

· Application Design – configuration planning

· Configuration – cloning if needed; configure and unit test items in Sprint Backlog

· User Acceptance Test – user test and acceptance of items in Sprint Backlog

Multiple Sprint cycles can operate in parallel if they are delivering independent features. For example can customisations be considered as an independent Sprint cycle.

The number of Sprint’s will vary depending on project size and complexity. But for example a minor project could be arranged like this:

1. Core features – chart of accounts; ledgers and user security

2. Basic features – sub-ledger transactions; posting; reporting and journals

3. Advanced features – intercompany, multicurrency and consolidation

4. Development -customisations; interfaces and data migration

Where Sprint 4 could be run in parallel with Sprint 3 if the customisation is independent of these features.

So a small implementation is around 4-5 sprints.

Each Sprint cycle duration would be around 3-4 weeks.

In accordance to the Scrum methodology each Sprint requires the user to test and accept the delivered features. So the Scrum methodology provides a rolling User Acceptance Test (UAT) ensuring a more balanced approach to acceptance and project completion.

The user also incrementally learns about the system and can therefore better provide constructive feedback for both the current as well as the next Sprint cycle.

Commercially this is also good approach as each Sprint is having an UAT the payment milestones would naturally match the Sprint cycles.

Post-game Phase

This phase deploys the last Sprint release into production and the documentation is delivered.

This is similar to a normal implementation project where the last tested configuration is deployed.

The documentation can be generated automatically or manually as on a normal ERP implementation as part of each UAT:

The benefit of Agile/Scrum is that the go-live leap should be smaller as the UAT has been a progressive experience rather than a big bang.

The Phased Implementation – Looking Back

Still to this day the normal way of implementing ERP systems is to use the phased implementation model with a known method like Oracle Application Implementation Method (AIM); Oracle Unified Method (OUM) or similar.

The typical waterfall phases are:

· Analysis

· Design

· Build

· Transition

· Production

Several environments are delivered from design to production with the final test being the User Acceptance Test (UAT) for final signoff before going live.

The phased implementation models are characterised by complicated project plans and documentation flows. It is often unclear what is a deliverable and what is a work product and how this tie in with the commercial contract.

Anyone who has been a part of a large phased implementation knows the following symptoms:

· Requirements are missed

· Loads of paper being produced

· Deadlines are missed

· Communication failures

· Payment disputes

· Fear of going live

Some newer implementation methods are leaning towards being agile – like the Oracle Business Accelerator (OBA) which speeds up the delivery of the first working instance but the remaining phases are still similar to AIM.

Agile ERP Implementations – The Team

Kent — Thu, 25 Aug 2011 12:51:15 +0000

This post is an extension of the overview – read this first: Agile ERP Implementations

In this post we will focus on the implementation team.

The standard Scrum method has an organisational structure as follows:

Scrum Team – Everybody on the project
- Product Owner – Project Manager
  - Development Team – Individual Sprint team
    - Scrum Master – Team leader and facilitator
    - Team Member – Professional developer

In addition to this an ERP implementation project may need cross-departmental and multi-project coordination:

Steering Committee – Cross-departmental coordination
Programme Manager – Cross-project coordination

Organisation Chart:

Scrum Team

The Scrum Team is a self-organising cross-functional project team responsible for delivering a product.

With an ERP implementation the product would be a working implementation live in production.

As with any normal business you may have several parallel on-going projects however these would have their own Scrum Teams. Coordination between projects may require a programme manager or similar.

As ERP implementation projects mostly are cross-departmental the scope of the Scrum should be controlled by a Steering Committee. This is not stated as part of the Scrum methodology but the Scrum methodology is made for product development where most products are developed within one department – hence no need for this kind of coordination.

Product Owner

The Product Owner is responsible for delivery of the product on time and budget. The product owner owns and maintains the product backlog. In an ERP Implementation the product owner may have to answer to a steering committee to ensure cross-departmental interests are met.

The Product Owner will also manage any agreed change to the product backlog and may maintain a project wide issue log.

The Product Owner has the power to cancel a Sprint if it is overrunning or hitting unexpected difficulties.

Development Team

The Development Team is responsible for delivering a Sprint producing a working product or a new feature.

The Development Team is tailored to the individual Sprint and is not static throughout the whole Scrum project.

Multiple Development Teams can work in parallel – each producing a Sprint. However care must be taken to ensure features are not dependent between parallel Sprints.

Each Development Team should be kept to a minimum ideally less than 8 people.

A typical development team for a basic General Ledger setup Sprint could be:

Scrum Master
Client Accountant
Client Chief Accountant
External General Ledger Consultant
External Developer

This may vary based on module and project size but if the team becomes too big for a Sprint – it is better to split the Sprint into smaller pieces.

Smaller teams are more efficient and communicate better which is the basic idea behind the Scrum methodology.

Scrum Master

The Scrum Master is the development team leader responsible for facilitating and monitoring the Sprint.

The Scrum Master will ensure the Scrum methodology is followed by all development team members.

The Scrum Master owns and maintains the Sprint backlog and reports progress back to the Product Owner.

Any issues or impediments are resolved within the Development Team or escalated to the Product Owner.

Team Member

The Team Member is a professional responsible for developing the product with the help of the other team members.

All team members are equal and are all developers with the sole focus of producing the product or feature in accordance to the Sprint backlog.

Any issues identified are reported to the Scrum Master.

Agile ERP Implementations

Kent — Thu, 28 Jul 2011 13:56:36 +0000

The Agile methodology helps the customer to gradually understand and accept the new system whilst providing constructive feedback and suggestions to the implementation team throughout the project.

This article will focus mainly on the high-level phases of Agile. A later article will discuss the detailed project management and the resource management side of Agile.