Can L&D be Agile?

Last week at Learning Live, I had a lot of fun listening to a variety of speakers on some interesting topics. The first of these was from Owen Ferguson, and his colleague (whose name I’ve kind of completely forgotten). They were talking about how they have adopted using an agile methodology for project management when it comes to any work they receive. In the world of technology, this is fast becoming a way to disrupt the traditional way of producing work.

I first learned about agile as a project management methodology in a previous organisation I worked for. The majority of their work was project based, and in the main, it was delivered by using traditional project methodology known as waterfall. The waterfall method is what we know of as a typical was of working in projects. There are various models for this such as Prince2 or PMBOK.

These projects follow a set and prescribed way of working, with clearly defined roles such as Project Manager. You have a scoping phase, development phase, user testing, and implementation. In the world of work, most of us will be used to this. It involves defining clear deliverables, producing business cases for projects, having clear parameters for what work will and won’t be done, milestones, and having a critical path. You’ll likely use tools like MS Project, Gantt charts, SWOT analysis, benchmark research, and other interesting and useful tools.

Project teams normally meet their clients when they have to, when milestones are reached, and at the end of the project when they are ready to hand over and implement a project.

Procurement teams in a lot of corporates favour this as a preferred approach to delivering projects for their companies. This is mostly because of the things I’ve talked about above. It offers these departments the firm perspective that nothing could possibly go wrong, and if it does, there are severe repercussions.

Agile, then, is kind of everything the waterfall method isn’t. Here’s the set of values that agile teams ‘sign up’ to (as in they agree to these things as a way of working):

‘We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over Processes and tools
Working software over Comprehensive documentation
Customer collaboration over Contract negotiation
Responding to change over Following a plan

That is, while there is value in the items on the right, we value the items on the left more.’

The nuts and bolts of this methodology are completely different to waterfall. The agile team works in what are called sprints. A sprint is a period of time normally between 2-3 weeks. At the end of this sprint, there is normally a product available for the client to review. On feedback, the iterative process starts again, and the team set about the next round of development, ready to complete the next sprint in the same time frame.

Instead of objectives and tasks, the team have what are called ‘stories’. These stories help the team know what they should be focused on. The stories can be codified and categorised however makes sense. The idea is that at the start of the project, you have a big list of stories. By the end, using the agile approach, you would have a few leftover which don’t matter.

The iterative and sprint approach means that the client involvement is much greater and often requires the client to be present throughout the project so that decisions can be made instantaneously. What is also means, crucially, is that you have working prototypes from the end of the first sprint. It won’t be perfect, it’ll be full of flaws, but it’ll be something to review against. By the 7th or 8th sprint, you’re either well into producing a highly usable product, or you’re ready to deliver the product because of the process you’ve just gone through.

There are, of course, challenges to this approach. It’s a bold way of working, with definables being worked out along the way. That’s scary for a lot of clients who want a clear idea of what they’re getting before the work has even started. The size of the project team can fluctuate depending on the sprint and stories that still need to be resolved. There is no need for a central project manager. It relies on the team working together and offering support to one another as appropriate, be it your speciality or not.

So, here’s the question: Can L&D work in this way? Can HR work in this way?

For a long time, L&D has always followed the waterfall method. We define a learning need, design a course, and deliver it to the business. There’s little in the way of checking in as it’s being designed. There’s little in the way of effective feedback from users. We pretty much don’t know if it works as a learning intervention until we are standing and delivering.

Those in the e-learning and online collaboration worlds may lay claim that they’ve been adopting the agile methodology more in recent years.

But what about the internal teams? The ones who are aligned to business goals and have budgets to deliver against, and have teams out there doing good facilitation? Can they work in this way?

My tuppence says that if we are to, we have to learn a lot of new skills to support this.

Advertisements

Published by

Sukh Pabial

I'm an occupational psychologist by profession and am passionate about all things learning and development, creating holistic learning solutions and using positive psychology in the workforce.

