Traditionally agile


A brief disclaimer. This post is not really about eLearning or learning technology. Sorry to disappoint if that is your only desire. Notions of scrums and agility have been on my mind persistently over the course of the last twelve or so months, for a variety of reasons. I have learned much from practitioners of these arts (not sciences after all?). So this is really about me waking up. It is only really a quick thought too.

In my experience (and it may well only be me) Training (with that upper case T) is not very agile. It seems to prefer programmes and movement after much thorough analysis. I suspect that this is bundled up with the course as the delivery unit and with the ways of working in corporate departments. A major build up to a moment of delivery. Neither of these lend themselves to improvisation. It tends to be more of an orchestral work than a jazz piece. On the other hand, software development, particularly efforts focused on product development, seems to be pretty flexible and comfortable with uncertainty. There is much to learn here I believe.

There are now many experts on this subject and agile professionals abound. There seem to be equally many opportunities to disagree about how it is done best. Nevertheless, there is a general agreement on the principles. My favourite of which is that it is impossible (and very unwise) to predict what will happen over any significant length of time. A five year plan is inherently fraught with so much uncertainty. So don’t. This is a better summary from Barry O’Reilly of Thoughtworks: “Trying to use predictable type processes where you expect a certain thing to happen in months’ or years’ time is just totally unrealistic”. Many casualties of large scale IT systems projects may find themselves wincing as they nod at this.

Jeff Sutherland, who fathered the Scrum methodology sums it up quite nicely. He notes that all that analysis needs to be redone when the development work starts – that’s when we start to really test the usefulness of the analysis. Much to learn here I feel as we try to figure out all what all these fleeting signals of learning need mean and respond in a useful amount of time. I wonder if the unfolding digital world will offer much time for a training needs analysis and a programme that results? I will return to this theme and try and reflect on it closer to home.

In closing, I will also declare that, as a person of a certain age, I find the language of agile and scrum quite odd, alien and unwieldy. I sense the birth of a new profession, creating it’s own language in defence of it’s specialisation. Not quite the open and equal outcome I had hoped for. Whilst they do talk funny, these Scrum Masters are onto something.


Leave a Reply