Engineering the “Delivery model”

Whenever we engineer any delivery team, process or structure, we need to measure success by two factors, outcome they have achieved and habits they exhibit. Let’s elaborate what I mean by both Outcome and Habits.


When engineering the delivery model for your team, following three factors should be considered as an outcome



Habits – 7 Habit of successful delivery teams

I have covered what are the 7 habits of highly ineffective enterprises. So we should certainly avoid those. Also refer to embracing change and be aware of interpretations

This are the 7 habits of highly successful delivery teams that we should embed in the teams

  • Work smart – Always think of innovative ways to reduce waste and focus on automating anything which you do more than 2 times
  • Focus on Quality – Focusing on the smooth flow of work  and delivering high quality code. Never compromise doneness at each step of the work flow. But please note that focus is on Minimum Viable Product MVP rather than trying to go for a rolls royce
  • Self organising – make their own decisions. Rely on coaching from leaders rather than direct answers
  • Takes pride in Finishing Work rather than working multiple items in parallel
  • Openness – Be open, honest and direct to build trust. This is the way you will improve and your team will improve
  • Collaborative – Focusing on team’s performance rather than individual performance
  • Data driven – Rely on data over opinion or subjective analysis

Engineering the delivery model

Let’s look at the different phases in the delivery model, what they are, what are the recommended practices and impact on other teams in the enterprise organisation


The 4 common phases we need to understand are Define, Deliver, Acceptance and Cutover or Go live


“Design is a complex, iterative process. Initial design solutions are usually wrong, and certainly not optimal”
  • The deliverable is scoped out and designed at the Define stage. The process begins with a workshop, bringing together key stakeholders, including software developers, operations team, testing, business analysts, product owners, project managers and architects
  • This is where we capture primary business driver for the change. This is broadly called EPIC as per scaled agile framework model (Relationship is EPIC -> Features -> Stories)
  • All documents produced for a product will be cumulative i.e. existing product documents will be enhanced to incorporate  these new requirements. For new projects this would be brand new set of documents.
  • Goal is to define features for each EPIC in this phase


  • Technical approach detailing impact to high level design and other systems
  • Features in alignment with Minimal viable production for a release
  • Testing approach , if there is any change from normal
  • Business value
  • High level estimates/points
  • Dependencies with other product teams

Impacts to other teams

Environment teams – Plan new environment if needed depending on the non functional requirements

Operations team – Define any operational acceptance test scenarios and come up with a list of alerts which need to be set up

Security – Identify involvement at future phases including need for any additional testing in the hardening phase

Performance – Identify performance impact and work towards mitigating the same


This phase consists of majority of the activity necessary to produce an outcome. Input to this phase is the output of the Define phase. The phase is executed as series of sprints. Each sprint builds upon the previous one, allowing work to be validated and progressed. The top features of the backlog are picked up and executed. Definition of MVP may/will/should change as part of this phase as you learn more from the user feedback

Sprints can be conducted using scrum methodology and follow scrum ceremonies like Sprint planning, daily stand ups, sprint retrospective , grooming and reviews. Multiple teams can be folded into scrum of scrums for managing cross product team dependencies

There should be a common notion of “done”. “Definition of done” is a transparent and mutually agreed list of criteria that must be adhered to for the  stories to be marked as complete

All major testing including integration, component, system test are part of this phase. Acceptance test (please see below) and non functional testing should be started in this phase in staggered manner with the aim to complete as much as possible in this phase. E.g. acceptance test for Sprint 1 must be complete by Sprint 2, for sprint 2 in sprint 3 and the likes. Last sprint is the only one which should remain to be covered in the acceptance phase for the release

Epics are converted into stories with acceptance criteria and then stories is further break down into tasks. Each task should be as measurable as possible. Like if it is code then we should measure code quality metrics, code coverage, unit test execution and the likes

Also definition of done should be broken down into several done’s so it is easy to monitor the progress


