That’s the conclusion we came to when we asked our practitioners the question we get asked most often: how do I know how to get the best training in agile project management?
At GDS we encourage the use of agile project delivery techniques for service delivery through the service design manual, so we are often asked for our opinion on the best ways to learn to become more agile.
We decided to crowdsource a response via our own agile practitioners by asking them:
“How did you learn to be an agile practitioner and what was your journey along the way?”
I gathered a group of agile practitioners into a room, this included delivery managers, agile coaches, transformation managers and agile team members.
Initially I asked everyone in the room to give themselves a score to help understand what level of agile experience they have, this was:
- I’ve heard of agile / seen others do it but no direct involvement myself
- I’ve been involved in agile projects at GDS, but not prior
- I’ve been actively part of an agile team at GDS, but not before joining GDS
- I’ve been actively part of agile teams at and before joining GDS
- I’ve been a delivery manager or an agile coach or a product manager at GDS but not before joining GDS
- I’ve been a delivery manager or an agile coach or a product manager at and before joining GDS (how many years?)
The scores ranged from 2 - 6 with number of years from 1 to more than 10, so we had a good spread of experience.
I then asked the people in the room to create a timeline, that showed the moment they first heard about agile to today. This included points along the way like: seeing agile done in organisations, formal training and starting to take part in agile projects.
They then paired with another person in the room to discuss the good points and bad points along that journey. They wrote these up on post-it notes and shared with the entire group.
The overwhelming message of the workshop that everyone in the room gave is that they only got to this point through hands on experience. We have taken the outputs of this workshop and fed them into our guidance for agile training, which is now on the service design manual. We’d love your feedback in the comments below or contact me on twitter @ewebber.
Emily Webber is Head of Agile Delivery at GDS. Any questions, comments or feedback? Respond here or Follow Emily Webber on Twitter
6 comments
Comment by David posted on
Really like this approach!
When I was working with traditional project management techniques the picture was similar in that everyone knows you need hands-on experience to develop your skills - formal training can only ever be a small part of the picture.
However, people (myself included) still felt the need to get the 'badge' that completing a course gives you because this is how your competence is measured in HR and recruitment terms.
It's positive from this perspective that e.g. the GDS job description for a delivery manager asks for 'proven experience using agile project management methods' rather than specifying qualifications in the way many civil service project delivery roles do
David, MOJ DS
Comment by Emily posted on
Hi David,
thanks for your comment and glad you like it.
I do think there is a place for formal training (as is mentioned in the guidance), but I think it's only part of the journey and not always a necessary one, depending on what information training you have access to. The concern I have with judging competency on certification alone is that it can be a badge of turning up and doing a course rather than the ability to practice. It's great to get the fundamentals, but until you get experience you can't gain a deep understanding of it.
Comment by Richard posted on
Learning by doing is the very best way, but it does work best in a supporting environment. Learning without a supportive, already-agile-ready environment is not impossible, but you risk taking short-cuts and learning bad habbits. This is best avoided by learning in an environment that has at least one experienced agile coach present, and by buddy-pairing with experienced agile and lean practitioners.
Comment by Emily posted on
Hi Richard,
I completely agree, having a supportive and safe environment to learn is important. I mention shadowing in the guidance for agile training, but we also buddy some of our newer to agile people with more experienced agile practitioners to help their development. This helps with personal development, but also organisational learning.
Comment by David posted on
This is really very interesting. I have some questions. If you consider that the generation doing Agile at GDS are pioneers, will the generation that follows acquire their skills the same way? Following on from that, if proven experience in agile is a pre-requisite for an agile role, how do you get proven experience? Finally, what are the key filters you use to narrow down candidates when hiring?
Comment by Emily posted on
Hi David,
I don't consider that the generation doing agile at GDS are pioneers, lean principles have been around as a concept since the 80s, XP since 1999 and the agile manifesto was written in 2001. Many of us at GDS are part of a second, or third wave of agile practitioners, who have developed whilst courses, books and blogs exists. Those learning now have an even bigger wealth of resources to support learning, both in the material that existed as well as opportunities to see it working in different environments. As experience is such an important part of becoming a practitioner, I don't see that this will change for future generations.
You can get that experience from a number of places, shadowing others within your organisation or elsewhere is great, but you can also take the principles of the agile manifesto and start applying them in any work environment to create continuous improvements, agile is not just for software delivery teams. When hiring we look for people that have taken the opportunity to do this. We also look for those that have strong skills in people and teams, problem solving, collaboration and communication, all skills of a good agile practitioner.