When a client asks for a training session, most often the full content of the training is discussed and defined up front. With one client that wanted a week of training I took a different approach. The client an I used a backlog to prioritize training sessions and workshops. We only planned the first days, and reflected and adjusted the training every day of the week. This is a story of how I collaborated with a client in an agile way to ensure that they would get the biggest possible benefit out of a training week that I delivered to them.
Delivering training to teams in an agile way
When a client needs training for an organizations a lot of time is often spent to discuss the requirements with the party that will give the training. As a result the training is defined up front, based on the assumption that the client knows exactly what they need and that the consultant knows best how to deliver it. But is this assumption correct? Can a client really know everything before the training starts? Is there only one best way to do the training?
I worked with a customer that wanted to measure and improve the quality of their software products. We agreed to work on-site with the teams and management for a week, to train and coach them. This is how we decided to work that week:
In stead of making a plan for the full week, we only planned the first two days with a kick-off presentation, training sessions, workshops, and daily evaluation and planning at the end of each day. This would make us flexible towards the needs of the various teams, which would become clear during the week.
I made a short list of available training sessions and workshops, and my customer picked the ones for the first two days. I also gathered and organized my presentation and training materials, to have them available when I would be on-site during the week.
On the first day onsite I sat together with the client’s manager for a couple of minutes to do a final check for that day’s plan. Then the manager asked the the first team in the training room and I started doing the training sessions and workshops with them.
The manager was there the whole day to arrange anything that was needed. During the day we check the timing and informed teams if their training would start earlier or later. I also adjusted the training sessions based on the feedback that I got.
At the end of the day the client’s manager and I sat together and evaluated how things went that day, and revised the plan for the second day. We also picked some first things that we wanted to do on the third day.
The second day followed the same pattern: start with check the plan for the day, give sessions, and evaluate the day.
In agile terms: It’s a Scrum based training week with 5 sprints of 1 day. As a 1 man Team and Scrum Master I created a backlog and my Product Owner (clients manager) prioritized the User Stories (training, workshop, presentation) and picked the ones for the first two sprints (day 1 and 2).
After the first day on-site, we did an evaluation (Retrospective!) and decided that we needed some small changes on day 2 (Planning Game!). We also made a draft planning for day 3, which included a new course to be developed (using partly existing materials). This way of working (Sprints!) was used throughout the week.
We did a stand-up every morning to check the planning for the day, and had a daily retrospective and planning game at the end of each day to evaluate the day and fix the planning for the next day.
Adapting to delivering value to the client’s organization
After 2 days of team training, I started to train the managers in the organization. We used a similar approach, doing this training in an agile way:
On the 3rd and 5th day we also had a short evaluation and planning session with the whole MT. On the 3rd day, the MT asked me if I could do a presentation for all teams and managers showing how an organization could look that would use a full blown quantified quality management system. This was a pleasant surprise for me and the client’s manager, as we didn’t expect that the client’s MT would be willing and ready to take this step.
I adapted a presentation that I’ve given as a keynote on a conference, and added specific slides on what we had done already in the past days and how the stuff would fit into this organization. And gave the presentation.
It was a great success; it helped the attendees to visualize how their “road to quality” could look. The employees asked lot’s of questions, and there were several good discussions between the managers and the employees, about the “why” to manage the quality of their products, and what managers can do to facilitate this.
Neither the client’s managers nor I had expected this when we started the training. By working with agile daily sprints, and continuously adapting the training we were able to make it more valuable!
Reflecting and learning
You might be wondering if anything went wrong, or if there were things to improve? Of course! Since every day ended with a planning game, I always had some “homework” in the evening. In one situation it was challenging to have training materials ready for the next day, but I always managed to do it.
On the 1st and 2nd day we had some training sessions which took more time then planned. Actions taken were to become more focused in the training sessions, and also allocate some more time for the sessions, with slack in between training sessions, to meet the schedule. With these improvements, we managed to keep the schedule for the remaining days.
The value of doing training in an agile way
Agile practices helped to deliver this training week and make it more valuable. The daily retrospective and planning game took only 10 minutes at the end of each day, and helped us to adjust the training to the changing needs.
Every morning before the training started we had a short stand-up to check if everything was ready. We didn’t really have a demo, but since my client’s manager attended almost all training sessions and workshops you could consider the full training day to be a demo. Where he could not attend, I briefed him on what happened when he rejoined the training.
In the final evaluation on day 5, our conclusion was that delivering the training in this agile way had been very effective and efficient.
Conclusions
This blog described how I applied my experience with agile into giving training. Using iterations to deliver it, with retrospectives and daily stand-ups as the main tools to manage the training activities and deliver results. With the agile approach , the training week delivered more value for the customer.
Hey Ben,
Nice post. Still, doing one week of training is still a big batch of training. What about lowering the batch size?
Patrick.
In this case that was not a viable option as the client was in India and they wanted to make a quick start to improve their performance. Also I trained multiple teams and managers, nobody received more that 1 day of training during the week.
But yes, my preference is to do Just-in-time training in small batches, where people learn, apply what they learned, reflect and learn from applying, and learn more stuff. Their training needs will evolve, so don’t plan all up front and be flexible.
Which is similar to the way that I do Just-in-time coaching and advice; more on that in Short Cycled Improvement.
Good read! In your opinions, is it better to deliver small batches but more frequent training sessions even before functionalities are released to end users? That is, training on the future release of functionalities in incremental manner.
If it’s about training the users of your product, I’ve seen good results when it’s part of the delivery. Then you can indeed train people, where needed, just in time before the start using new functionality.