The Simplest Thing That Could Possibly Work

“Just do the simplest thing that could possibly work.” Have you ever heard this? If you have, it’s likely you were listening to someone who uses Agile. It’s a simple concept, sometimes hard to implement, and absolutely essential for an iterative development process. 

My recent session at ATD 2017 offered a deep dive into the Agile practice of developing learning materials and experiences. Essentially, Agile is more than just being flexible or delivering adaptive content. As I describe in my writing and workshops, Agile is an iterative, incremental method of guiding design and building projects in a highly flexible and interactive manner—focusing on maximizing customer value and fostering high team engagement. 

Agile principles call for the early and frequent delivery of working product, even as frequently as every two weeks. The team makes this work by delivering an MVP (minimum viable product), rather than the entire finished product. This MVP is then used to gather data about what to improve in the next iteration. Think of it like editions of a book, in which the first edition is useful, but the second edition often includes more rich descriptions, factual updates, and clarifications around previously confusing topics. Need another example? Consider modern, web-based software that is often iterated bi-weekly, with new functions and bug fixes rolling out each time. 

The goal is to get a simple version of the solution (whether it’s software, a job aid, an e-learning course, or an in-person experience) into the hands of the target population. You do this to make sure that you’re on the right track, and the feedback you gather will help you identify the highest priority things to do next. 

The MVP is what actually makes an iterative development process—like Agile, LLAMA® or SAM—work. With SAM, the Successive Approximation Model, the first iteration is the Savvy Start. With a LLAMA® (Lot Like Agile Management Approach) project, you’re defining an approach to iterating in your kickoff session, making each project unique. Agile Scrum projects deliver incremental functionality with each sprint iteration, and often wrap up with a “hardening sprint” to harmonize and fix errors across all previous iterations. 

Regardless of the flavor of Agile you use, you’re delivering a rough version of a product, not waiting to get feedback for the very end. Why? It’s easier to make changes to rough versions than finished ones, and you are identifying which changes are needed before you’ve burned all your budget and timeline developing the perfect finished product. 

Each release is an opportunity to advance the product—both iteratively (making it better) and incrementally (making it more). For an e-learning product, it could be things like fine-tuning scripts and graphics (iteratively) and moving from a script-and-screen draft to a playable online draft (incrementally). 

As you’re testing your MVPs, be sure to gather data at multiple levels. Not just “do you like it?” (Level 1), and can you pass the test on it (Level 2), but all the way to behavior (Level 3). Specifically, we’d really like to know if the users can perform the tasks successfully as a result of the training.

How do you iterate? By device, by language, by project phase or user group are all solid methods of iteration. When we kick off a project, we work with the project sponsor and stakeholders to determine what our iterations will be, who our test users will be, and how we’ll gather data. The data you gather will then fuel a new round of design and development for the project.

Connect up with me at #ATDICE2017. I’d love to hear your Agile story … iteratively! In the meantime, check out my TD at Work “Agile and LLAMA for ISD Project Management.”