How to become an Agile team
Part 1 — The ‘Why’
We’ve been using Agile to run our Learning & Development projects since August 2016. It now feels like home, and I can’t see us going back. Agile isn’t anything new; there are thousands of sites, courses and advocates that explain what it is and why it’s cool. Essentially it’s a project management mindset that encourages transparency, collaboration, flexibility and, most importantly, speed to market. Its main use is in the software development industry, and at the moment there’s very little out there on Agile for non-techie teams. The good news is that it’s a simple mindset to adopt and adapt. You just need to substitute the term software for [insert anything you like]. So if you’ve got this far, you’re probably interested in the nuts and bolts on how to get started with your team!
Why did we bother?
In June 2016, we were a pretty traditional Learning and Development team. People owned projects or development programmes, they worked on these independently and delivered these over the months in a pretty normal project management-y type way. All well and good. However, because it’s a silo’d way of working it had a number of familiar issues; there was a single point of failure or bottleneck of knowledge, there were seasonal ebbs and flows of work per person, and delivery times were long and limited to how much one person could do — therefore the eventual solution was sometimes no longer the right solution given the world had changed along the journey. All in all, not very efficient or even effective.
We thought there must be a better way to do this, so two of us started looking into Lean, and then into Agile. After a bit of research, and after speaking to and observing our own technology colleagues in Agile action, we kicked off an experiment to see if we could adopt this approach in our own L&D world.
The answer was obviously Yes.
A brief ‘what we’ve learnt’
Agile comes in a few flavours; Scrum, Kanban, Scrumban… and likely loads more variations, splices and alternatives we never discovered. The flavour we’ve used is mainly Scrum (so the steps below are focused on that) but we’ve also had some Kanban-type projects running alongside the Sprints.
Agile has shown us that the focus (or project) can be absolutely anything. But you do need to stick to some basic rules, and initially go-slow to go-fast (in part, because you are also managing your team through a change journey). You’ll then get this back ten-fold.
We’ve used Agile across all different types of projects, including; research proposals, digital learning campaigns, learning resources, infographics, videos (including our first interactive video!) — evidence that it’s not just the playground of software development teams.
Through our Agile adventure we’ve realised a few benefits that are in line with the usual Agile rewards:
· We have realised greater speed to market for business priorities because we work in short ‘Sprints’. These are time-bound periods with a clearly defined goal or output. Multiple brains working together to solve the biggest problems fast.
· The work is more visible and varied — you can see what the priorities are and you choose what tasks to do (it’s just all got to get ‘done’ by the end of the sprint!).
· The design and delivery is customer-centric, data-driven design, and involves constant business owner contact. This means the team delivers a product that is actually needed and wanted.
· There’s a real sense of team ownership and togetherness, working with momentum towards a clear goal.
· Giving and getting pretty instant and honest feedback is the norm — usually weekly for both teams and product — so you get steady incremental improvement.
So all in all, what’s not to like? And here’s how we did it in 9 simple steps:
We originally had this as one single article, but have now split this up into more bite-size chunks. Take a read of Part 2 which cover steps 1–4 of the above, which deals with the necessary prep before you Sprint.
