The agile development process leaves traditional waterfall componants, like training, behind when it comes to implementation. SAM development, although lean, is not a perfect solution for all software development training. As such, I was asked by the VP of Portfolio Management to design a Software Release Training system that would satisfy the requirements of the various departments that software implementation impacted. Notably, the customer facing departments in the company. This particular project required:
It was clear from the beginning that every department was going to have different training needs even if the content was going to be similar. I spoke with the various leaders for Customer Success, Customer Support, Sales Enablement and Customer Implementation. After identifying a couple of delegates from each department, I began the interview process to attempt to identify their needs. Truly, the most difficult part of this entire process was that, for the most part, the delegates were unsure what they needed from this training. In order to truly identify the needs, I employed the strategy of asking "dumb questions" that caused the delegate to think through the root of their concerns and issues. With this strategy I was able to uncover:
It was made very clear to me that at no point should this engagment effort take more time for the Product Manager than what was already being spent. In fact, leadership was looking to cut their training investment time by at least 50%.
Additionally, after conducting some reviews, we began to see that some product managers were better trainers than others. To this end my team and I worked very closely with the Product Managers to create a series of standard deliverables and best practices
in order to strandarize the delivery and time investment made by each individual regardless of product Complexity. Through this development process we:
Agile delivery at this company was difficult to engage with. Delivery dates were constantly in flux and "code freeze" was more of a theory than a best practice. As such, our team had to adjust to the changes in schedules and content while remaining true to OUR committed timelines.
My first goal was to ensure that we had at least 75-80% of the content ready at least 3 weeks prior to the release. Creating an active schedule of the items going into the release and working very closely with Program management, we were able to utilize "Aha", a software development mangement tool, to easily track the items going into the release. Working, then, closely with Product Managers, we were able to complete training items as the software enhancement, bug or new feature was completed. For items that went into testing and failed, we were able to track them and pull them out of the schedule quickly and easily.
As part of the scheduling process, I created a matrix of the items planned for the release and worked with the leaders of the various departments to ensure that all high impact items were addressed. This allowed us to group a product managers work so that they spent only
one session training all of the departments at one time but at different levels of detail depending on the needs of the learner.
Tracking and feedback was one of the main items requested by senior leadership for this project. Using our 3rd party LMS, Workday, I was able to track, measure and host all of our training sessions for review by managers and leaders. I was able to hire a
IC to pull metrics monthly from the LMS in order to send out reports to our leadership for them to review engagement and adjust accordingly.