Successful IT projects are essentially about creating customized or unique solutions for your client. Sitecore Helix can be a useful aid in achieving this. Helix is a set of design guidelines that present to the software developer a solid base upon which he/she can create additional modules to factor in the client’s specifications. Furthermore, when paired with the Scrum methodology which aims at providing small shippable products as deliverables, the results can be highly effective.
What’s Sitecore Helix and how we can create solutions using it
Sitecore Helix is basically a layered architectural guide that can be customized to suit your client’s business requirements. The three layers of code: foundation, feature, and project, form the basic structure that’s used to build an application in Sitecore.
The layers are built on the stability dependency principle that states that any module must depend only on another that is more stable than itself. If these dependencies are not defined such, any change to a module could lead to a disruption in the others resulting in an unstable code base. Hence:
The Foundation layer, as the name suggests, forms the most stable aspect of the module. It contains only the concrete features or those features that don’t often change. For instance, indexing, theming extensions, UI hooks like JQuery and Bootstrap. It’s important to remember that any change in these will affect the rest of the layers.
The Feature layer contains features as understood by the clients. For instance, this layer would contain features like news, articles, website search, and so on. These are terminologies used by the business and not necessarily by the technology team. The names have no bearing to the underlying codes or technicalities; rather they are defined by the business intent dictated by the client.
The Project layer forms the context of the solution; the actual layout of the website, pages, graphical design, and so on come under this layer. It stitches together all the features to form a cohesive structure that takes into consideration all the specifications of the business. Any change to a feature affects this layer.
Often, Helix is used interchangeably with Habitat. This could lead developers and clients alike to dismiss the benefits of using Helix architecture as time-consuming or even stressful. A good rule of the thumb is to remember that Habitat is a full-fledged Sitecore project that has been implemented using the principles and guidelines provided by Helix. Hence, it should only be used as a reference point and not to be replicated in its entirety.
How Helix works well with the scrum methodology to add value to any business
Scrum methodology, a part of Agile frameworks, uses iteration and incremental practices to deliver a product. The deliverables are broken down into smaller shippable products. Each of these development cycles, known as sprints, are used to add/enhance the quality of the product. Every iteration or improvement goes through a sprint review by the product owner. Every product cycle has several sprint reviews that allow for a timely course correction. This helps the team to get better organized and mitigates the risk of having a sub-standard final or end product. The result is a value-added approach from the team and happier customers.
Now, if you observe closely, Helix feature is similar to a shippable product as identified by scrum process. A shippable product is defined by a user story or a set of user stories. Sitecore Helix creates the necessary boundaries to the shippable product to ensure that each functional feature is uniquely defined. Each feature is now a shippable product. The codes for each of the feature are stored separately.
There’s always the danger of the codes overlapping (similar products with similar user stories) which could render the uses of Scrum and thereby the Helix architecture redundant. The product owner is responsible for reviewing and eliminating any vagueness in the user story for each of the features. For instance, a search feature on an article page is separate from the ‘article page’ feature itself. However, different components of the same feature could be grouped together. Case in example is that of an accommodation feature on a travel website. The type, size, price of accommodation are multi-components that can go as a group.
The team and the product owner need to work cohesively, arrive at precise requirements, and agree on code separations within the prescribed feature boundaries. One could argue that several discussions over a single feature or shippable product are a drain on time. However, the more questions are raised, the clearer the path becomes. Both parties stand to benefit; the product owner is able to precisely articulate what he wants and the team is able to understand the business process better.
Helix is a suitable aid to enforce the scrum methodology by creating the necessary boundaries for smaller shippable products. The two can work harmoniously to add value to a business and increase customer satisfaction.
Related: Why Sitecore’s Digital Experience Platform is what you need to boost your ROI
Want to know more about Sitecore Helix and Scrum methodology? Our expert team at Suyati would be glad to help you out.
