Guide to a SWEET Sitecore implementation
In the many Sitecore solutions we have seen over the years, there is none that are ever perfect. But I will say, there are some that have been SWEET. Unfortunately there are some that have been SOUR, but we won't focus on those in this piece. Below are some helpful tips when implementing Sitecore that you really need to think about before your next endeavor.
The roles you will need are:
- Product Owner - decisions are made by/through this person
- Project Manager/Agile Team lead
- Business Architects to help transcribe requirements to stories
- Architects mentioned in Discovery phase below
- IT Technicians (scaled to size of project)
The types of processes:
- Kanban (Factory line where story cards are pulled from phase to phase - time is based on fully delivered MVP - minimum viable product)
- Scrum (Time-boxed workload commitments from team - comes with ceremonies and clear communication)
- ScrumBan (Time-boxed Kanban in which items are selected to be worked in a given time period)
- Waterfall - Some still do it, I will leave it at that
1) During the discovery phase is the time to bring in the experts. This is where if you are going to spend money on consulting - you spend it here. Just imagine a house that is nothing but a piece of land or a house reno that is about to begin, would you bring in a weekend warrior to do the planning. Believe me, You DO NOT want a green or DIY Sitecore lead in this stage.
There are so many things you have to think through in this phase such as:
- Information architecture
- Sitecore content architecture - Audience Awareness (content managers)
- Sitecore rendering/Component architecture
- Designs that will align with the information and component architecture
- HTML/CSS architecture to align with the component architecture
- Back-end code architecture (Helix, Traditional, Accelerator)
- Hosting (Azure, AWS, On-Prem, Hybrid)
2) During the Design Phase is when the information architects will play a lesser role, only to be involved as needed. This phase will weigh heavily on the Component Architects and the U/X team and the Designers. During this phase the sketches are drawn up that align with the information architecture. The items within the sketch should be transformed into an Atomic methodology in which atoms (labels, headings/titles, content styles) are put together to build molecules (buttons, sections) which molecules will be placed together to build organisms (components). After this the designers will overlay their design that will bring to life the face of the project output. Once the new designs are approved by the product owner(s) then this phase can come to a close. This is when you really want to begin to introduce the content managers. The will need to be able to speak the same language from a component and page perspective.
Tip: NO CODE SHOULD HAVE BEEN WRITTEN BY THIS TIME!
3) During the development phase is when you should start to hear the hammers and the saws in the background. During this phase the designers will play a lesser role, only to be brought in as needed. Sitecore content and rendering architecture should start to take shape in regards to building out the plans from the Discovery phase. HTML and CSS is underway. The HTML and CSS output should always be monitored by the Component architects to ensure components are built agnostic of any piece of the site. The HTML should be built at the component level instead of a page level. Each component should be able to live free anywhere on the site driven mainly by container size. Next during this phase is when the HTML/CSS gets handed to the back-end development team. This step will start to tie Sitecore together with the components, so you will see Sitecore items getting created. If you are seeing issues with how the code is lining up with any of the architectures, immediately stop and fix it ASAP. The sooner you get that fixed, the cheaper it is to fix it - it will need to be fixed eventually.
Tip: Component/Rendering naming is key in this phase
4) During the testing phase, is a place where if all things are smooth if done correctly up until this time. If you are seeing quite a bit of bugs, I would suggest take a pause and understand where the issue is and fix it. Even at this stage it is cheaper to fix the issue before it becomes exponential, and will have to fix it later. If you do not fix the issue, it will drain your project.
Tip: The cheapest time to fix a problem is now
5) Deployment phase. It is always best to shoot for an MVP (minimum viable product) to get to this point. If you have chosen to wait to release a perfect product, then kick back. If there is follow on work to be done, take what you have learned over the course of the project and incrementally improve the process, product, and yourself.