14 thoughts on “Can L&D be Agile?”

  1. Hi Sukh – There isn’t really one Agile methodology. It’s a set of values and principles (the ones you listed), but if we look at where it started in software development, Agile is a term used to describe a family of approaches, like Scrum, Kanban, Extreme Programming (which may or may not involve snowboards) and half a dozen others.

    Some of our IT teams have recently moved to Agile and are using Scrum and Kanban. Scrum is probably the most popular Agile method and I recommend this video for the clearest explanation: http://youtu.be/XU0llRltyFM (they’ve got a good one on Kanban too).

    Scrum actually has a very strong project leadership arrangement. You have three roles – Product Owner, who represents the business or customer and decides which user stories get built first, Scrum Master who is like the project manager but has a strong coaching role. One of their main tasks is to remove roadblocks so the team members can deliver.

    If I suggested to our Scrum team that it took till the 7th or 8th sprint to get a quality product, they might not talk to me again. The point of the iterations is to focus on small enough pieces of work so that you can deliver working software by the end of the sprint, it might only be a small feature. e.g. if it were a spreadsheet I might only deliver column A in sprint one, but it would still be a damn fine column A!

    You’re correct in thinking that some elearning is produced this way check out the SAM model for some insight http://www.alleninteractions.com/expertise/our-process

    So can L&D work this way? I think there are lessons and ideas we can learn from and more importantly pass on to other parts of the business.

    Take Scrum, they have daily standup 15 minute meetings. Each team member says what they accomplished yesterday, what they are doing today and highlights any problems that have arisen. A great way to energise the day and improve communications in a team.

    User stories – “A user needs a way to do something because of something” Sounds like a much more natural way to thing of learning needs than shoehorning a list of verbs into a learning objective. What’s stopping us creating a backlog of learning user stories and addressing them in Sprints. Wouldn’t this lead to more bitesize learning, performance support and peer to peer sharing?

    Lastly, it’s worth thinking about what it means if your IT team go Agile and your L&D team support release training. Because if that’s you, things are going to change and you are going to need to adapt to Agile and become much more involved in the process at an earlier stage.

    1. Really appreciate your comments here, Sam. You’re absolutely right about there being more than one Agile methodology. I did know this, but got myself confused with Agile and Scrum being the same thing.

      Love your thoughts on how user stories could help create a more responsive way of providing performance support.

  2. I’ve changed my mind to ‘maybe’. I love the collaboration and lack of rigidity required here, but a lack of objectives at that start would be difficult. They are part of what ‘customers’ trust. Especially in a learning intervention, when I’m a big believer in knowing (or at least fully exploring) what you want the end to look like before you begin.
    However objectives of the learning intervention can flex and change along a project.
    Caution tells me an agile method of working is similar to working with requests for L+D when people don’t actually know what they want or need. The ones where L+D isn’t the solution. The result can be a waste of time, or a beautiful thing. Depending on time and creativity to problem solve and make it work. I’d love this style of working – that middle point where HR and L+D overlap. ‘Training’ wouldn’t be the elected but we’d find the solution and change would happen.

    1. I think I wasn’t clear about that. Objectives are set out at thr outset so there is guidance to help get to the outcome. But after that, the plan for getting there, and the solution itself is often a very different place to what it started out as.

  3. Hi Sukh – before centralising L&D in my previous org, one of the options that was considered in re-structuring L&D was to set it up totally as a SCRUM.

    Each team would be aligned to business unit(s) and consist of Project Manager,L&D consultant, ID, eLearning pro, designer and delivery / implementation.

    Unfortunately it did not get off the ground but I think it could work – at least it would have been worth a try.

    What I am though concerned with is this:

    “We pretty much don’t know if it works as a learning intervention until we are standing and delivering.”

    If the ultimate litmus test re the effectiveness of the learning intervention is at the delivery point, then we do need to change and review how we do things.

    L&D needs to wake up and develop the “right” skills that enables them to focus on delivering effective business outcomes or else risk extinction.

    1. Con, thanks for your input here. I imagine that your previous organisation was sizeable enough to accommodate the demands of a Scrum way of working for the L&D team itself. That’s brilliant and it’s a shame it didn’t kick off. Most L&D teams are 1 person, if they’re lucky there may be two!

      I think part of the challenge here is that L&Ders are only just catching up with new ways of working. This is true of most businesses and organisations. So it’ll be some time before they can be truly dynamic in their delivery and the outcomes for the organisation.

  4. Sukh, you raise a fascinating challenge.

    My project management experience is rather limited, but my best experience in the early 90’s was using Goal Directed Project Management which essentially used milestones to track progress. Gantt’s etc were used at a lower project level, but at the Management Team level and for me to use to report to my Steering Group and Project Sponsors I found it a really powerful tool. In essence the questions I asked are “are we going to meet the milestone, and if we are not what are we doing about it”. It allowed us to focus in a way that sounds familiar to the concept you describe as sprints.

    How your blog intrigued me was not about the internal team, but maybe the challenge for the external provider and how they are engaged.
    I wonder if there is some collusion about how to work, and maybe both parties prefer a long and detailed plan, clear timelines and clear deliverables.

    Agile throws up many challenges. Here right now, what does this person, team, organisation need right now to achieve its goals and how do we provide that. Both internal and external. Maybe thats the challenge. After all as my MBA hero Prof Ralph Stacey said “the future is unknowable”

    1. Ian, thanks for adding your thoughts. For me, you’re onto something hot right there. The challenge most practitioners face is how to collaborate well with external suppliers. There’s real opportunity to break away the traditional models of external provider, if we can help that we can help organisations improve what they’re seeking.

  5. I wonder too if we are solution and problem solving oriented, when it may be more useful to use conversation as a core business process – as identified through open space work such as WC – to deepen understanding and create shared insights. Create the right cultural conditions; PM becomes very simple. We like to make things more complicated….. not sure it matters what we call it.

    1. I like the provocation, Meg. I think what Owen and his colleague helped share in his session is that sometimes, following a rigid PM process like Prince2 means it becomes really difficult and challenging to adapt and flex your resourcing needs. An Agile approach means that these things can happen better.

  6. A couple of years ago I led what became an Agile L&D project within an internal team. We needed to design and launch an 8 day classroom course for a graduate programme, which was to be run on a roughly monthly basis with a new cohort of around 30 graduates each time.

    Usually we used a v-model (similar to waterfall) approach, but this time around we had an extremely limited amount of time to create the course before the first intake of graduates were due to start and the fact it was to be run at regular intervals meant it was well suited to an Agile approach, with further development made after each delivery. It allowed for continuous improvement and development and the integration of participant feedback.

    The first iteration created a slightly rough and ready prototype which went well in delivery and was enjoyed by the participants, but had a lot of room for improvement. By the third or fourth iteration we were very happy with the programme, but continued to make minor tweaks over the next couple of sprints.

    As Sam suggested, working in L&D or change management within an Agile environment requires an Agile response. I’ve developed training and system configuration workshops for a client, which used Scrum methodology. We had to use an Agile approach as well, updating our workshops each sprint depending on what had been delivered that time around. Some sprints meant little change for us (if devs have mainly been working on back-end updates) but others required a complete refresh of materials, particularly if there had been any big front-end changes.

    I think Agile is becoming a bit of a buzzword – in reality there are lots of people who work in an iterative way, without necessarily consciously using an Agile methodology. I’ve found it is starting to lose its true meaning a little, with people describing any kind of flexible approach to working and projects as Agile.

    1. Hi Lesley, and thanks for taking the time to comment. I agree, a lot of people probably do iterative work, but I see that as being distinctly different to working in an Agile way. I think you’re also right that the terminologies have become bastardised, and that’s just a sad fact of organisational life.

      Your example of supporting Agile team with the delivery your team produced is a great example of the responsiveness that comes with working in an Agile way.

  7. Really enjoyed reading this blog post and the comments. I’m a organisational trainer, who’s been tasked with challenge of delivering more agile training in our workplaces. The first step for me is identifying what the top challenges a L&D are likely to face when delivering training in an emerging agile environment. Would value your input/comments Sukh?

    1. Hi Chris, appreciate you reading the post and your comment. I think there’s perhaps room for a better conversation to happen with agile practitioners. I have some ideas on delivery. One is to recruit a team and just do it, with you as part of the team. There’s plenty to be said for lived experience with something like this. I think it’s useful to present case studies of how an agile project works so the L&D team can tangibly see what is involved. That helps them to share their challenges with you. I hope these ideas help you think of other things to help make this happen.

Say something...

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s