How We Follow Agile Methods in Our Talent Acquisition Team
I have been interested in learning about agile methodologies for some time already. Not only because I’m interested in tech topics in general but maybe even more because I had understood they can be of value for many kind of work, not only software development.
Therefore I was more than excited when our talent acquisition team decided to try applying agile methods to our ways of working six months ago.
At a time our team had faced a challenge of not having enough visibility between team members thanks to everyone having packed days and long personal to do lists.
We also felt like we were not able to support each other very well with daily challenges and share knowledge as much we would like to.
A typical case was that we found out two people having similar development ideas without knowing from each other and both putting thoughts on it without discussing with each other.
Acknowledging these challenges and appreciating the modern approach of agile methods Nordcloud’s highly talented and professional Head of People Operations and Talent Acceleration Kaisa Tikka-Mustonen was brave enough to invest in experimenting them.
Lead by Kaisa and our team lead Marko Paldanius and together with our team members Władysław Gadomski, Tomi Mahlamäki, Paulina Zajączkowska, Katia Rajanen and Marta Clements we were keen to find out if agile methods could improve our communications flow and help us getting best out of our team efforts.
They are also known to be adaptable which sounded very promising to our hyper-growth business environment where — thanks to continuous development — changes are not uncommon and solutions need to be scalable.
After the first steps during the last six months I can’t call myself an expert in agile ways to organise recruitment work but I’m more than happy to share our model and approach. I hope it gives you some ideas about how your team could harness agile methods to use.
How did we start?
In the beginning our team invested time in understanding the basic building blocks of agile methodologies. Many of you have probably heard about the basic concepts — scrum master, product owner, sprints, daily stand-ups and retrospectives etc.
Focusing to the model we built today, I’m not going to explain them here but just like we did, I recommend getting to know them on the internet. For example scrum.org describes them well.
Or let me know if you’re interested and I can write a separate post about those from the recruitment perspective.
We were lucky enough to get some facilitative support from Pia-Maria Thorén from Agile People. Our workshop with her was mostly focusing to philosophy behind agile methodology.
As starting to work in an agile manner is a lot about changing mindset it was good to discuss about foundation pillars supported by her and recognise typical pitfalls with practical exercises.
To take a long story short, we discussed a lot about basic principles like being adaptable and transparent and creating the right environment of inclusion and belonging.
What kind of a solution we built?
After understanding some more about the very important basics we started building our model in practice.
For the start we of course tried searching for examples and benchmarks but we found out there were not so many models available fitting exactly to out needs and setting.
What we found was mostly about how to manage candidates with the help of agile boards but our goal was rather to manage matters like open positions and development projects.
As our ATS Breezy.hr was kind of using kanban board for candidate management already we were keen on finding ways to organise our teamwork the best way.
As our search didn’t bring a sufficient solution for our needs, we ended up creating a partly self-adjusted scrumban model to Trello.
Scrumban is a combination of scrum and kanban frameworks and in our application it combines the best of both worlds: roles and sprints from scrum and — as length of a recruitment process is not always predictable and development projects often require a longer period — the expectation of not necessarily having your projects ready (done) by the end of sprint from kanban.
To be honest, we were slightly suspicious if creating our own version would be of value or rather the first mistake done. At the same time, we had learnt from our developers that even in software projects scrum or kanban hardly ever is run 100% by the book.
As said, our goal was to improve our ways of working in the recruitment team and it looked like there were not too many examples available for our use case. Therefore we decided to give it a try and trust our skills to create applications of existing models.
And anyway, is it a good model if there is no space for adjustments and creativity? The biggest value of best theories come from their applicability to a real-life setting.
Here’s how our scrumban board looks like:
It’s otherwise one form of quite typical agile boards but our own addition is the column Done & Check. Just for the sake of being able to understand what we have achieved during one sprint and celebrate it we decided to separate dones during sprint from earlier dones.
What other decisions did we make?
Choosing the right type of content for Trello cards wasn’t that simple as you would expect. In the beginning we were a bit of struggling of how broad a topic one card should present.
Individual candidates or interview invitations would be way too detailed for our need but then again, all the recruitments in one country unit way too wide. After evaluating pros and cons between different options we decided to use one card for one position or development project.
To understand the statuses in recruitment processes better with a glance, we additionally decided to mark statuses like sourcing and interviewing as easily modifiable labels to the cards.
When it comes to meetings we went for having 15-minute daily stand-ups two times a week and sprint planning and retrospective once in four weeks.
We have also had a heavy emphasis on automating all the steps where a human being doesn’t bring value in the recruitment process.
At the same time we respect the fact that automating too many aspects would reduce the quality of candidate experience and company attractiveness. Good news is that humans are still needed :)
I believe the above mentioned are the main characters in our agile model but if you come up with any questions I’m happy to answer in comments.
What have we learnt along the ride?
Well, considerably in general I guess but beside basic building blocks probably most importantly, let’s experiment attitude! One of the cornerstones in agile thinking is experimenting and trying out different approaches instead of setting a process in stone.
We have learnt to fail fast. The ways of working don’t have to be perfect and set at once — by comparing different solutions the practical experience will guide in choosing the path for longer use.
But still, you should not stick to it! Always be ready to do agile changes along the way. We live in a world which moves fast.
Additionally, I believe we have learnt the attitude for always sharing when you know (somebody knows). Along the way it has become quite natural for us to interrupt one’s turn in daily saying I actually discussed about the same issue with my business counterpart, let’s organise a chat around it.
The same goes for challenges with tools and processes. Very often you hear happy to show you how I’ve solved it.
As a third notion, you can’t underestimate the power of how teams meeting regularly brings people together and closer to each other. Partly thanks to this development project of changing our ways of working and partly thanks to agile methods themselves, our team has never been this close.
Let’s be honest, has our approach proved itself useful?
Shortly answered yes, and therefore we are looking to continue on the same track and keep on experimenting and building on the foundation we have built so far.
Of course, also going forward we want to stay healthy critical towards our ways of working and be ready to make changes when there is space for improvement.
It’s all about experimenting and learning. We are proud of our achievements and celebrate them but our goal is never to become 100% satisfied — that’s when you stop developing yourself and the business.
Following our adjusted agile methods has helped us quite nicely in creating that needed visibility between team members and providing us channels to identify pain points, support each other and share knowledge.
Of course, it’s not a solve-all-your-challenges-in-half-a-year kind of a model and we have for example reflected if it really benefits to invest time for dailies two times a week while we in practice still handle the recruitment cases quite independently.
So far we have anyway come to the conclusion that regular dailies are a very good platform for staying up to date, changing ideas and easily finding somebody to help out with open questions.
The regular arranging of dailies lowers the threshold to ask support in daily questions. The more seldom the meetings are organised the higher the threshold is to invest time for asking about non-priority practicalities.
It’s good to remember that people easily get fed up with meetings in which a lot of time for the questions not concerning their work area is invested. Therefore I warmly recommend keeping dailies as short status checks.
To be exact, Dailies are not exactly a perfect spot for knowledge sharing due to limited time. Therefore the comments let’s take this separately and let’s get back to this offline have become quite popular in our use and that approach has worked well.
As said, our model is not perfect (as it should never even be), from where we get to the topic of…
What are we looking to learn next?
From how I see it now, the next learning step for our team in the scrumban framework itself is probably the use of story points. We tried them out in the beginning of the process but we didn’t yet quite land to the same page on how to use them and didn’t yet get the full benefit out of them.
I believe that story points could provide great value for us by supporting our priorisation. My expectation is that they would help us estimate what we are able handle during one sprint and what we should consciously leave out and keep in the product backlog.
That would also support our communications towards business. Once prioritisation is clear we know what we are able to achieve during a coming month (sprint) and to what extent we are able to support hiring managers with their hires.
Currently we still have a challenge of having too many projects of different sizes in one sprint and, as we all know, doing too many things at the same time leads to inefficiency and delays with all.
Thanks to rapid growth at Nordcloud it’s typical for us to have a number of roles open all the time and we often struggle with organising our time between them and important development projects.
We have started the journey by creating recruitment prioritisation lists together with business but there is still space for growing our maturity in ensuring we handle the most business critical roles as high-quality and efficiently as possible.
Connected to that theme, we are also looking to find ways to support each other in an agile way with highest recruitment priorities.
We are already come far with supporting each other in many ways but when it comes to daily operational tasks it would be great to create a system around how we can support each other for example in interviewing, sourcing and screening.
The objective would be to make it smooth and agile and be sure to avoid confusions when many people support the same recruitment process. Behind that the strategic goal would of course be to improve the times to hire to serve our business needs better.
As an example, at some point we had common sourcing sessions where everyone looked for profiles for high-priority roles no matter who was the recruitment project owner. Contacting candidates was typically done by the project owner in the end.
That could be something to reconsider for us as a solution but it would be great to make an improved version 2.0 out of it.
I would be also happy to hear your experiences about solving similar challenges.
The third challenge I identify is funnily quite contradictory and makes me wonder if we practice as we preach.
Before starting the agile journey we did some restructuring in our talent acquisition organisation and split it to two parts, Nordics and Central Europe teams.
Now it looks like we are on the stage where we are very well aligned with daily topics in our Nordics team but at the same time notice that our alignment with Central Europe team has been reducing.
As we are today a team of 13 recruitment professionals located to four countries and being responsible for hires in 10 countries and 19 offices, it definitely was a good decision to split to two teams and discuss daily questions in smaller groups.
Anyway, when it comes to certain global initiatives we sometimes notice that it is not so clear for everyone what is going on in different countries.
One of our next internal development initiatives will surely be finding a balance between sharing enough but not too much information between the teams.
Also on this one I’m happy to hear ideas for solving it.
Conclusion
All in all I warmly recommend looking at your ways of working with a critical eye and thinking if agile methodologies could be of benefit for your organisation.
Restructuring ways of working never happens in one day and as it requires time it is of course a strategic question to evaluate if the change is worth the investment in the longer run.
Looking at our experiences from the last six months I can say it has definitely been worth it in many ways and we are able to support our hyper-growth business operating in a global environment better now.
By staying up to date about development projects we can be sure to take best out of the hard work put to initiatives like finding best solutions to business’ talent needs and developing our candidate experience and attractiveness as an employer.
In the end it’s all about supporting our business to deliver and following our mission to power-up our customers digital success by building on the world’s best technology platforms.
If you think the topic is interesting I’m happy to write also about how one of our internal development squads, Community squad, is following agile methods.
I’m acting as a scrum master in it, surrounded by an awesome team of recruitment pros Anna Mäkinen, Władysław Gadomski, Kasia Downarowicz and Katia Rajanen who really have the mindset of continuous growth.
The basic structure is quite similar but there are some slight differences and there is a high emphasis on development initiatives as the themes we cover are related to employer branding, community building and induction process.
Do you see potential in agile methods for your organisation? Or did you already start the journey with them?
I highly appreciate if you contribute by sharing your thoughts and experiences — it would be great to change ideas and best practices with people operations and talent acquisition professionals from other organisations.
That’s why we created Retain and Hire Medium publication in the first place, right? To learn and develop together!
Take care and stay safe everyone :)
