A Tale of Two Sports
Close your eyes for a second and visualize a relay race. The runners get set in their starting blocks. The gun goes off. The contestants begin running, batons in hand, racing to get the baton to their anxiously awaiting teammate. The baton is passed from runner to runner until the “anchor” or last runner on the team, crosses the finish line.
A well-run relay race is a thing of beauty. When the runners are in synch and the handoffs go smoothly there is no other track and field event that is as exciting to watch.
A problem arises, however, when the handoffs don’t go smoothly, and the baton is dropped or when one member of the team has a bad day. When this happens the entire team loses and there is nothing that the other teammates can do to help. If the runner on the third leg (of the relay) wants to make an adjustment, there is no easy way to communicate that to the runner who is starting the race.
Now consider the dynamics of a rugby match. Not as artistic as the relay. The team members are bunched together into something called a scrum. The entire formation moves together. It moves slowly to the left, then to the right. Sometimes the formation moves forward, other times backward. Suddenly, the entire team sprints rapidly toward the goal, and then they bunch into a scrum again. This is followed by another sprint and yet another scrum. Their close proximity allows the team members to communicate changes in strategy to everyone on the team at the same time. If one team member is having a bad day, the others are able to easily adapt, adjust and compensate.
The Training Development Relay Race
Current approaches to instructional design resemble a relay race more than they do a rugby match. The process begins when a business partner contacts the training department about a possible training project. Someone from the training group then meets with the business partner to gather some initial requirements. The requirements are then passed on to another team member who conducts a needs analysis and produces a design document. The design document gets passed off to someone that is responsible for creating a prototype. The prototype is then passed off to a team member for testing. The finish line is finally crossed when the business partner approves the training program.
One big problem with this approach is that as the virtual baton gets passed from team member to team member, it is highly likely that the initial requirements will change and adjustments will need to be made. As Bob Mosher, the chief learning evangelist for Ontuitive, pointed out in the November issue of Chief Learning Officer magazine “Change is constant.” We need to “examine how we design content” and “who we involve.”
When changes occur, the serial nature of the current processes makes it difficult to communicate with the entire team in a way that allows everyone on the team to make the appropriate adjustments. The siloed nature of the work approach makes it challenging, if not impossible, for team members to compensate and assist other team members.
A Scrum Approach
Consider how the instructional design process would play out if it more closely resembled the rugby match that we illustrated earlier. The entire team would huddle with the customer to jointly identify the project’s requirements. The team would then meet together in scrums in order to jointly come up with a strategy. Once the strategy was agreed upon, the team would sprint forward to complete the agreed tasks. Periodically, they would come together in scrums to access progress, identify changes, and make adjustments to the strategy. If the customer changed his or her requirements the entire team would hear about it at the same time during one of the scrum sessions. The team would therefore be positioned to examine the implications of these changes holistically.
The designer and developer would be positioned to quickly come up with an approach to address a change in learning requirements. They could jointly figure out how to account for the addition of a new audience segment. If they were using the relay race approach, it’s highly likely that they wouldn’t even know that the requirements had changed until they presented their “completed” project.
If the person responsible for testing the links in a new e-learning course needed some extra hands, the entire team would know about it and be positioned to help as opposed to receiving an email that testing will take an additional week.
At DTCC, we’ve seen first-hand how creating small teams that are self-directed and dedicated full time to single projects can virtually eliminate “dropping the baton” as a result of missed communication and finding out at the last minute that the learning solution that we just spent a lot of time building was useless because the requirements changed along the way and no one knew.
A rugby match might not be as pleasant to watch as a relay race but if you’re interested in reducing the communication gaffes in your instructional design process, you might consider dropping the baton and picking up a rugby ball.