Agile development is a popular topic. So popular that even learning and development teams are talking about it. Robert Winter of CA Technologies raises this question in a preview to his Performance Improvement Conference talk in mid-April, “Is Agile Compatible with Human Performance Technology (HPT)?” And since I am an HPT’er at heart, I believe the answer is, “Yes.”
The article begs the question, “How can I implement agile development methodologies in my learning design team? This is not an easy question to answer since there are so many ways to implement agile. Scrum is one way. And when you start to learn about Scrum, you realize how applicable it is to developing learning content. I thought I would summarize the major events of Scrum, which are detailed in the Scrum Guide. Once you learn about scrum, you will go back to your team and say, “Hey, we gotta do this!"
Here are the five major events in Scrum.
A Sprint is a window of time (one-month, for example) during which a specified body of work is completed and, at the end of which, a feature, product, or some other “product increment” is created. In the world of learning design, a Sprint could produce and added module to an existing course or it could produce updates to an existing enterprise software training course when the software has had a major update. Once a Sprint is completed, a new Sprint begins and tackles new tasks. Sprints repeats until a product is completed or in perpetuity depending on the product.
Here is how it would work on your learning design team:
All the work that needs to be done in a Sprint is listed during a Sprint Planning process. Let’s say you need to update a software training course because a new version of the software is being released. A Sprint Planning process would list everything that needs to be changed in the course. Then decisions will be made about what can get done during the Sprint time frame. This is the hard part because it is unlikely that everything can get done during the time frame you have. In other words, maybe you can replace all of the screen shots, re-write scripts, re-record the audio, but you are not sure if you can redesign the course template, like you have always wanted. During the Sprint Planning process you must make a decision to not update the template during this Sprint, but that you will do it during the next Sprint. The key is that everyone on the team is clear about what will get done during that Sprint and who will do it.
Once a Sprint begins, the team holds a daily, 15-minute meeting to discuss what will happen that day. This process keeps everyone aligned on the goals of the Sprint and keeps work moving along. The Daily Scrum is a chance to raise issues, remove blockers, and hold team members accountable. For example, during the Wednesday morning Daily Scrum, someone raises the issue that they cannot capture screen shots because the product team is still working on the reporting engine. This can impact your ability to capture the screen shots and get them into the course update during this Sprint because the product team will not finalize the screen layout until next week. This is when the team lead needs to figure out how to remove this blocker so the work can get done or make the hard choice to have updated screens during this Sprint. The point of the Daily Scrum is to raise these issues as they happen (each morning) so nothing takes the team by surprise at the last minute.
A Sprint Review is a meeting that is held at the end of a Sprint to review what tasks were “Done” and “Not Done” during the Sprint. This meeting is a chance to review and demonstrate what was accomplished during the Sprint with key stakeholders. It is also a chance to discuss what was not accomplished and how and whether those tasks will be addressed in a future Sprint. Let’s continue the example of the screen shot problem that was raised in one of the Daily Scrums. It turns out, the team was unable to update the screen shots in the new reporting engine because the product team was unable to finalize the page design in time for your team to update the course. The Scrum team would discuss how and why this happened with the expressed purpose of getting the screen shots updated at the next possible time, which could be in the next Sprint or further in the future. This depends on how the product team is progressing on the new reporting engine. By taking the time to do a Sprint Review, the team can communicate to key stakeholders what got done, what did not get done, and why.
Whereas a Sprint Review is tactical, a Sprint Retrospective is more strategic and a chance for the team to “inspect itself” and make improvements for the future. Things that can be covered during the Retrospective are how the last Sprint went in terms of “people, relationships, process, and tools.” It is also a chance to discuss plans for making improvements in these areas. In the example of the reporting engine screen shots, a Retrospective may uncover that this issue should have been raised earlier. This way, the team leaders may have been able to talk to the product team sooner and get the design completed on time. Another possible outcome of the Retrospective could have been that the team discovers that they are much more dependent on the timeline of the product team than they thought, so when conducting future Sprint Planning sessions, they may want to invite a member of the product team to help guide the planning process. That could be a way to improve Sprint Planning and improve what can get completed during Sprints.
Is Scrum for You?
Pretty easy, right? As it states in the Scrum Guide, Scrum is easy to understand, but difficult to master. I recommend reading the Scrum Guide. It will change the way you think about how to get work done on your team. Even if you don’t adopt a full-blown Scrum process, you will find yourself adopting parts, like the Daily Scrum, Sprints, and Sprint Planning, for example.
This blog post originally appeared on the humancapitalist blog.