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.