By the time that most businesses realise they need move to a new e-commerce platform to replace their existing one, time is not on their side. The investment into a new
e-commerce platform is not a trivial decision and once made, the time to introduce the new platform whilst keeping alive the legacy platform is critical.
In Portaltech Reply we engage with many large enterprise clients that demand rapid delivery once e-commerce investment has been made. We understand this need and right from the beginning embrace a truly collaborative approach to work together from Discovery through to Go live.
Minimum Viable Product (MVP) is a scary one, anything that suggests doing the minimum amount for a significant investment does not make logical sense.
However, if this is rephrased to
Maximum Value Proposition within the given timeframe then this changes the thought process completely. This mind-set switches to focus on the things that matter, allowing our team to articulate how the hybris capabilities can be exploited to transform businesses.
At Portaltech Reply we encourage this thought process from day 1 and plants the seed for true
We have established a Delivery model, a pattern of working, for Agile programmes that can be scaled from a team of 20 people to more than 100 people. Taking the key elements of SCRUM, SAFe (Scaled Agile Framework) along with Continuous Integration principles to be applied to delivering hybris customised platform iteratively. The team is structured around 4 functional areas that have clear objectives namely:
DEMAND, DELIVERY, RELEASE & GOVERNANCE
Within this function, the primary objective is that the backlog of work is appropriately defined sequenced and agreed with the customer ahead of Delivery consumption.
The team is a cross functional team of Architects, Business Analysts and Quality Assurance to shape the upcoming backlog in the form of
User Stories (using BDD Syntax) & API contractual definition. At Portaltech Reply we invite the customer to engage and to be part of the
same team, so that a shared common understand and goals can be agreed as early as possible.
This function is also responsible of the management of CRs and will rework the overall build sequence ahead of development.
This function is the heart of the Delivery model and follows a more traditional SCRUM set-up whereby cross functional Agile teams of BAs, Devs, QAs, Scrum Masters work in according to traditional agile ceremonies. The handover of the Demand Planning backlog is managing through upfront
The real engine of the Delivery is the
Build Pipeline, this is the production line that should never stops. The development team is orientated around developing and testing production ready software into the hybris Build Pipeline with full
Test Automation (Unit, QA) & Static Analysis to ensure Quality is maintained throughout. We have established our own Build Pipeline, Automated test framework and code line management specifically for hybris for this to work.
In addition, on every Sprint cycle iterative
Security based testing & Performance Testing is performed against each candidate build to ensure the build package is solid before release.
Finally, working closely with the client the adoption of
Progressive Acceptance is highly recommended to build confidence in delivery and build knowledge of the evolving platform.
Within this function, we establish a dedicated team in a Kanban approach to support the software package that has been released into other client environments.
The team are responsible for the
resolution and investigation of issues to allow the overall Programme to move forward with other stages of testing. Importantly defects that are leaked into downstream stages are assessed and corrective action taken on the automation packs are addressed.
In addition to this a small team is often needed, as a symptom on how much code is being changed, that requires the code to be refactored in the form of
Technical Debt remediation. This activity allows for independent assessment of the architecture and provide corrective action as needed.
The overall Programme governance oversees and authorises change to the Delivery Model Approach. Using
automated dashboards, the overall assessment on how the team are performing can be assessed and improved. The Continuous Improvement focus allows and embraces change to improve overall delivery efficiency.
A major part of agile delivery is establishing a close, trusted working relationship with our client’s, the Automated dashboards we have created allow clear
unambiguous status of where we are in delivery.
customer’s goals are our goals and by sharing the same objective we can leverage our experience and engineering capabilities to delivery something truly special.
Software delivery is never easy and for e-commerce platforms with major investments, complex legacy systems and with time pressures a good delivery model is
At Portaltech Reply we believe we have found the right recipe for delivery success and have leveraged this approach to great effect. We have found this approach has not only accelerated the delivery of e-commerce platforms to “Go live” it has ultimately built
special relationships with our clients.
David Eccles, Portaltech Reply