When you think about implementing agile methodologies, do you think of IT teams? If so, you are not alone. In practice, agile methodologies such as Scrum and Kanban have been predominately adopted by IT teams due to the type of work these teams release.
Non-IT teams may struggle with breaking down their work into smaller pieces to deliver within a shorter timeframe and therefore may be hesitant to adopt agile. As an instructional designer, I was used to the traditional waterfall approach; I could plan for all my deliverables up front and choose a designated time when they were all due, which was typically several months down the line. Instructors often cope with factors that can influence the development timeframe for any training document. Example obstacles include a change of scope, the system not being ready, undefined processes, key decisions not yet made, role changes being in process, the unavailability of the subject matter expert, etc. It just did not seem possible to complete any substantial asset in a short timeframe—until I saw agile in action.
I’ve been working on a Learning and Development Scrum team with three other instructional designers to develop learner-to-performer journeys and training materials for a client whose IT organization is going through an agile transformation. What better way to design and develop training for newly forming agile teams than to work and progress as an agile team ourselves? Our team of designers act as the traditional development team in the Scrum model. Our team has a Scrum master who ensures the team follows Scrum practices, removes obstacles, manages risks, and provides an environment for continuous improvement. Instead of the traditional product owner, who owns the vision and requirements for the work (we do a lot of this as instructional designers), we have what we call a backlog manager. This role manages the intake of our work from the business and helps us track and prioritize what we work on. On many projects, the Scrum master and product owner split the work of a typical project manager.
Though we had our challenges while adjusting to a new way of working, we are now a high-performing Scrum team, releasing deliverables every 3 weeks. In order to reach this point of success, however, our team needed to have the following criteria in place.
Have a scrum master who removes barriers. Momentum can significantly slow if the team is not able to adapt and push through development blocks. Having a scrum master who is highly engaged, is willing to find answers, and knows how to help the team shift priorities allows the designers to continuously stay productive throughout each sprint.
Having clear priorities filter down from project leadership is also critical for our team to manage the intake requests received from numerous business stakeholders. On our team, the backlog manager and Scrum master attend weekly priority meetings to provide and receive updates on work for our team. This helps us plan faster and more effectively for each sprint and provides the business with deliverables that will add the most value for them as quickly as possible.
Lastly, the notion of being pulled to the work is critical for our team to maintain momentum. This means that we only work on assets that align with current business needs so that our subject matter experts are engaged to support. As many instructional designers experience, we were asked to develop certain assets but because the business did not have an urgent need for those assets, when we found gaps or had questions on the content we were provided, we struggled to get support because our subject matter experts were being pulled into higher priority tasks. This slows down design and development significantly,. We solve for this through the stories we track on our Scrum board each sprint. We create a story solely for content review and curation, if sufficient content has not been provided, that is separate from design and development to ensure the designer has all that they need when it is time to develop. This not only puts more ownership on the business to provide the needed material before development can start, but it also helps limit rework for the designer if development starts too early.
This new way of working has been effective for our team to continually have a steady stream of work throughout the project. It also helps us manage scope and deadlines when we plan the work; we complete each sprint ahead of time, with stretch goals to take on more work if time allows. This helps ensure the team does not get overloaded but still challenges us to complete more within the sprint. Using the agile approach gives our team the ability to release training content quicker so our end users can start using the content when they need it. Agile also allows us to receive feedback early so we can iterate on it and apply that feedback to future assets we develop.
Agile is not just for IT developers. If implemented effectively, being agile is a fast and efficient way to produce on-demand training for our clients. Even if your team is not set up with a Scrum master and product owner, your project manager can fill this role by helping the team plan and prioritize work to focus on and complete within shorter timeframes. Even if your deadlines are months down the line, working in sprints can help ensure steady progress is made, and daily standup meetings allow all team members to stay informed of progress and any barriers that arise. At the end of each sprint, team members reflect on what went well and what did not, which helps the team to continuously improve the processes going forward. There are many benefits to working this way for both the project team as well as for the client. Give agile a try and see how you like it!
Latest posts by Michelle Crowe (see all)
- Implementing Agile on a Learning and Development Team - July 30, 2019