There’s a lot of interest in agile in project management, quality improvement, and software engineering. Many organizations either have or are switching to agile. The agile literature has also started appearing in instructional design, eLearning, and performance improvement fields—with different degrees of success. Some of the literature makes claims about being agile without actually following agile practices. Sadly, there are few examples of OPWL organizations that actually practice agile. Join us for someone who actually uses agile in instructional design and other performance improvement efforts. Our guest, Bob Winter, has actually written a book on agile in performance improvement. During our hour together, Bob Winter will:
- Review the history, principles and terminology of agile
- Provide examples of how agile can be applied to instructional design and performance improvement
- Invite participants to examine where they are on their own agile journey
Susan: 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.
Susan: 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 10th annual: http://stateofagile.versionone.com/ I’m sure they would appreciate you taking a couple of minutes to respond to the current (11th) open survey.
Steve Villachica: 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.
Steve Villachica: 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.’
Lisa Giacumo: 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
Steve Villachica: 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 pace 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)
Steve Villachica: 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.
Michelle: What do you think about SAM as an agile approach to ID?
Bob: 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.
Linda Scott: 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.
Bob Winter is the Product Owner for CA Technology’s Enterprise Agility group, which focuses on agile enablement and education. In his work, he consults with executives to establish priorities yielding the highest value impact. Bob is an advocate for self-directed and collaborative work habits and is a frequent conference presenter and thought leader in the optimization of team performance.
He holds many industry credentials, including Certified Scrum Professional (ScrumAlliance) and Certified Performance Technologist (ISPI). Bob’s first book, Agile Performance Improvement: The New Synergy of Agile and Human Performance Technology, was published in 2015 by Apress. He is the author of the It Ain’t Training blog, and he tweets as @TheBobWinter.
Bob lives in Marblehead Massachusetts with his wife and two kids. He enjoys running, playing hockey, sailing, and coaching youth sports.