Agile Sitecore Training – Part 2 of 3
This post is the second in a series discussing applying agile practices to training for Sitecore products. In the first post, I covered applying “Individuals and Interactions over Processes and Tools” to training. In this post, I will look at “Working Software over Comprehensive Documentation”.
Over the past few years, I have been uncovering different ways to deliver training. To help people retain what is taught, I want to deliver in a way that involves more doing. This is different than just dispensing information through lectures.
One document that I found helpful was the Manifesto for Agile Software Development. It was a watershed moment when I started applying the manifesto to instructional design. Although designed for developing better software, the principles could be applied to other disciplines.
Working Software (demo)
At the end of a phase of work there should be a ready demo session. When I first would deliver training, there was an expectation to have all the slides, demos, printed workbooks and exercises ready to deliver in a 1 to 4 day format. This was a waterfall approach to delivering training. It was highly dependent on a perfect execution and depended on all the website development to be completed, gone through UAT and published.
Instead of a long single day or full-week session, I now set the expectation that training will be delivered in smaller sessions broken up over a series during the project. What is covered in the training is dependent on what development is completed. Additionally, I need the participation of the customer to confirm what functionality is “done” and ready to be shown to their organization. Finally, I solicit feedback after each session to ensure any gaps are covered in an upcoming session.
Macro Trends in Sitecore and DXP
Over the past few years, Sitecore has transformed its architecture, offerings, and vernacular. The DXP landscape is evolving and organizations are increasingly embracing these changes. This guide explores six emerging trends in Sitecore and the DXP landscape.
Get the Guide
A session is minimally, a demo and exercises (or at least “open” lab time) for the customer to immediately try out the information received. The lab time could be done in either the customer’s pre-production environment or on one of our training environments, depending on the topic.
It is vitally important that the trainer is able to perform the demo during the training. This allows them to build customer confidence and perform mini-UAT during the development process. If there is a particularly high-risk demo or something in development, I attempt to arrange a demo with the customer’s product owner. The product owner can then make the decision whether or not that functionality is ready to be presented before their peers.
Make a Backup!
Everyone has had a live demo fail on them. As a precaution, it is not cheating to have a pre-recorded demo of the functionality. If something unforeseen happens during the live session, the recording is a perfectly fine way to show the demo. The customer can then try to repeat the process on their own time, once the networking or other technical issues during the presentation are resolved.
Comprehensive (or at least enough) Documentation
Contrary to most organizations’ Agile practices, there is still a need for documentation. There should be at least enough documentation, that the trainees could try the steps in the demo on their own. By delivering the documentation in a digital format, the customer has the option of printing if that suites their organization. If there is gap in the documentation, then the trainer has the opportunity to update the documentation and redistribute prior to the next session.
In addition to steps for performing the tasks, I like to get the customer a copy of the slides that will be presented. This allows them to take notes during the presentation if they so desire. Especially if the customer is new to a product, I highly encourage them to either mark up the digital documentation or print out and mark up as I speak. This encourages absorption of the information.
I think to apply “Working Software over comprehensive documentation” means the following:
- Ensure you can perform the tasks in your training environment
- Record demo as a back-up prior to presentation
- Ensure you give a copy of the slides to the client prior to the training
Be on the lookout for my next post, where I will show how to put your customer first and respond to change!
If you’d like a partner who can help you with customized CMS (especially Sitecore or Optimizely) training in your projects, reach out to your Perficient account manager, or use our contact page to begin a conversation.
Nice article and series, Christopher! Thanks for sharing.
I always have to laugh when I hear comments like, “Contrary to most organizations’ Agile practices, there is still a need for documentation.”
It’s like, “well, of course there is!” But you are correct that it is not always well established or maintained. Classes on Agile should always remind the students that just because the Agile process doesn’t have it defined, doesn’t mean that your team doesn’t still need it — or deserve it. I’ve been in Agile classes where the instructor mentions documentation as an example that is still good to do. Or project charters… etc. etc. Agile doesn’t say NOT to do these things, so if they are helpful to your group, by all means, do them!
Thanks for commenting.
The maintenance of documentation is not a small task. I am going to tackle it, by setting up reminders to re-visit certain topics at least yearly.
Although it is not the most exciting task, keeping documentation updated is a valuable task. Minimally, when Sitecore releases a new major feature or product line, I think it would be beneficial to our customers to review and update their training, wikis and product roadmaps in light of the new announcements.