OSB Agile Project Methodology

At OSB we split our projects into 5 big phases:

  • Sprint 0
  • Implementation Iterations
  • User Acceptance & Validation
  • Rollout & Deployment
  • Hypercare

Agile Project Methodology

Sprint 0

The Sprint 0 is the initial phase of the project and usually consists on: Business Analysis, Systems Analysis and Engineering Team Norming.

The initial design sessions with the customer are usually performed at this stage (but also throughout the project in case of need). These sessions, together with the business and systems analysis will lead to the definition of the first set of requirements. It is important to mention that these requirements should not be a detailed description of the system to be built, but a reference to be used during the development and testing phases. This list should also evolve and adjusted throughout the project execution and interactions with the customer.

This phase is also used to bootstrap the engineering team, get familiarized with the scope and requirements of the project and setup all the needed environments.

Implementation Iterations

This phase corresponds to the main development phase of the project. The amount of sprints as well as its duration should be defined on a per project basis.

Recommendation is to have sprints of 1 to 3 weeks, with preference of 2 weeks sprints.

User Acceptance & Validation

For each project it is important that the customer accepts the solution developed before deploying it in production. This acceptance should be done through a set of key user testings and not only through demos. The plan of these tests should be defined by OSB together with the customer and should be based on the requirements defined during the project execution. The ownership of the UAT testing plan can be adjusted depending on the project itself.

Besides the User Acceptance Testing, a final validation by OSB teams in a "E2E" (or close to E2E) environment should also be performed so that we don't rely only on the customer to validate the solution.

Rollout & Deployment

After being accepted, the solution can be deployed in production. This phase is very specific to nature of each project. For example for a greenfield solution, we may need a longer rollout phase but less risky. On the other and, for an extension of an existing system, a more incremental approach can be taken but we should also accomodate the migration of the existing data.

Hypercare

Usually after a new deployment there is a period of close monitoring and potential bugfixes, so it is recommended that such a phase is part of the project plan. However, this will be very specific to the project/customer and in some cases can be optional.