Agile based deployment

Agile deployments have the main benefit that the deployment starts, and results can be shown within weeks. Agile projects are delivered in through so-called sprints. A sprint is a short, time-boxed period when a scrum team works to complete a set amount of work. The best choice for project deployments with requirements in flux.


PROJECT METHODOLOGY

ROLES AND RESPONSIBILITIES

During the contract life cycle, Skyline agrees with the stakeholders dedicated checkpoints (in average between 2 and 5 sprints, and a sprint lasts in average 2 weeks (max 1 month)). The customer at these checkpoints can make changes to the deployment taking in account variables such as VALUE (scope), TIME and COSTS.

SCOPE OF WORK

In contrast to a scope-based project, there is no need to write a Scope of Work (SOW) or draft a full Functional Design Specifications (FDS) document.

"Sprints make projects more manageable, allow teams to ship high-quality work faster and more frequently, and gives them more flexibility to adapt to change."

NAMING CONVENTIONS

PROJECT

The general description of the domain

EPIC

An EPIC focusses on a functionality within a domain. It's a broad description of the requested functionality without going into any details. A project can have an EPIC for each domain. An EPIC has a Business Product Owner (BPO) and/or a Technical Product Owner (TPO).

USER STORY

A user story is related to new functionality required in an EPIC. A user story needs to be individually testable and the test criteria are included in each user story. Each user story has an owner, which is the person who’s assigned to the next task (meaning a user story can change ownership during the sprint. Therefore, budgets/hours are based on user stories instead of on tasks.

TASKS

Each user story contains multiple tasks including defining/architect, preparing, developing, testing and deployment. Each task has an owner who is responsible for the complete execution of the task. During the sprint planning, the required effort is estimated for each task and the task is assigned to a team member of the squad. During the sprint execution, each assignee keeps track of the time spent on each task which is chargeable.

Check out more in-depth information related to the naming dictionary.

ONE TEAM

Agile projects have proven to be very efficient. However, it's essential to become one team during these projects. It's a contract where the customer and Skyline are equal partners, and the following set of rules are important for to become a successful team:

Trust:  be able to be vulnerable without fear of repercussions

Conflict:  be constructive, debate ideological

Commitment:  be clear on commitments and buy-in

Accountability:  help people get back on track when they have made their commitments

Results:  focus on collective outcomes

HOW TO ADDRESS A NEW REQUEST?

Each new requirement needs to be translated into one or multiple user stories. This will be done by the BPO for the user stories provided by the business and by the TPO for the technical user stories.

  • Each user story needs to represent a business value
  • A business value does not necessarily mean a direct financial value. It could also mean workflow improvements (e.g. a business value could be: As a user, I would like to see functionality xyz, in order to work more efficiently).
  • The business value is validated by calculating the Cost of Delay. This is done by the BPO with input from the stakeholders and TPO.
  • New user stories end up in the backlog. The backlog is sorted by the BPO and prioritized as requested.
  • The prioritization of the backlog can be based on dividing the Cost of Delay (what is the relative value of having this or not, how time critical is it, what are the risks in deployment, etc.) by the job size (hours estimated). The higher the number, the more priority the user story will be given in the backlog
Cost of delay - Agile based deployements

Cost of delay: estimates in a lightweight way the opportunity cost of NOT completing a feature, often divided by feature size to get a 'proxy' for ROI

AGILE CONTRACT ENGAGEMENTS

A common mistake is that agile means that there are no rules and there is no engagement from the supplier. The opposite cannot be more valid - agile contracts include clear engagements and deliverables including the flexibility to adapt towards the continuous changing reality. However, agile projects can only be deployed successfully when all stakeholders engage to a set of agile principles through the complete deploy cycle.

Cost is constrained (fixed budget)

Your project needs to be deployed against a locked upper cost. In this contract, during the sprint design deployments and checkpoints, the customer stakeholder has the option to adapt the scope against the cost variable.

Therefore, the indicated deploy date of the project could take a bit longer than expected, as the scope is in flux and fully iterative defined during the sprint design. At the start of the engagement, the deployment starts upon a mutually agreed start date and your budget is not going to exceed the estimated value.

COST is locked (locked upper cost) with the customer

SCOPE is in constant flux to remain within budget

Engagement against hourly rate is agreed upon. Based on the hourly rate & estimate, the total is estimated, and budget will not exceed.

Time is constrained (time - deadline)

Your project has a fixed deadline. In this contract, during the sprint design deployments and checkpoints the customer stakeholder has the option to adapt the scope against the fixed time variable.

Therefore, your project is going to be deployed within an agreed start and deadline estimated with an approximate budget cost. Note that the cost could be higher than initially discussed. However, the scope is in flux and can be adapted by the customer key stakeholder.

TIME is locked – project is deployed by agreed deadline

SCOPE is in constant flux to remain within time

Engagement against start & end date, based on hourly rate and estimate scoping an approximate cost.

Scope is constrained (fixed scope)

Your project has specific requirements, and this is what is considered to be delivered. The path to achieve this is fully designed using user-stories and iterated into sprints. Each sprint planning is scoped, and costs are estimated, and also the time plan for deployment is adapted.

TIME & COST are volatile and can be higher than expected - however the customer controls both variables and manages an incremental delivery contract

SCOPE is locked

Engagement against a start date only.
Engagement cost against a set of agreed features listed.

Scope and cost are fixed

When scope and cost are fixed, a natural reflection could be to turn back towards a scope-based contract, which is a valid option. However, note that in case the requirements are difficult to define in full detail, an incremental delivery contract is also an option. In this case, Skyline offers services to define the user stories and the full deployment based on full agile methodology, delivering you the best of both worlds.