Since 15 years I have been working on IT projects in many different roles. I see a lot of positive evolution regarding successful projects. Nowadays we deliver more software in less time and learned to listen better to our customers.
Nowadays Scrum is our methodology of choice that helps to be more effective and successful. Basically, it will result in doing more in less time. Completing small, but completed parts of software will give an overview of results in an early stage. This helps Product Owners in specifying the business needs.
However, implementing scrum as a way of working in a company has its challenges. People are often very motivated to use Scrum, but while working they tend to forget the key elements of the methodology. It requires discipline to stay focused on small shippable parts of a product. It requires practice and focus to implement the methodology.
As a Solution Architect with years of Sitecore experience, I believe that the Sitecore Helix architecture can help teams to implement the Scrum way of working more efficiently.
Which problem can we solve?
One of the key aspects of scrum is that deliverables are always small but also are a 'shippable products' that delivers value to the business.
Why? There is more than one reason:
- It's more likely that the team will build what the business wants because the 'subject of discussion' is small and everybody is talking about the same small part.
- A small and precise defined product is easy to test.
- The product is small and complete, therefore it's easy to evaluate. The product can easily be adjusted to add more value
It is difficult to implement Scrum. Right now, I want to focus on where Sitecore Helix can help to implement the method.
What is Sitecore Helix.
Sitecore Helix is an architectural guideline in how to build a web application using Sitecore in a proper way.
The guidelines describe how to add effective layering into an application in which loosely coupling and single responsibility are virtually guaranteed. By loosely coupling parts of code are separate building blocks that do not depend on each other. The separation of the building blocks is based on functionality.
In a Helix architecture the building blocks of code are layered. The lowest level of code blocks exists in the Foundation layer. When a change occurs in the layer, it can affect many other features in the solution. This means that the foundation layer must be the most stable one of your solution.
The feature layer contains concrete functional parts of the solution as understood by the business owners and editors, for example, news, articles, promotions, website search, etc. So, based on functionality this will be completely separated chunks where no dependency exists.
The Project layer provides the context of the solution. This means the actual cohesive website or channel output from the implementation, such as the page types, layout, and graphical design. It is on this layer that all the features of the solution are stitched together into a cohesive solution that fits the requirements.
How can Sitecore Helix support Scrum
Sitecore Helix can help a Product Owner and the development team in the thinking about and understanding what a shippable product is.
Although not recognized by many, in the end a Sitecore Helix Feature is the same as a shippable product. So why not approach it like this? First, the Product Owner will ask for a Shippable product. Next, the team will create a repository in where it will save its source code. The repository will only contain code that is a part of the shippable product. Name it a feature.
A feature is a shippable product. A Sitecore development team creates features. A shippable product is based on a user story or a group of user stories. A feature needs to be functional but also technical as a separated part. There are strict rules regarding the code of a feature. It has to be separated from other features.
"By creating boundaries to a shippable product Sitecore Helix Features supports Scrum to do its work efficiently, adding real value to your business"
The power is excluding vagueness
Therefore, when the refinement of a shippable product takes place you need to be very specific. This sounds hard to accomplish because it is difficult to decide what a functional shippable product is. Often, there is an overlap with other product parts. This is where the process can start to be vague and can result in communication errors. Even worse. It can reduce the benefits of scrum earlier mentioned in this blog.
Because of the preciseness required in the definition of a feature, the Product Owner is forced to be very precise in defining and separating user stories. If the communication isn't good enough, the team will notice it and can create an overlap of code, which isn't possible. Therefore, a fix for the communication error needs to take place. This might seem time consumable but in the end, the opposite is true.
Merging the idea of a feature with the concept of a shippable product will help to implement the Scrum methodology strictly.
Do you have to create new features all the time?
How does this work in real life? Do you have to create new features each sprint? The answer is no. A feature is a concrete functional part of the solution as understood by the business. Examples are news, articles, promotions, website search, etc. A shippable product is not the definition of a user story. When a Product Owner wants to replace, change or extend functionality it can be an already shipped product/feature. A user story has the goal to increment value. This can be done to an already created Feature. The existing feature plus the increment will be the shippable product.
Accurate separation in real life
The definition of the shippable product will still be precise. For Example, a user story is about incrementing value on a Feature called "Website search". "Website Search" might be visible on an article page. The work that needs to be done will be on "Website search". Changes that need to be done to the article page itself belong to another user story, another shippable product and another Sitecore Feature. The separation on what the team works on and where the team talks about is sharp.
Are we winning or losing time?
The question will arise whether there will be too many discussions on what a shippable product or, in other words, a feature is. The answer is "on the contrary". It will force the Product Owner to be clear. The team has to understand exactly what the Product Owner wants. In the beginning, the team and the Product Owner may have to spend more time together to make decisions about what exactly has to be created by the team. Once decisions have been made, the separation made in the code will enforce to stick to the previously agreed separation. So it will help to stay within the boundaries subscribed in the scrum process. Most likely time will be won.
So, in the end, Sitecore Helix will help to enforce and support the scrum methodology because it helps to define what a shippable product is and ensures that the product owner can be as specific as possible to achieve the optimal result for the business. By creating boundaries to the shippable product Sitecore Helix helps scrum to do its work and that is adding value to the business.