- The Epic
- User Story 9.1: Draft Training Presentations
- User Story 9.2: Test Training Presentation
- User Story 9.3: Deliver Training to [Group/Team]
As the Change Team, we want to gain support among, and provide training to, all stakeholder groups and teams, to reduce resistance to the desired behavior changes.
Initial training needs to be provided to each stakeholder group identified in Epic 5 and the potential Agile teams, so that no one is surprised by the implementation of Agile, your chosen system, or the specific behavior changes group members will be asked to make. As with any skill, most of the learning will come in the coaching and doing. Thus the goal of this formal training is not so much skill development as it is providing context or background for what’s to come. The training is also yet another opportunity to reduce resistance to change (RTC) by increasing understanding and dialog.
For this reason, I believe trainings lasting more than an hour or two are a waste of productive time. Research on adult learning proves a tiny percentage of the information from long trainings (including experiential ones) is retained, making the three-day or weeklong classes sold by for-profit consulting firms just as questionable as pre-planning months of work in waterfall. So the trainings in this epic are seen as lasting a maximum of two hours per stakeholder group, including at least a half-hour for Q&A.
Each training must include Agile 101 highlights; the justifications for structural changes mentioned in the leadership presentation (per US 6.1); and a description of the system you chose. Beyond that, it will be tailored to the needs of the specific group/team, such as:
- Ensure managers accustomed to controlling silos can articulate the reasons for the change and, critically, that they understand what decisions they can and cannot make under the system—many will struggle, for example, with the idea that their work requests of employees must go through the same backlog process as those of customers.
- External groups must understand how and when they can insert their requirements into backlogs, and how they can check progress.
- Teams need more detailed introductions to the mechanics of the system and how it will impact them on a daily basis.
For maximum impact, provide this training as close as possible to the start date for implementing the system. This means you should probably have your Agile tool (mentioned under Epic 10) chosen and set up, allowing you also to show its basics as part of the training. Typically I try to give all trainings within three weeks before the implementation date.
If you hired a coach, it may make sense to consider them the change leader (not the “sponsor”) at this point, if the initial leader is comfortable with that. In that case the prior leader can add value as an “ex-officio” member of the Change Team.
As the change leader, I want to draft training materials, and scripts appropriate to each stakeholder or team type, to get input and improve training effectiveness.
As with the leader presentation from US 6.1, prepare visuals according to the expectations of the organizational culture and/or preferences. Given the common elements, I find it is easiest to prepare one set of visuals and skip the irrelevant items during a given training. This also enhances transparency, because everyone can download the visuals later and see what everyone else saw! Create notes of what you want to cover for each group as well. For an example of training slide text (or if you chose FuSca™), download the FuSca Proposal Slides.
On the assumption this will take most of a month, the output of this story is a draft for feedback.
- Draft the presentation and scripts/notes, including customizations for different stakeholders and work teams.
- Publish the draft.
- Schedule a meeting with the sponsor and Change Team, including a link to the draft presentation and requesting written feedback from those who can’t attend.
As the change leader, I want input on the stakeholder training to ensure maximum effectiveness.
Present the team-level (most detailed) version of the training to the Change Team, not only to get feedback but also to reinforce critical messages members should be conveying back to their organizations.
- At the meeting, deliver the presentation, read out any written comments, and facilitate consensus on changes required to the materials or words said.
- Update and publish the materials.
As the change leader, I want to present the Agile system training to [group/team], to gain input and reduce negative resistance.
Notice the reason given for this story. Recall from the US 2.3 discussion that training by itself has limited impact on learning and even less on behaviors. Though this training lays the foundation for later coaching, a key outcome is to reduce initial resistance founded on rumor and misconceptions. Here is one very typical example: People may have heard (falsely) that Agile means you don’t have to document anything, and become resistant when the chosen system requires a degree of documentation in the form of detailed user stories. The training allows you to point out what the Agile Manifesto actually says and cut off some RTC before it starts.
Again, create a separate copy of this story and its tasks for each group or team trained.
- Schedule the training.
- Deliver the training.
- Follow up on any questions you could not answer during the training.