Q&A: Agile for Instructional Design

Earlier this week I had the opportunity to present a webinar, Agile for Instructional Design, to a group of graduate students from Boise State University’s Organizational Performance and Workplace Learning (OPWL) program. Associate Professor Steve Villachica invited me to speak after we met at the 2016 ISPI conference in Philadelphia . The conversation with Steve’s students was excellent, and it was encouraging to hear instructional design practitioners so enthusiastic about their study of agile and pursuit of agility. The chat window generated some great questions, and I have written up some brief responses here, Q&A style.

I’d be happy to discuss any of these ideas more. Reach out to me.

Question 1: How do you adjust the ID side of agile when the tech side of agile impacts your plan?

Bob: I believe this question refers to the idea of using an agile method and interacting with non-agile colleagues and groups. The example I gave during the chat was from the experience on my team. We use two week sprints, and sometimes it takes a week or two to publish an eLearning on our LMS. This is a problem because we want to create eLearnings and have them available to users within a two week sprint. So, we have a range of imperfect choices: (1) make the development of an eLearning piece and the publication of same as two separate stories (sub-optimal), (2) use another method to deliver the eLearnings over which we have more control (inefficient), (3) ask the LMS people to revisit their process to accommodate our need to publish faster (difficult), (4) publish eLearnings in batches so that there is not so much total wait time (slow), or (5) other things I’m not thinking of. The key is: Using a work method that asks for you to deliver frequently reveals these types of problems, which you may not have noticed otherwise. Once the problem becomes obvious enough and important enough, then the team needs to deal with it.

Question 2: It would be interesting to know how many of those people were IDs.

Bob: This is referring to the VersionOne State of Agile survey. Most respondents were from the software world. Full results are here for the 10^th annual: http://stateofagile.versionone.com/ I’m sure they would appreciate you taking a couple of minutes to respond to the current (11^th) open survey.

Question 3: Does visibility also mean adequate client sponsorship?

Bob: We talked about this a bit in the session. Visibility and transparency are some of the key benefits cited by respondents to the State of Agile survey. It is tied into the Agile Manifesto principles (http://agilemanifesto.org/principles.html)

-Business people and developers must work together daily throughout the project.
-The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

In other words, make sure everyone knows what is going on, as often as possible, so you can continually verify that you are working on the right things, and moving in the right direction. The Scrum Sprint Review ensures that your clients have an opportunity to give feedback at least every 2 weeks.

Question 4: I have a colleague in Canada who is using agile on a province-wide healthcare project. In addition to writing application code, the project will also employ online performance support and knowledge management. Her team is using agile sprints to create screen prototypes for different customer groups. Is this approach in the spirit of regular delivery? Or should the sprints deliver software?

Bob: Again, referring to the Principles of the Agile Manifesto, “the primary measure of progress is working <software>.” A prototype is not adding value if nobody is using it. If it has goodness, I would recommend a bias towards action. If the thing you create improves the situation for the user, put it out there, even if imperfect. In agile, people call it the ‘minimum viable product.’

Question 5: What if you are creating ILT?

Bob: If you are creating a large instructor-led training (ILT) course, I would suggest creating and releasing (or at least piloting) one small piece at a time. Figure out which learning objective adds the most value, that is, addresses or contributes to the remediation of the biggest problem. There are so many benefits to working this way:

-If the small piece you create misses the mark, you can fail fast and get on the right track more quickly

-You can get something out there right away that helps fix the problem

-You build in a feedback loop with your customer that happens sooner

-You actually finish one thing instead of starting 8 things and possibly not finishing any of them

-Others

Question 6: What is driving the increasing move towards agile? IT budgets? The executive suite? Customers? Increased pressure to respond to change?
Bob: There are many theories on this trend, and there has been all sorts of research happening the past decade or so to establish valid connections between agile practices and project success/team performance/etc. To some degree the jury is still out on whether agile is the answer to what ails us. (Google “agile is dead” and witness the race to be the first to declare it so.) What is not in dispute is that adoption of agile methods is still growing with no end in sight. Agile is nearly ubiquitous in the software world, and it’s catching on with all kinds of work, such as ID. Some of the big drivers of this continuing growth (IMHO) are: A way for big companies to (attempt to) keep up with the innovation pace of small companies and startups; the huge and still growing buzz in the world around agile, including conferences, certification, consultants, etc.; the prima facie benefits that it promises (productivity; innovation; happiness/engagement in the workplace)

Question 7: Is HR an "agile laggard"? The last adopter in the organization?

Bob: Yes, and…based on my observations, pretty much every occupation beyond software engineering is a laggard at this point. Agile was cooked up by, for, and of the software development world. A community of software practitioners were sick and tired of failing projects, and they felt that “traditional” long-form project management (the ‘see you in 6 months’ type) was so rife with intrinsic flaws and anti-patterns, that they figured there had to be a better way. A lot of non-software people struggle with where to start and how to translate the practices to their type of work. It’s difficult.

Question 8: What do you think about SAM as an agile approach to ID?

Bob: Michael Allen’s Successive Approximation Model (SAM) is really getting traction in our world, but I’m not totally sold. (I make a couple of oblique references to my critique in my book Agile Performance Improvement - pages 38-39, and the footnote on p 143 - but I took pains to be collegial about the topic.) Now, that’s not really fair because I haven’t read the book in its entirety, and I haven’t gone to the workshop, but….

Having said that, I would suggest trying Scrum, which is covered in detail in Chapter 4 of my book. The “official” rules of Scrum are right here in a few tidy pages: http://www.scrumguides.org/. My Chapter adds color commentary about how Scrum works for us. My big thing is: Don’t invent a new work process when there is one sitting there that works for a lot of teams. Try pure Scrum and adjust along the way. The anecdotes and guidelines that I talked about in our call are all supported by the rules of Scrum: Prioritization, 2-week iterations, limiting work in process, agile principles, etc.

Here is a link to learn more about SAM. I’d love to hear other opinions from those who have applied it to their work. http://www.alleninteractions.com/sam-process

Question 9: Are there any situations in which you think the waterfall approach is better of ID?

Bob: Who’s to say? Waterfall and Scrum are just work methods. What’s more important is the mindset of the team. You could approach Waterfall with a team mindset of relentlessly focusing on delivering value to customers and do just great. You could do Scrum without an agile mindset and have a disaster. The big distinction is that Scrum, as the most popular agile work method, was consciously designed to support teams who are committed to living and breathing the agile values and principles.