An Origin Story for Agile Learning Design

I’m going to try and keep going with the writing. Rather than aim for the masterful tome, I’m just going to approach it as a series of connected pieces. For me I just need to externalise some of my thoughts and see what sticks. I’ll come back and refine things later.

I want to talk a bit about work – how I work and how my team works. Why? Well I think we do things a bit differently and I think it’s why I feel at home working with my colleagues here in Adelaide. We’re singing from the same book on so many things. Over the next couple of posts I want to talk about Agile Learning Design. I want to do this because I think it’s a different way of working that really underpins how we do things and why it might be a bit different. As a team we’ve developed this approach through experience, and often not of the pleasant kind. What I’ve tried to contribute over the last year and a bit is to take those ideas and bring them together, add some shape and definition to them and in doing so embraced them in order to influence some of the core things we do in our learning design. But rather than do it in one go, I’m going to try and break it into some smaller pieces and posts.

---

The Seeds

I spent the first half of my career working on projects that utilised a waterfall approach. In the end we always achieved what we set out to do, but more often than not it was in spite of the project methodology used rather than because of it. It was only through the hard work and determination of those working on it that enabled it to succeed. It was at the end of one particular project, that chewed up about 18 months of my life and wasted hundreds of thousands of dollars, that I decided I needed to find another way. When I started to search for alternatives what I ended up doing was asking myself was “what exactly are the problems with traditional waterfall projects?”.

The Problem

Traditional waterfall methods tend make projects too big, too slow and too expensive. There is a lack of knowledge and learning built into the process itself, every project is treated as something new and fresh, so regardless of the individuals involved, the same process is applied. This all started to feel stupid, not the projects themselves or the project managers, but the process itself.

My real concern though was just how badly they would respond to change. And I mean ANY change, no matter how small or insignificant it seems, any change results in a blowout in the allocated time and budget. Waterfall projects are so fragile they simply self-destruct when faced with change. There is no ability to adapt, they can’t respond to changes in circumstance nor do they have the mechanisms to allow manoeuvrability. 

Yet somehow projects get done. Outcomes are achieved and things get delivered. When you peel back the facade and start to poke around how and why that happened what do you find? People. People did it. People worked harder, adapted and responded. They manourvered resources and spent extra time and budget (that somehow magicked itself into existence) in order to get things done. And this is all IN SPITE of the process rather than because of it.

The Solution

With that in mind what I was looking for was something that was more flexible and fluid. Something that could adapt to change fairly rapidly while still providing a level of structure and accountability to know where we were going and how far along we were.

This point in time agile was more of a philosophy that I methodology (still small-a agile rather than Agile). While it may have been popular in software development it hadn’t really made its way outside of that discipline. So without the constraints of a method, I found the agile philosophy engaging.

About the same time Eric Ries published the Lean Startup. The cyclical process outlined in the book – Build, Measure, Learn – made a lot of sense to me. My experience in so many projects was that the solution often emerged, but not during the “planning” stage but in the doing stage. What I also noticed it was such a huge thing to get Version 1 up and running, and every-time it had massive problems, problems that were unforeseen, that couldn’t have been predicted or anticipated. Yet once that version was up it became easier to fix and change and adapt. By moving in cycles you could test and refine your work, learn the process and from the feedback available to you because you have a real thing that people can use, touch and interact with as opposed to a flat pixel perfect mock-up.

The solution for me was to take these two ideas and smoosh them together and what I ended up with as a philosophy as much as a methodology. The focus switched from a linear concept of a project to cycles and iterations. Rather than focus on stages and steps I switched to thinking of versions and fidelity.

Rather than thinking about waterfalls I began to think about projects as snowballs.

You build them as you go, starting off small as you go round and around adding in detail as you roll through the process. You begin to create momentum as the team comes together forming and reforming the project as it gathers heft and as we flesh it out. What started out as a kernel of an idea and as you go through that process you grow it, you build on it, you refine it, you shave off the bumps and edges as you gather more momentum and speed. This helps as the project timeline goes on and you get closer to the deadline. Rather than it being an impediment, the momentum and speed drives everything on towards the deadline and you can use it to carry the whole project on through. Rather than deadlines being a barrier and an impediment that so often fights against this force, a snowball project harnesses that energy and it becomes part of the that way of working.

In Practice

It seems like an age ago but it was close to 10 years since I started working on the mLearn Project at CSU. It was the first real thing I was put in charge of. A million dollar multi-year project to explore mobile technology and how it could be applied to teaching and learning. It was an amazing opportunity – not just because the work was interesting but because I was in charge! I could do things MY WAY!

It was the first time I got to put all of this stuff into practice – and it worked. I had an amazing team, and the process we had, while often chaotic and ad-hoc, worked. Not just in the sense of us being able to deliver – but in having a process that didn’t get in the way and enhanced what we were doing. Yes there were issues – but from each one we learnt. I can honestly say that in the 10 years since that project I have never made those same mistakes!

The biggest change though was that when change happened (as it always does) things didn’t fall in a heap. The project never went off the rails, we just pivoted and moved on. When we got crunched for time, we had a way to reduce the work required to get us across the line. How? Because we were iterating the whole time. We already had something there, yes it might have been lower fidelity than we wanted, but something existed and we could fall back to that and focus our energies on other areas. Was what we released the version we hoped? No, but we’d simply fix it in the next iteration.

The project itself ran its duration and we ended up with money left over. We delivered everything we set out to do. For all intents and purposes it was a highly successful project. It’s a pity that the institution didn’t want to adopt a lot of our recommendations or pursue some of the innovations we started, but that’s probably another story.

What I took a way from the experience was an alternative way to do things. One that worked and worked well. It’s been something that I’ve tried to apply to almost all of my other work – with varying degrees of success. Often I was hamstrung or trying to operate within another project or more senior people wanted things done in a particular way. I missed the autonomy I had with mLearn, and it’s not till I arrived at Adelaide I felt I had it again.

And the surprising thing for me was that I had found the others. A whole team who felt the same way, worked the same way and wanted to keep improving on the processes and practices. The ideology unites us and makes us an incredibly strong team. I don’t know of another who could have launched a new MOOC every two weeks for 3 months during the first COVID lockdown.

And that was just the beginning.

In the next couple of posts I want to move beyond this origin story and start to delve into the how, what and why of Agile Learning Design.

Advertisement