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.

Agile: Simple But Not Easy (?!?!?)

 

It is often said about Agile and Scrum: It’s simple, but it’s not easy. Hogwash! Certainly it’s not easy. Teams everywhere will report that they are not good at agile at first, even experiencing a loss in productivity when starting out. It’s also not simple. Scrum advocates like to tout that the Scrum Guide is merely 13 pages long, but within those 13 pages are dozens of rules, covering ceremonies, roles and artifacts. SAFe is so unsimple that the train-the-trainer guidebook is roughly the size of Mozart’s Complete Piano Sonatas.

This state of affairs can be discouraging. Indeed, while thinking that agile is simple, teams become quickly overwhelmed with all of the things they need to deal with at the start. So, let’s narrow things down a bit. Here are five big things to keep in mind about agile.

1. Work on the most important things first
   “There is no value in squandering precious resources creating crap that nobody cares about. Value is not in producing more things. Value is in producing worthy things.” ¹ If you’re anything like most of the teams I’ve talked to and worked with, your team probably has more work in its backlog than can reasonably be expected to tackle without violating the laws of time and space. Accept the fact that you can’t work on (much less complete) everything. Accept the fact that most of the stuff in your backlog is useless and will likely deliver no value. Find a way to prioritize the work, by whatever criteria you establish, so that you first work on the things that will add the most value now.
   
   
2. Limit work in process (WIP)
   As agilist Uncle Bob Martin once said, “the nightmare scenario is to get to the end of the iteration with 90% of the tasks complete, but no stories complete.” ² The game is about delivering value, not just being industrious. And you can’t deliver value unless you finish what you start. And you can’t finish what you start if you work on too many things at once. Many agile and Kanban teams set a limit for how many stories each person can work on at once. This practice is called limiting work in process (WIP).  A common WIP limit is 2. Yes, that seems like a ridiculously low amount of work items, but research has shown it to be ideal.
   
   
3. Frequently deliver in small increments.
   The power of agile is expressed in (among others) the first of the Principles Behind the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” Rather than taking 6 months or a year producing your output without getting feedback, find a way to develop and deliver products in small, more frequent deliveries. This way, you can get feedback from your customer and adjust accordingly. Remember, on that day when you create a huge project plan that covers many months of work, you know less about the work and how your customer will receive it than you will at any point after.
   
   
4. Make it a team sport
   Many organizations starting off in agile start using the terminology, having the meetings, and putting work in an agile planning tool without really changing the way that they work. This is called being “Agile in Name Only (AINO).” A common symptom is having people work alone on the same work they worked on before becoming AINO. Then the larger organization reinforces these patterns by evaluating and reward performance as individuals. Agile is team-oriented, and agilists believe that the best results come from working as a cross-functional team.

5. Continuously improve
   Regular cycles of inspecting and adapting work output and team collaboration are essential. Scrum teams typically conduct a retrospective meeting every two weeks, and make commitments to improve something in the way they work every time. It should be obvious that discussing team health fortnightly rather than annually will yield better performance.

If you want to simplify agile, keep these things Five Big Things in mind at the beginning of your journey, and your team will avoid many of the pitfalls that discourage teams and make them give up trying to be agile.

Please add comments below or tweet them to be @TheBobWinter.

References

¹Winter, Bob. Agile Performance Improvement, Islandia, NY: Apress, 2015, page 210

²Martin, Robert C. Agile Software Development: Principles, Patterns, and Practices. Upper Saddle River, NJ: Prentice Hall, 2003. Page 22. I

Agile For Non-Software Teams: Three Steps to Get Started

I speak often with agile novices about the benefits and, frankly, beauty of being agile. It sounds good enough: Be adaptable to change; delivery value more consistently, work at a sustainable pace as a real team. Basically, the promise of agile is to fix everything that sucks about work. But then, there’s this leap. Agile was invented by and for software makers. The Agile Manifesto and Principles mention ‘software’ five times and all other forms of work output zero times. How do you practice agile when you’re not, as the preamble to the Agile Manifesto declares, “developing software”?

Step 1: Declare your rationale

A lot of teams decide to start practicing agile for flimsy reasons. This applies to software and non-software teams alike. Some of the common reasons I’ve heard are: Our management hierarchy told us to start doing agile; a book tells us we can do twice the work in half the time; everyone else around us is doing it. Those types of reasons are understandable and, in some case, arguable, but they miss the point. They don’t provide a rationale for why it would help YOUR team perform better. Have a team discussion and agree on the answer to this question: What benefit do you as a team expect to reap from practicing agile? If you can’t agree to why you are doing agile, it might not be a great idea right now. Whatever answer you come up with can be a core component of your mission or vision. If you can identify a metric that helps you quantify the benefit, you can make it the basis of a team goal.

Step 2: Define a story