For multiple location scenario, communication is one of the most important things to be taken into account. Talk talk talk. You can never communicate less. Avoid too many emails and make use of phone or skype or google hangouts

For multiple vendor scenario, make sure you create an environment where they work as one team. You really don’t want people to have their own agenda otherwise you will drift from the main objective.


  • Convert Features into Stories with acceptance criteria
  • Updated functional specification documentation, wireframe/VD. This is quite important for multiple location teams and more importantly this will also serve your knowledge base for support teams and sprint teams for future development
  • Updated HLD or equivalent technical documentations
  • Updated automated testing scripts
  • Working code

Impacts to other teams

 Environment team – New environment or component needed will be provisioned

 Operations team – Operational service documentation updated

 Security – Updated tools or test scripts. Completed the assessment to be fit and not something which will damage brand

“The best programmers are up to 28 times better than the worst programmers” 


This phase accepts the MVP that comes from the ‘Delivery In Sprints’ phase. The product goes through rigorous testing by users and Ops. It is also tested to ensure that it complies with non-functional requirements. Typical tests done in this phase include the spill overs of the acceptance tests and Non functional tests (e.g. Volume & Performance, Availability etc.) for the stories completed in the last sprints.

By absorbing the majority of tests into the preceding ‘Delivery In Sprints’, the process is accelerated. It can be further sped up through automation. In advanced teams, approval can be automatic, further shortening the cycle.

End users and BA’s must be involved in the acceptance/regression testing so that complete E2E business process is executed

Volume and performance testing is conducted on the E2E flow to understand any implications

A high degree of automation is essential to ensure that the application moves through this phase very quickly.

Typically this phase should not take more than 1-2 weeks


Cutover or go live

In this phase, the hardened application moves into the staging environment. The environment is prepared with data from production. The solution is ‘sanity tested‘ in the staging environment and certified mostly by operations team. The existing sanity test suite is enhanced to include the new features. In mature organisations, this phase can be completely automated, although a small number of random checks will be carried out before it is cutover to LIVE

If there is any roll back needed then this is also practiced in this environment

Impacts to other teams

Environment teams – Start setting up production environment for the release

Operation teams – Get ready for the release with new monitoring, alerts set up, configuring existing tools etc



Define: Define phase should be based on the principle of  “good enough”. Try and cover as much as possible in the sprints

Deliver: In order to get most benefit of agility, it is imperative to do majority of the work in increments

Acceptance : Acceptance phase and cutover phase combined should be less than a couple of days in extremely advanced large organisations. Rule is “If it can be automated then it should be automated”






Survey: Large organisations wants to embrace continuous delivery

Technology leaders from big brands and agencies took this survey and results were very interesting

100% of the leaders who are working for this organisations wants to adopt DevOps and continuous delivery. So as we always used to say… it is not a question of  “Why” but it is “How”

Best definition of Devops and continuous delivery was-

“DevOps is about getting everyone in the organisation (particularly Development and IT Operations) pulling in the same direction by (a) setting common goals and priorities, (b) sharing the responsibility for success and failure across the organisation, and (c) constantly improving communication channels, processes, infrastructure and tools to remove bottlenecks and allow a consistent flow of value to the business’ customers. Continuous delivery is the automation of the software development process from code construction through live production deployment. Simply stated, both DevOps and Continuous Delivery are about reducing cycle time, improving product quality and productivity – bring working, high quality software to production faster”

Other learnings on the subjective questions are documented as part of the Engineering the delivery model posts

This picture summaries statistical key findings





Continuous delivery tools landscape

Since there is almost one tool released everyday in this space, it becomes impossible to keep up to date with the tools and there is a fear that real good tried and tested tools get lost in the midst of a newbie.

Objective of this infographic is to provide different categories of these tools and what are the most common tools in these categories which are used by enterprise organizations and thus are tried and tested.

