Containers and Fidelity

So last week I dropped down some principles for Agile Learning Design and I want to unpack each of these a little. However, I figured there’s one there that might need some extra explanation – number 5 – so let’s start there.

Content is content until it is something else. We use “content” as a container to get things out of the SMEs head. Write it all out to start and iterate through it. Begin with dot points, add paragraphs, add guiding comments and increase the fidelity over time. Text is mutable, it’s easy to transform into a HTML page, a video script or an interactive – but you can’t do any of that without knowing what the content is.

So Containers and Fidelity?

---

I came across the term container words a few years back during my Federated Wiki exploration. The basic idea is that container words describe large phenomena: like content, traffic, art, sex or weather.

They’re incredibly useful for describing things at at scale but what I was finding was that they were less than useful the more you zoom in. At the time I was railing against them because so often they are used in ways that confuse or obscure the underlying problem:

In fact not only are they less useful, they are disruptive and obstructive. They get in the way of discussions or obscure the necessary details to properly define and identify.

What I’ve come to appreciate though is that context is key with container words. At the heart of what I was railing against was the application of container words to the wrong thing. You can’t use use container words to solve problems. What the problem with content, sex or traffic? There’s no possible way to tell.

As I wrote at about the same time:

The devil is in the detail. The problems and complexities inherent in something as generic as content are vitally important.

If we want to solve the problems with traffic then we have to unpack it more – are we talking about roads, cars, numbers, types, intersections, pedestrians, bike, signage?

The other thing I’ve learnt is that when you use container words matters. What I failed to appreciate is that at some points in a process – the details don’t matter. Sometimes you need the details and you need these to be precise – you need fidelity. But sometimes adding detail can just add confusion instead of clarity. You can and need to choose the right fidelity to work during a project, and at some points working with less fidelity is better — faster, more efficient and more expedient solution.

One of the key differences between an agile and a waterfall process is the need for specificity up front. Waterfall processes require everything to be specced out up-front and in great detail. It’s what allows you to develop the waterfall — when and what is going to happen throughout the process. It’s long and arduous and from my experience the root cause of project failure and overspend. Why? Because of lock in – you’ve already allocated your budget and resources, so if anything needs to change it has an immediate knock on effect. One small change and the whole thing cascades through the rest of the project — maybe that’s why they call it waterfall.

What an agile process allows us to do is pick the point in time in which we need fidelity and to only worry about it then. This allows use to use “containers” to build out a project and then iterate through the detail and increase the fidelity of the solution . Just like zooming into Google Maps, you start off with a rough map that only includes key features, the main roads and destination. This is perfect to gauge direction, routes and distance – but you’re unlikely to navigate through your drive at this view but it is the best setup to plan. Once you chosen your route you can start your journey. The first part is from home – you already know the roads and directions, so you don’t need to zoom in too much, maybe just enough to define the main roads you’re travelling on. But at some point you get to unfamiliar territory and now is when you need to get into the details. Now you need the fidelity of the street level — details like street names, landmarks and signposts start to matter.

If we apply this process to learning design it allows us to use containers to help shape and define the process, but customise the product. Combining container with an iterative agile approach and what we do is add details through each iteration of the course. So we might start with containers like “content”, “practice”, “discussion”, “assessment”, “review” and “social interaction” to help define and sketch out the learning experience. Then we proceed to map these out further – going through week-by-week and adding in what students are doing, what topics they need to cover, what skills will they need and what feedback will they need to succeed. And we keep doing this, fleshing out the details each time, adding in connections to other modules and topics, starting to define what media we might use and assets we will create.

The practical way we have for doing this is text. Everything is text to begin with usually we just start with dot points, but text is easy to change, edit and move. And as we build out the course we need that flexibility. We need to change the flow of the experience but often this doesn’t happen until you have something on the page. The shape of the course emerges from the content as we develop it. The containers allow us the fidelity we need along the way until finally they are replaced by course elements – interactive, videos, activities.

This element of agile practice is probably the biggest changes, and one of the hardest. We so often default to trying to work out how many videos and elements we’ll need before we get even a word on written down. And that locks us in, it has a knock on effect with production teams and resourcing. I understand why we do it – but to be honest it so rarely ever works, and at worst actually inhibits the development process itself. Trying to scope out everything up front is like trying to choose a direction in the dark – you don’t know what you don’t know. So rather than having a course that is bespoke – that matches the discipline and audience – we default to one-size-fits-all templates that in the end fit in the same way that a sack does.

Agile design practices require you to understand emergence – that the shape and form of the course will come by going through the process of learning design. Containers and the idea of increasing fidelity as you go provide the structure required to get the work done and allow that emergence to happen. At the same time this isn’t a set-and-forget process, instead it requires learning designers to engage, steer and drive the process itself. Learning designers become the key to how this all comes together, and without them it’s not a process that will work.

Advertisement