Agile methodology has been sweeping the world since early 2000’s. It came about when a group of software developers met to discuss the current methods for developing software. They quickly realised that the traditional at the time waterfall project management was slow and ineffective. It took a lot of time to develop something the customer required. And when it was done, it didn’t work and the customer no longer wanted that. So they came up with the Agile manifesto. And so the craze around Agile began.
At first it was only in IT companies. I was introduced to Agile when the company I worked for at the time transitioned it’s entire 800-odd IT workforce to Scrum. Our HR Director had a brilliant idea and said that, in order for HR to support our workforce, we had to understand how they worked and what are their pain points. So we set on a long journey to working in Scrum teams as well.
Very few companies had done this before us. We had to find out own way and create our own manifestos. At first, we were hesitant, then we got a little more confident and finally we were bold in our execution and development. But how did it work?
As a scrum master for one of the teams I had a very good view of the process. I will aim to briefly describe how we made it work for us. And if you’re interested to learn more, please contact me – I’d be happy to chat about this.
What is Scrum?
To understand Scrum is to understand the underlying principle and terminology. Simply put, once a customer wants something from a team, they sit down and decide how to do it. So far, it’s not that different from traditional project management. The difference comes in how much time it takes to execute the task and the regularity of communication with the customer. Usually teams decide to work in short iterations, or ‘sprints’, and after N number of sprints to showcase what they have produced to the customer. If s/he is happy with the result, it can go live or development continues. If not – detailed feedback is collected and the team gets to work. Another important term to remember is Minimum Viable Product, or MVP. That is, if the customer wants a digital clock, the team has to create a clock first and then add colours and shapes, humidity detection, radio and so on.
What is Scrum in HR (example)?
Let’s say I am the customer and I want a new recognition scheme developed by HR – one that fits the company culture, is seen fair by employees and gives a lot of options for recognition to my team members. Traditionally, something like this can take up to year. But what if my friendly HR team says “Sure! We’ll get it done in 2 months!”. My first reaction is to not believe them. But my second one would be to ask how. This is where my friendly HR business partner would tell me how they work in small iterations, keep asking for feedback and report back to me on progress every 2 weeks. The illustration below summarised very neatly the whole process of Scrum – from a project entering the ‘production line’, to working in small iterations, to creating a ‘shippable product’.
Scrum Roles in HR
How did it work in HR? First, we needed to establish the roles and their responsibilities. Agile normally has 3 roles – product owner, the team members and a scrum master (the last could be optional, depending on the set-up). In HR we created 4 roles:
Service owner – this was our HR Director, who was responsible for all the projects that were to be done through Agile; because the HRD had close relations with the business, they knew what our 'customers' wanted and were responsible for creating the projects the teams were to work on
Service Area Owner – the Heads of the different departments within HR – Talent Acquisition, L&D, Central Services and so on
Team members – teams were comprised of different experts, which allowed people who had never dealt with other areas of HR to now be actively involved in the creation and implementation of new projects in those areas; because the whole HR team is relatively small, the Service Area Owners were also team members
Scrum master – this was the person who ‘defended’ all the Scrum ceremonies (I’ll talk about those later), supported the team, created a feeling of team belonging and ran all the meetings that were part of Scrum; in IT the Scrum master isn’t necessarily part of the team, but in our case I was also a team member.
Now that we knew what the roles were, we had to understood what we were supposed to do. This is where artefacts and ceremonies played an integral part. Generally speaking, artefacts were all the documents that ‘ruled’ our work, and ceremonies were all the meetings we had to take part in. We’ll come back to those in a bit.
We also needed to understand how Agile fits into our daily work. As in any other profession, in HR there are a lot operational things we do on a daily basis (think payroll every month – it has to happen, you cannot delegate and if you don’t do it, a lot of people would be angry). So our fearless Service Owner mandated a 50/50 set up. That is, 50% of our time would go into business as usual (BAU) tasks, and the remaining 50% would be dedicated to Scrum.
Artefacts and Ceremonies
Now back to the nitty-gritty. The artefacts each Scrum team has to have are:
Backlog – a prioritised list of all projects or ‘stories’
Stories – or the projects, a detailed description of what needs to be done. It usually follows a simple but powerful phrasing “As a …[Manager] I want … [a new recognition system for the employees] that allows … [to have more recognition options for my team members]”
Items – the specific task at hand (i.e. interview manager about specific requirements for recognition system)
Epic – a collection of different stories/projects under the same title
Burn-down chart – a fancy Excel sheet that tracked how much time the team members spent on working BAU and Scrum and how much time it took each team to complete the stories they had pulled off the backlog
Sprint backlog – a physical or online board that has up to 4 columns – to do, in progress, review and done. Each item would begin in the ‘to do’ column and slowly progress through the board until it ends up in the ‘done’ column.
There are other artefacts teams can use but these are the main ones.
As for the ceremonies, the most important ones were:
Item selection meeting – this is when each team would select what ‘stories’ or projects to pull
Sprint planning – where each team sits down and plans for the iteration to come
Daily stand-up – every day team members would (ideally) begin their day with a quick 10 to 15-minute check in; each member would answer the questions – What did I do yesterday? What am I going to do today? What hinders my work?
Demo – a meeting to which either the service owner or customer (or both) are invited to see the result produced by the team (in HR we called it Global Epic Review)
Retrospective – at the end of each sprint the team would meet up to discuss what went well, what didn’t go too well, what needs to start/stop/continue happening. Generally speaking, the retrospective is time to retrospect – reflect back on what has happened and highlight any lessons learnt so the team can work even better in the future.
As a result of one such retrospective it became clear that keeping a burn-down chart for one of the teams was considered a waste of time. And we stopped doing it. Another team recognised that they needed more support and guidance from the service owner, so we invited her to every other daily stand-up.
Couple of retrospective games you can play - the team wheel and hot-air ballon.
Scrum Example in HR
Let’s put all of this into an example from my experience. In one of my teams we were working on an epic called “New Manager Induction”. We were to create a process for onboarding first-time managers into the company. The below table illustrates how we went about it.
The epic and the stories were written by our Area Service Owner – she knew what the business required and how to go about it. She set the acceptance criteria (or a description of what she would consider a ‘shippable product’). We had to break down each of the stories into items we could then pull of our sprint board. We ended up with something like this:
When we tried assigning how much time each item would take, we realised that the Online portal was huge and it would take more than 1 or may be even 2 sprint to complete. As a result, it was broken down even further and refined with smaller categories, update of links to the intranet and other important documents.
The final result – the whole epic was done in less than 2 months. Every new manager could take advantage of a wealth of new information whenever they wanted and needed it.
There are cases when the Area Owner simply doesn’t have the capacity to break down an epic appropriately. This is when the team can help – they can conduct all the needed research in order to understand the business needs better and then roll their sleeves and get to work.
The nirvana of Scrum and/or Agile in IT is to create homogeneous teams, i.e. for QAs to learn how to develop software and for developers to know how to test it. This way the team wouldn’t be dependent on just one person’s knowledge or expertise. While this is almost impossible to accomplish, the idea is rather nice and very much applicable to HR as well. When you have people in payroll, rewards, recruitment, business partners, L&D and OD working together, you are bound to learn something new.
The methodology described here is not as detailed as you would get in a 2-day practitioner training. I would love to continue the series on Agile in the future. If you’re interested too, give me a shout and I’ll continue writing about my #adventuresofthelearner as a Scrum Master for over 2 years.