If you are working in such organization and if you discovered a new tool which you are using and is working well then please do post your comments so I can update the infographic to include the same.

Description of each category (mostly from Wikipedia)

Code repository – A repository is a term used by most of the different source control tools to refer to the collection of source code. A source control instance can have many repositories. Usually a repository contains a project, or a group of projects that are closely related. Distinct projects would be a good example where you’d want to make use of multiple repositories.

Continuous integration – Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least

Static code analysis – Static program analysis is the analysis of computer software that is performed without actually executing programs (analysis performed on executing programs is

Code coverage – In computer science, code coverage is a measure used to describe the degree to which the source code of a program is tested by a particular test suite. A

Configuration management – In software engineering, software configuration management is the task of tracking and controlling changes in the software, part of the larger cross-discipline field of configuration management. SCM practices include revision control and the establishment of baselines. If something goes wrong, SCM can determine what was changed and who changed it. If a configuration is working well, SCM can determine how to replicate it across many hosts

Application lifecycle management – Includes Change management and Issue management

Monitoring – operational monitoring of the application by providing operation intelligence

Application Release Automation – Includes application release and deploy

Testing automation – In software testing, test automation is the use of special software to control the execution of tests and the comparison of actual outcomes with predicted outcomes


Maturity model

Maturity model helps you to see bigger picture and assesses where you are as an organization within the DevOps and Continuous Delivery space so that it is easier to assess how much more ground we need to cover.

This can also be used as a reporting tool as part of the process to understand if there are improvements made overall in the transformation.

There are multiple DevOps maturity model which are already defined and goal is certainly to not repeat these here. My goal is to provide more objective assessment and help in creating that action plan in a more interactive fashion.

Some existing DevOps Maturity models include:

Based on my personal experience and research, for large enterprises, there are 10 key factors to measure and most of the action plan will surround around these 10 factors.

Please download the maturity model and select your level in Column D for each of the 10 factors. This will give you the score. You can select the area for your organization which you want to include in the action plan based on the current state.

Please do not hesitate to get in touch if I could be of any assistance in this small exercise.

Maturity model 1 3 


Latest architecture patterns

I have now spoken to multiple technical leads and architects from various eCommerce agency and I feel below patterns are more and more we will see in coming months


SOA architecture or LEGO brick pattern – Moving browse and potentially checkout (very cutting edge) away from commerce server and use commerce as a data layer (via API, direct command layer , JSON and the likes)

  •  The new trend is that SOA is becoming increasingly applicable for the E-commerce services as well. This is especially true where these services need to be consumed elsewhere in the Enterprise
  • In this new paradigm, E-Commerce application is getting divided into front end and back end
  • The responsive web design layer would use a JS based MVC framework like angular
  • Front end layer is composed of controllers that provide a form submission based contract with the web layer. This layer can be specific to a technology stack or can be generic.(Node.JS for instance)
  • Controllers speak to the services using REST/SOA. In case the controllers are in the same JVM as the services they may use direct Java interfaces.(more on the lines of a monolithic application with a combined front end + services) (MORE ON THIS BELOW)
  • We certainly gain the advantage of independent operating for product teams
  • But obviously this comes with some compromises like
    • Complexity around API’s
    • Loosing certain functionalities which are driven from workspaces like sale workspace, promotional workspace etc unless we customize this heavily
    • We may not be able to leverage things like personalisation as that is inbuild into commerce server
  • Needs heavy investment

Functional clustering

This ideally if done within commerce server can reap some benefit of the OOTB features

We can still go angularJS and single web page style and call internal JVM API rather than rest API. There is an obvious chances of leakage as commerce server may still leverage something i.e. Order class which we try to avoid from the API

In both the approaches, we need to be careful that we do not go too fine grained as than we start to loose lot of the advantage. We need to make sure our API, either rest or internal are aligned to business capability as that will prevent us to go too fined grained

Please provide any thoughts on any more pattern in this area