Agility through collaboration

Instead of factory-style production teams, agile programming uses far fewer, but better, programmers. The principles of communicating, focusing on simplicity, releasing often and testing often are also applicable to developing good instructional programs. Does instructional systems design (ISD) need more agility? An ISD project team should be able to return to the Analysis or Design phase and make changes while instructional content Development is taking place. If not, changing conditions cannot be accommodated and the programme is outdated before it’s even finished. I wonder how many content development shops actually have a process that enables them to rebuild after the design specification has been signed off.

The root of the problem is that ISD views instruction as separate from work. Instruction is perceived as something that can be designed, developed and delivered as a programme, not integrated with the work to be done. Subject matter experts are consulted, but the ISD professionals remain in control. It’s a good model when things change slowly. The current fascination with rapid e-learning only exacerbates the problems with ISD. Rapid is just a faster version of ADDIE, with less time for reflection and feedback: Garbage-In; Garbage-Out.

I think that ISD and agility are fundamentally incompatible. Clark Quinn proposes a better approach, collaborative co-design:

Things are moving so fast, and increasingly the work will be solving new problems, designing new solutions/products/services, etc, that we won’t be able to anticipate the actual work needs.  What we will need to do, instead, is ensure that a full suite of tools are available, and provide individuals with the ability to work together to create worthwhile working/learning environments.

In short, tying back to my post on collaboratively designing job aids, I think we need to be collaboratively designing workflows. What I mean is that the learning function role will move to facilitating individuals tailoring content and tools to achieve their learning goals.

Collaborative co-design is one more way to integrate work and learning, and give our organizations more agility. Embedding the principles of communicating, focusing on simplicity, releasing and testing often; just make sense in an increasingly complex workplace. Once again, the major barrier, like Enterprise 2.0 or social media for work, is that the traditional gatekeepers have to give up control.

5 Responses to “Agility through collaboration”

  1. Chris

    Interesting article and I think not not many people (at user side) realize how much more efficient content development can be if SME and ISD can work side by side. A problem I see coming up is: how do we call this way of working? I myself called it community driven content development before ( but I like collaborative co-design as well

  2. Martijn Linssen

    Interesting post Harold!

    I have my doubts about Agile in general ( as it strives to deliver a project rather than a product. By that I mean that it is very focussed on quick, fast development interknit with test – depending on verbal rather than written communication

    Agile is such a success because they work in small groups (10-15 max), face-to-face, and don’t document much if anything. In a sense it’s the XP version of RUP

    That’s why they can shift easily during phases, without having to change much else than their common opinions and goals. The problem however is the fact that even after project delivery there’s not much written communication (aka documentation) to be found, making it next to impossible or very costly to sustain or maintain the product delivered

    I agree with the power of Pull described by Clark and the inability for or uselessness of predicting or anticipation (and the desired absence of management in order to fix that)

    The same problem I see in the collaborative co-design proposed: I can see how it gets you “there” faster and better, but I wonder how it will keep you there: how will you retrieve the state of a given workflow so you can know how and why to change it?

    Regardless of that, what you’ll need is relatively highly skilled employees, whereas in E1.0 you can do with relatively low skilled employees and a high-skilled manager to compensate for that. Although, of course, the manager nowadays is little more than someone promoted to the side and a lot less knowledgeable about the actual work to be done than any given employee

  3. Gilbert Babin

    I have many years of software development experience with both Agile and structured methodologies.

    I have seen a few Agile projects go awfully wrong. And even when they were considered a success I had my doubts as to their justification.

    Most elearning projects I have come across didn’t really follow ADDIE. They were just a bunch of naive ideas thrown together. Agile might have worked but not doing the projects still would have been better. Sticking to something simple like a simple instructions manual would have also been much better.

    Just seems to be a lack of down to earth people that can think clearly.

    When it comes to businesses I strongly believe that core business process should be very structured.

    I also believe that all other non-core business processes should be as agile and as diverse as possible. This is not the case in todays organizations. HR, Admin, Finance, etc are way too structured.


Leave a Reply to Martijn Linssen

  • (will not be published)