In agile software development, stories (aka work items) refer to new features for software. If your output is not software features, an important first step is to define what you mean by a story with your product. In order to do so, you need to define what your product offering is and what a feature is. The instinct for many is to define everything that you do as a story, but that is a misguided notion.

For discussion purposes, take the example of a fictitious company called Super Bicycles, whose mission is to improving the design of their line of bicycles. There are all sorts of things that you do that do not improve the design of a bicycle. You have meetings, you hire employees, you pay employees, you pay the rent on the workshop, and a zillion other things. Those things aren’t stories; they are just things that you do. A story is something that you create that enhance the perceived or actual value of your product. Stories in the improved bicycle product backlog are only features that improve the customer value of Super Bicycles. That backlog of new product features is entirely focused on improving the bike's design.

Step 3: Decide where to start

From there a team is ready to really move towards agility. Typically a team can start with a list generated in response to the question: What’s the ONE most important thing to focus on first? Start a list and prioritize it. Many teams start their journey toward agility in a state of being overly busy, where everything is “really really important.” Remember that “important” is a relative term – if everything is important than nothing is important. Take your list of potential places to start and commit to tackling THE most important thing. Examine the assumption that there are things that have to be done before we can work on the most important things. Focus on the actual most important things. What could you do right now that will make the biggest difference? Start with that one thing and crush it. And don’t worry about all of the other most important things – they are, by definition, less important than the most important thing.

These three steps will help your team to find purpose with agile. Whether or not you develop software, your team will improve its chances of enjoying the rewards of higher productivity and quality that agile promises.

Facilitator's Notebook: Going Off Script

As I arrived to deliver a soft skills workshop, I started to have misgivings. I don’t really know what is going on with these people. Do they need what I have to offer? What if they disagree with the premise (learning/performance objectives) of the course? What if something is going on in the work environment that distracts them from what’s at hand here in the formal learning environment?

I reflect on the last conversation I had with the manager, who mandated that everyone in his reporting line (15 people) attend. We had discussed the business problem at hand, and we agreed that my workshop would contribute to preparing the team to navigate it.

In order improve the chances that we will accomplish something meaningful in the session, that is, a disruption that will help the participants to perform better at their jobs, the facilitator needs to be ready to go off-script. We need to be ready to ditch what is planned in order to focus on what is needed. As such, here are four facilitation techniques to consider:

Elicit the elephant in the room. It’s fun and energizing to start a class with an “ice-breaker.” What if instead you start with questions that ask each person to articulate what they want to get out of the class and the concerns they bring to it? If there is a truth or challenge common to everyone in the room except the facilitator, that’s a problem. Generally by the time you get around a room of 15 people, the elephant will be revealed. Acknowledge it and discuss what it means to the today’s work.

Gain unanimous agreement the purpose. Instead of learning objectives, propose a purpose for the session. After presenting the purpose, ask for agreement to proceed with it. If the consensus to proceed is not unanimous among all participants, ask dissenters what would need to change in order to be on-board with the rest of the group. Use the responses to refine the purpose before moving on.

Be ready to shift. Based on a refined purpose and any revealed elephants, be responsive to this new data throughout the day. Don’t be married to your agenda. Focus on providing what will have the greatest impact for the participants. Check in frequently, with yourself and the group, to ensure that what you are doing still serves the agree-upon purpose.

Have participants articulate their (very few) commitments. Presumably, people attend your class to prepare to do a better job. As a pro facilitator you remember this, but participants might not. The class likely includes more information and idea than one can reasonably be expected to retain. Before adjourning, take a few minutes to have each participant write down and declare before their colleagues their commitment to bring one specific approach back to the job.

In my instructional design days, I recall being required to script every word that the trainer would say. If, in observing teach-backs or the actual delivery of the course, I found that a talking point was missed or mangled, I felt compelled to provide corrective feedback. Somehow corrective feedback became more important than how the participants responded to the class.

It might seem that these facilitation techniques are only applicable to soft skills training or consulting conversations. For example, if you are teaching basic job skills, you need to stick to the script, right? Well, not necessarily. A faulty assumption in many new hire or functional training courses is that the people entering the class can’t do anything. Chances are, many in the room have had some time on the job and/or have done a comparable job in the past. Instead of making this an experience where participants have to slog through a class of limited value, ask them what they need to get better at doing their job. Then be ready to go off-script, with purpose.

If you create things as part of a team, you should read my book, AgilePerformance Improvement. Now until May 10, get 30% off if you buy it through Springer.com with the discount code 'Winter2016'. Also available on Amazon.

A Week with Disney - a consultant's review

Last week, my family and I (Figure 1) embarked on a full week of the Disney experience. This included 3 days in Walt Disney World and a 4-day cruise aboard the Disney Dream liner. Much has been written and said about the Disney experience in general. Let’s get beyond the obvious (it’s great for families; it’s expensive; it’s “magical”) and note the 3 best things and 3 not-so-great things about the experience.

The 3 Best Things

The staff

For decades now, Disney has been renowned for it’s impeccable service. Well, in 2016 it can’t be overstated how consistently good the staff is. Every employee from the captain of the Disney Dream to the room attendants at the Beach Club was as friendly and personable as the most gregarious bartender at your local watering hole or touristy pub in a major city. Everyone seems to hit that sweet spot of being friendly and professional without being annoying or insincere. No offstage business was conducted in front of customers.

Cleanliness

Normally, the state of cleanliness and sanitation is one of those things you don’t take note of unless something is wrong. At Disney World and on the Disney Dream, things are so tidy that you start wondering if there are any flaws in this area. Run you finger on a surface in a dark corner of the Tower of Terror attraction and find no dust. Note the man in the Magic Kingdom carefully wiping morning dew off of the garbage containers. See the person polishing the chrome on a junction box in the corner of a deck on the Disney Dream. Look hard and fail to any quality issues or inconsistency in the presentation of the 100-foot long breakfast buffet over 4 mornings. It all adds up to total confidence in the sanitation and, particularly on the cruise ship, safety.

Impeccable processes

As consultants we know that consistency at the scale of Disney resorts is the result of highly refined processes and quality programs. With no specific knowledge of their practices in this area, the very absence of problems, even forgivable ones, attests to the work they do in this area. With a family of four in one room, I never ran out of towels, struggled to find a light switch, or found anything in need of maintenance. Amid swimming pools and rainy days aboard a cruise ship, I never encountered a puddle, a slippery floor, or a wet lounge chair. And, while there are more than a few crying children around, I never saw any adults upset or angry with anything in Disney’s control.

Figure 1. Happy Disney Family. Disney offers so much to make families happy, from wonderful employees to impeccable processes that never distract from the magic.

3 Areas for Improvement

Technology

Make no mistake. Disney has technology that benefits users. The wrist bands they issue prior to your visit are spectacularly effective, as they help you to easily enter parks, get into your hotel room, and charge things to your room. However, there is room for improvement, particularly on the cruise. The Disney Cruise app is not as useful as one would hope. The wrist band is swapped out for an unweildy card, which you need for everything. There is obviously no 3G/4G at sea, yet the Wifi is slow and expensive ($80 for 4 days?!?!)
Recommendation: As a Disney Cruise guest, I need easy access to the level of technology I expect in 2016, so that I don’t get aggravated with lack of same. Prioritize an investment in the development of more modern technology.

Partner relations

In consideration fo the end-to-end experience, things change dramatically (shall I say become much less “magical”?) once you are put into the hands of non-Disney entities. A sub-contracted bus service takes runners to and from the runDisney Health and Fitness Expo. Gone is the Disney TV and music content, in favor of, in one case, conservative talk radio. Instead of the driver making helpful and exquisitely timed and worded announcements, you have drivers getting lost and instigating arguments with Disney staff at the pick-up spots. The snorkeling excursion off of Nassau put us on a rickety and dirty 3rd party boat. The TSA process at Orlando International Airport (Figure 2), as it has every time I’ve ever used it, was horrendously slow and aggravating, putting one in mind of the refugee camp we see at the beginning of Scarface.
Recommendation: As a Disney guest, I need the entire experience between arriving and departing Florida to have the same groove as my experience under the care of Disney employees, so I maintain good will throughout the trip. Use Disney buses for the Expo; manage the excursions; and dare I say, build a major international airport at Disney World.

Figure 2. MCO. It’s not the refugee camp we see at the beginning of Scarface. It’s the start of a typically sweaty and aggravating 35-minute experience at the TSA security checkpoint at Orlando International Airport, Hey Disney, shake these people and build your own airport.

Over-enthusiasm

OK, maybe this isn’t quite fair. Above I gush about the employees, but sometimes you can have too much of a good thing. I don’t need to have every person carrying a broom to ask me how I’m enjoying my vacation. I don’t need the Cruise Director to ask the audience to cheer or scream 8 times before the curtain goes up a live show. And I don’t need to have a cheery 3-minute conversation with the (otherwise wonderful) room attendant about what/how I am doing every time I go near my stateroom.
Recommendation: As a Disney guest, I need the employees to strike the right balance in their interactions, so that I can relax. This is a tough one. I trust that Disney has carefully honed the type of employee personas they want based on what makes their typical guests happy. It’s too much for me, sometimes. Maybe they need to teach their employees to better adapt their approach with guests of different dispositions.

Epilogue

Heavy rains delay our connecting flight home from Richmond to Boston. The best things about Disney become starkly clear in contrast. Suddenly problems appear at every turn. An obviously stressed-out agent at a gate counter becomes borderline abusive to a customer. My chicken wings are lukewarm and have no celery sticks. The pizza place is out of pizza. Oh look, the register at the bar can’t accept credit cards. There’s piss all over the floor beneath the urinals.

Now I wonder. Is the Richmond Airport any worse than any other airport, or is it just following a tough act to follow?